62
edits
Changes
Jump to navigation
Jump to search
Line 61:
Line 61: + +
Talk:Authorization Policy Vote (view source)
Revision as of 18:59, 14 February 2015
, 18:59, 14 February 2015→Ambiguity - Constraining authority for granting exceptions
I agree that the powers granted are extremely broad. But I believe keeping them is helpful because it encodes the intent of the policy within the policy itself. Five years from now, people may not remember *why* a given policy was written in a particular way. If the policy carries no constraints, a well-meaning Area Host could reasonably conclude that there isn't anything wrong with letting their non-member buddy spend an evening using our laser cutter. A well-meaning Area Host probably wouldn't grossly stretch definitions to allow this same situation with the policy as written. --[[User:Rdpierce|Rdpierce]] ([[User talk:Rdpierce|talk]]) 20:46, 13 February 2015 (CST)
I agree that the powers granted are extremely broad. But I believe keeping them is helpful because it encodes the intent of the policy within the policy itself. Five years from now, people may not remember *why* a given policy was written in a particular way. If the policy carries no constraints, a well-meaning Area Host could reasonably conclude that there isn't anything wrong with letting their non-member buddy spend an evening using our laser cutter. A well-meaning Area Host probably wouldn't grossly stretch definitions to allow this same situation with the policy as written. --[[User:Rdpierce|Rdpierce]] ([[User talk:Rdpierce|talk]]) 20:46, 13 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)
== Minor style suggestions ==
== Minor style suggestions ==
''Currency'' is not idiomatic for this meaning. I suggest replacing it with ''recency'' or ''expiry'' or ''expiration''. --[[User: Skm | Skm]] ([[User talk: Skm |talk]]) 09:14, 14 February 2015 (CST)
''Currency'' is not idiomatic for this meaning. I suggest replacing it with ''recency'' or ''expiry'' or ''expiration''. --[[User: Skm | Skm]] ([[User talk: Skm |talk]]) 09:14, 14 February 2015 (CST)