833
edits
Changes
Jump to navigation
Jump to search
Line 63:
Line 63: + +
Talk:Authorization Policy Vote (view source)
Revision as of 06:26, 22 February 2015
, 06:26, 22 February 2015→Ambiguity - Constraining authority for granting exceptions
My concern with the ambiguity is the communication as to when an exception has occurred. For example: said well-meaning area host grants an exception to a non-member, for acceptable reasons as defined as policy. How is this documented / communicated, in case of a situation where the equipment / tool subsequently requires repair? It is one thing, when a member is authorized for use and documented on the wiki - very easy to track down an individual in case something goes awry. However, it is another thing entirely when the exception is not documented, especially for problemsolving and root cause analysis, when it is unknown except to one individual who has been granted an exception-authorization. In the case of a one-time occurrence of a non-member usage exception, I would suggest wording that the area host identify and communicate in some way the exception-authorization, such as: document on the wiki page as a "non-member exception authorization" / report said occurrence to the board / document in board meeting minutes / or otherwise identified in some way. I will defer to the board as to the appropriate communication method, only that some communication method occurs.--[[User:Bioguy|Bioguy]] ([[User talk:Bioguy|talk]]) 12:59, 14 February 2015 (CST)
My concern with the ambiguity is the communication as to when an exception has occurred. For example: said well-meaning area host grants an exception to a non-member, for acceptable reasons as defined as policy. How is this documented / communicated, in case of a situation where the equipment / tool subsequently requires repair? It is one thing, when a member is authorized for use and documented on the wiki - very easy to track down an individual in case something goes awry. However, it is another thing entirely when the exception is not documented, especially for problemsolving and root cause analysis, when it is unknown except to one individual who has been granted an exception-authorization. In the case of a one-time occurrence of a non-member usage exception, I would suggest wording that the area host identify and communicate in some way the exception-authorization, such as: document on the wiki page as a "non-member exception authorization" / report said occurrence to the board / document in board meeting minutes / or otherwise identified in some way. I will defer to the board as to the appropriate communication method, only that some communication method occurs.--[[User:Bioguy|Bioguy]] ([[User talk:Bioguy|talk]]) 12:59, 14 February 2015 (CST)
Bioguy, that's a different concern than the person who raised this initially. These exceptions are going to be rare. In the case of a repair person, we may not even know in advance the name of the person dispatched, so the Area Host may need to give a "blank check" exception to whoever Epilog sends out. So I'm hesitant to want to add more required procedures around this. The real question in my mind is that if the Area Host is asked why X person is using a tool without being a member listed on the Wiki, the Area Host can say "Oh, that's the master blacksmith who was teaching a class." or "Yeah, that was the guy from Inventables who was installing limit switches on the ShapeOko." Also, member tool usage today has virtually no traceability. Having a list of authorized users does us little good in determining who broke X tool. There is value in listing authorizations on the wiki, such that any member can check to see if the person using the tool is authorized. But in the case of an exception, it should be very clear anyway, e.g. a class advertised on the calendar, or the person is clearly servicing the tool. --[[User:Rdpierce|Rdpierce]] ([[User talk:Rdpierce|talk]]) 00:26, 22 February 2015 (CST)
== Minor style suggestions ==
== Minor style suggestions ==