That would be cool… how hard do we think it will be to put a process in place?
We were talking about putting the ID badge photos into the member’s profile on WA, so that Security or Administration would be more able to put faces with names.
Of course sometimes the keys are removed for behavior instead of safety. Do you only want to know of the safety cases? or all of them?
It seems to me that a big reason to notify folks of key cancellations is so that they don’t allow that person in as a guest without knowing that person’s status. If that’s the main reason, then the front and back doors might be a good place to notify members, but there would be logistics and policy issues to address first. And I’m not sure WA is able to store member photos anyway. Whatever the case, it would be nice for those needing to see what someone looks like to be able to pull up some kind of image by name. Getting NAS space or whatever donated for the project would be trivial – I’d donate a large NAS myself for it, if necessary.
1 Like
Ok I am an idiot… what is NAS?
Network Attached Storage unit. Basically a hard drive that can be reached from anywhere on our network. I could live in the Admin Closet.
Wouldn’t it be kind of small…
Pain-induced typo. 
It could live in the Admin Closet. But now that you mention it, I’m pretty much limited to about that much area at home at the moment…
I would vote for Other: Depends on situation.
Reasoning:
- A key revocation may be temporary.
- It may be only to prevent that person hosting a guest.
- It may be to prevent them being unmonitored.
- It may be that they are not to enter even public events and classes, maybe they are banned from the premises.
Unless we give policy flexibility we can end up with a policy we ignore, or cannot enforce, or need to revisit.
Whether a person made keyless needs to be named at all depends on why their key was revoked.
When they need identified, it may or may not be useful to describe why they had their key revoked.
If temporarily, that needs to be clearly stated, with the expiration date.
If because of their handling of guest policy, then maybe they can be allowed as a guest of a keyed member without any other restrictions.
Mike B
1 Like
You’re correct, of course, and that’s why I said I thought we needed to deal with logistics and policy if we are going to put this into place.
Hey Kim. I know a lot of people give you a hard time about the pollls. I like them, though. It lets me get an idea of what the quieter folks are thinking.
Reviving this topic, possibly because of personal relevance.
Regardless of what may affect me personally, was there any decision reached about who is notified, how, and with how much detail when a key is revoked?
I hear that there may have been four keys revoked around a week ago, and I have only, that I am aware of, heard directly about one of them, heard indirectly about two more, and the fourth one is a mystery.
I never have much liked loose threads on policy discussions, even when I think the proposed policy is a bad idea I think making a decision by just moving on is bad form. Make an explicit decision, disclose the reasoning, and if something provokes a need to revisit the policy or the decision to leave things as they are, then at least there is some accountability for how things got the way they are.
Mike B
1 Like
I can’t get to the wiki right now for the policy but I believe the decision was made at the May board meeting to update the key policy with the statement: “In the event a key is revoked, Lead Security Officer shall notify the appropriate member, the Makerspace Area Leads, and the Board of Directors of the reason by phone or E-mail within 48 hours.”
We can inform other people at our discretion, but that’s the minimum. If you are not a lead, you will not hear about keys that are revoked.
No problem Kim. No one seems to have a different recollection of the time line, and the wiki being unreachable does not help as far as verifying what the Board had done and when.
Every thing you say sounds like what happened. The Board made a decision (possibly in May), but, combined with laterr things happening caused some offline discussion. What was settled in May, seems not to have remained settled by June 20th.
In June this topic was created to further discuss ‘Key revocation notifications’. Further discuss is OK, but what I am asking for is someone to take responsibility (ability to respond) for no further action.
Just letting the thread die off, is sort of a decision. But, is that really the best way to be responsive to what must have seemed important enough for the President to start a discussion thread?
There are several individual posts in this thread that seemed to imply more would be forthcoming. Then, nothing. And so, if it is just fine as is, as an official decision, say so here. Lock the topic. Whatever.
As I have said before, and will no doubt say again, I really dislike loose threads, especially in public, where no one reading can tell if anything was done responsive to the effort put into the discussion.
Mike B