Talk:Authorization Policy Vote

From Pumping Station One
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Bylaws vs Policies

Kyle Bieneman from the mailing list:

I fully support revising the policy to make it more flexible and adaptable to varying needs. However, I have a basic threshold question, since we seem to sometimes play fast-and-loose with terminology:
What is a "policy" in a PS1 context? I see that we have at least one policy (the Conflict of Interest Policy) as part of our bylaws. Is that what we intend this policy to be as well, an amendment to the bylaws? If so, easy enough, though we should bear in mind that to make any exception to the policy, we'll need a 2-week lead time to propose a vote. If this, or any other policy, is something other than a bylaw, what differentiates it from a bylaw?
Anyway, those are my thoughts/questions.
Best,
Kyle


Bioguy from the mailing list:
Kyle and all:
I also feel "bylaw" and "policy" are ambiguous as currently documented. On an ongoing basis I am doing a bylaw review to address issues like these. My goal is to clarify the differences between these two terms, make the bylaws a bit more high level and policies more low level and detailed. I'm sorry for the brevity but I am on a work site, but if anyone has any questions please feel free to private message. - Bioguy
Ryan Pierce from the mailing list:
We should take this discussion to the Wiki discussion page. I'm not in a place where I can easily do this.
Bylaws are supposed to define how an organization works at a high level. They aren't supposed to address day to day operations. So amending the Bylaws ideally should be a break-glass-in-case-of-emergency situation. Policies should be created and amended more frequently as the organization's needs change.
A lot of things that should be policies are or were in the Bylaws. Over the years, people have been removing things from the Bylaws and making them policies. Area Hosts are a good example.
Use of tools and authorizations never was in the Bylaws, nor should it be, so this is being proposed as a policy.
For a list of PS:One policies, see https://wiki.pumpingstationone.org/Category:Policy
Kyle's follow-up:
This obviously goes somewhat beyond the scope of this particular vote, so I won't belabor the point, but as a general comment, while the above explanations tell me about how the group would like to categorize the rules, it doesn't tell me anything about how the rules interact with each other in a legal sense. If a policy conflicts with the bylaws, do the bylaws supersede? If we want bylaws to be changed less often, and policies more often, is there anything in our rules which promotes that? Again, this is a fight for another day, but I'd just like to plant the seed here. If we want to create a distinction between "Policies" and "Bylaws," that distinction is only really meaningful if it the two are actually legally different in some way (such as: votes for policies have a lower quorum requirement, votes to change bylaws require a supermajority, etc.). Otherwise, all we've really done is arbitrarily chopped up our bylaws onto different pages based on how "big" we think the rules are.

That's an interesting point. I've heard suggestions that Bylaws changes should indeed require higher standards to change, possibly in terms of quorum, super-majority, review period for the vote, or even mandatory external legal counsel review. But, yes, that's a fight for another day. The best we can do now is to encourage people not to change or amend the Bylaws when a policy will suffice, as is happening here. --Rdpierce (talk) 20:52, 13 February 2015 (CST)

Ambiguity - Authority of Board vs. Area Hosts

Kyle Bieneman from the mailing list:

Assuming the intention is to incorporate this into the bylaws, my two suggestions on language are:
Reduce ambiguity regarding relative authority of the board vs. the area hosts. In several places "The Board of Directors or an Area Host" are given authority to do certain things under the policy. What happens if they disagree? (Say the Board wants to require certification for a given tool, but the Area Host thinks that's unnecessary.) I'd rather give authority to one or the other by default. Either the Area Host (with the Board as back-up if the Area Host position is vacant or if the Host declines to make a ruling), or the Board (which could obviously ask the Area Host for advice).

I considered this when drafting the policy. Ultimately, I had concerns about how long the policy was becoming, so I wanted to simplify this as much as possible.

What I would like to happen: The Area Hosts are the "boots on the ground." They should be the people making decisions for their areas. The Board would need to step in only when:

  • The Area Host can't do it. (On vacation, vacancy in the position, etc.)
  • An issue spans multiple areas. (E.g. an extreme circumstance where a member should have their authorizations revoked on all tools.)
  • The Board feels a need to override the Area Host's judgment. Ideally, issues would be resolved between the Board and the Area Host, but at the end of the day, the Board should make the final call.

Under the draft policy, it's technically possible for the Board to overrule an Area Host, and the Area Host overrules the Board, and the Board overrules the Area Host, etc. But practically, this would be a stupid move for the Area Host because the Board would likely remove the Area Host from office. I felt this situation was unlikely enough that it wasn't worth complicating the policy by setting up a more complicated decision making structure with escalation. I'm interested in hearing opinions on whether this is the right call. --Rdpierce (talk) 20:46, 13 February 2015 (CST)

I'd say keep it simple.--Bioguy (talk) 12:44, 14 February 2015 (CST)

Ambiguity - Constraining authority for granting exceptions

Kyle Bieneman from the mailing list:

I would not constrain the Board/Area Host's authority to grant exceptions. The policy as written is so broad as not to be a meaningful restraint (virtually anything could be deemed "events that provide benefit to Pumping Station: One"), but formally writing a list of accepted situations where exceptions can be granted will simply provoke arguments down the line about whether the Board has authority to grant an exception in a given situation.

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. --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.--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. --Rdpierce (talk) 00:26, 22 February 2015 (CST)

I think recording in the wiki would be great. Just a page like Tool Authorization Exceptions Record. It could just have a table that has who and why and the person that authorized them. I see value in something like this that bioguy is suggesting and it would be an after the fact thing. Kinda like posting to the list when you brake something. It helps every one learn and keeps a record. I would prefer a wiki page over just a post to the list because it is easier to go back and look at and easier to organize. --Lucas (talk) 20:21, 23 February 2015 (CST)

I'm hesitant to tie Area Hosts' hands by creating policies so specific that problems inevitably happen requiring more voting to correct them. For example, the original policy required that every authorized user be listed on a physical list located on the tool. That turned into a really bad idea, and as a result we blatantly ignored our own policy. Personally, I prefer to let Area Hosts handle authorization exceptions in whatever way they deem best, which may be the Wiki, the mailing list, listing them in the same way maintenance records for the tool are recorded, etc. --Rdpierce (talk) 23:44, 23 February 2015 (CST)

Minor style suggestions

Currency is not idiomatic for this meaning. I suggest replacing it with recency or expiry or expiration. -- Skm (talk) 09:14, 14 February 2015 (CST)

Mike, you had me worried there.... The term "currency" gets used a lot in the aviation community. As in, "I'm not night current, so I can't carry passengers at night. The night currency requirements are having done three takeoffs and three landings to a full stop in the past 90 days at night." I was wondering if this was just aviation jargon, but I'm actually seeing this as valid usage in a number of dictionaries, such as:

The aviation concept is exactly what I'd like to express here with tool authorizations, although at present nobody is doing it because we don't have the technical ability to track it. This could change when we add RFID power locks for tools. --Rdpierce (talk) 00:10, 22 February 2015 (CST)

Retrieved from "https://ps1.mywikis.wiki/w/index.php?title=Talk:Authorization_Policy_Vote&oldid=22697"