Hi everyone, related to another thread, I’d like to set up a guideline for who gets notified if we have to turn off someone’s key because of a safety/security/policy concern.
We have been informing area leads/admin list of these actions but it’s really been on a case-by-case basis, we don’t have anything formal in place.
When someone’s key is deactivated by security we should notify:
0 voters
I think the notices should be for leadership given one caveat. The whole community doesn’t need to know people’s dirty laundry unless it involves the safety of members.
Now, I don’t know every reason for key revocation off the top of my head so that may end up being the only reason in practice. No matter what, leadership ought to have the option for discretion in this matter.
I think we’ve only revoked one key for violence/fighting. Other reasons we revoked keys this year: total failure to clean up. being a disruptive jerk. stealing from us. being on the Kansas Registered Offenders list.
(all different people of course)
So it’s not always safety. We also have excluded names from the board minutes to protect privacy. As one board member said, “This guy could be applying for a job someday, they google him and find out he was a jerk who got kicked out of MakeICT, do we really want to punish someone that badly?”
I am confused how this survey works. I see that @Kez voted for all the choices. Couldn’t that skew the results a bit? Shouldn’t it be limited to one choice? Doesn’t post publicly mean that the members, keyed members, and leads will get notified?
I don’t think names or pictures need to be included in any notification to the general membership. Unless the act was really bad. Instead the membership should get something like:
This afternoon a member had to be forcefully removed from the building after… The member has had their membership and key revoked and is permanently banned from the facility.
Just a simple notification basically. There was a security issue. It was resolved like this.
Check boxes next to anything you’d support.
This is sort of how a board motion would have to work - a motion is presented, you vote yes or no, we can’t vote four ways. So pretend you’re at a board meeting and someone says “I move that we publicly post the cause and persons concerned in all key revocations” - would you support that, on its own? Look at each option independently. Whichever thing has the most support is the one I’ll probably propose that we incorporate as a process.
Sorry, I am a dumbass. I cannot read…
I don’t think we could post names or pictures with any of these no matter how bad the offense because of possible lawsuits.
You can just as easily get sued for withholding information about a possible safety concern.
So you have to choose who gets priority, our ~400 active members or the person who just got their key revoked?
A good rule to follow is “if in doubt, communicate”.
Just because something isn’t posted publicly, it wouldn’t mean we couldn’t let people know. The aircraft industry requires that all records be deleted yearly. Hmmmm… should we have some sort of document retention policy here?
Sigh… I hate legal stuff
Hi, pardon the shortness, I’m just trying to hey thoughts out before my lunch break ends.
I would say that we should include the name and badge photo and that their key was revoked. This should be sent to the entire membership.
No reasoning need be given. Anyone can visit the wiki and see the policy.
It’s important to send out name and photo so that some nice member doesn’t let a person back in the space after their key has been revoked. We all know the door gets opened for people. Let’s try to mitigate that. No I don’t see it as a breach of privacy. We’re just stating that the key was revoked, not the reason why. In general, we’ve revoked keys for security reasons. That’s all that really needs to be know.
Okay, I think those were coherent thoughts.
Happy lunch everyone.
Wouldn’t it make more sense to just post it on on the door? Not everyone reads the Forum. I get behind sometimes.
I can see some sense in posting it on the door for that reason.
And I am thinking that Security should probably be the ones to post, rather than the board.
They(we) are the first to know when a key is revoked.
Oh and I should mention that as far as I know, the pictures are not saved from the badges (i don’t know why)… so posting a picture may actually be impossible.
They are stored locally, but it would be nice to store them in the member’s profile on WA. Perhaps we can get IT to take a look to see how feasible it is, time-wise.
Is this something that some non IT person could just get started by moving things?
I suppose you could find it on the local drive and upload it to that member’s WA profile, but it would be very slow and prone to mistakes.
Maybe I missed something. What are we wanting to put into WA?
My thought was that there are a lot of things that need to be done. If this isn’t a top priority for IT, I could get the old data converted and then we could just work on a process for new people. (I find that fixing old data is the bane of those in IT and sometimes if that barrier were lifted, the new process is more likely to go forward.)
Personally, I’ve been doing some systems auditing at work. If we have a decent process figured out and start using it, I personally feel like that’s the best first step. That prevents the amount of “re-work” from increasing, so you actually feel like you’re making progress when you start going back through all the stuff that was being done the “old” way. But that’s just me, YMMV.
I agree with Josh. I think Keyed members should know at the board’s discretion so no one let’s the person in and potentially puts MakeICT, themselves, or others in danger. I don’t think dirty laundry needs to be out there, but if someone is a danger enough to have their key revoked, members should have the right to be aware for safety. Getting a key is a privilege that comes with responsibilities and when a person makes the choice to damage that trust, other keyed members have a right to know for safety reasons at the board’s discretion on how much to share.