Huishoudelijk Reglement/Accepted/Official Techinc Poll
Agreeing on something over Email
Contents
The Problem:
Since Techinc is an association, we often have the need to come to a decision about something after having informed and consulted people about their oppinnion on a specific matter.
Ultimately, the ALV is the association's mechanism to decide upon important/critical matters. Less critical matters and/or more time-critical subjects might either not be worth waiting for an ALV or might require greater speed to decide upon.
It should be clear to everyone that 'just asking at the social' or 'see what people know about something on IRC' isnt the correct method to ask the association members what they think about a particular subject.
Not everyone's on IRC or at the Social at the time of asking, after all. And neither of these places are the association's official communication-channel. The 'members@techinc.nl' mailinglist, however, is.
However, conducting a 'poll' or 'vote' via email can be quite troublesome if there are no prior guidelines/protocols set up that set boundaries/procedures. Past experiences with this have taught us this multiple times with people ending up confused or dissatisfied and nobody any wiser as to the status of the vote's result; wasting a lot of time.
Examples of Challenges
- What form should the mail have that informs them that it is an 'official techinc polling/voting' and not just someone asking something so there'll not be any doubts/questions later.
- What should the mail contain ? Size of proposal outline ? Only Yes/No questions allowed ?
- Should the person asking for/about something be seen as the 'owner' of the question for as long as the poll is running ? Are there any roles/tasks the owner has after the poll has been submitted ?
- How long do people get before they have to decide ? It is clear there should be a MINIMUM time set to prevent people hijacking some issue/event/whatever with a 1-hour-polling-interval. Is a week too long? 3 (full 24hour) days ?
- How should they reply ? It is often not clear how to interpret people's replies when they answer in 'I kinda like the idea; however ...' form. Is that a yes ? A no ?.. etc. An unambiguous answer-form should be adopted *and* communicated in the poll-announcement
- Who does the counting ? Does it matter much if it's the vote-owner if the mails are all public ?
- What happens if the vote-owner finds he/she cannot spend time on managing their votable point ? Can ownership be transferred at all or not ?
The mechanism:
Since different people have different expectations on 'what is clear/valid/long enough', there is a lot of room for arguments popping up because of a vote's form/contents, as well as arguments , afterwards, as to what a particular vote MEANS, or even if it was valid at all.
To prevent this from happening (as far as is possible), we propose 'Official Techinc Poll's, referred to as OTP from here on:
The Proposal Text:
We implement a 'yes/no' mechanism only for the types of questions that we want people to give their oppionion by being allowed to cast a vote for any particular option. The OTP mechanism is provided to come to an understanding on how the association's members feel about any particular undertaking/suggestion. The end-result should be understood and accepted as such.
It should be made clear that conducting an OTP or having an OTP conclusion on anything should not be required for any particular person to commence or cease doing any particular activity in the space. It is intended as enabling tool; not as a requirement.
Any poll cannot have a end-date less than *5* 24-hour periods in the future. (* As voted for on the ALV) It is suggested no vote should last more than 2 months.
Any poll/question is conducted over the members-mailinglist (or any future alternative implementation thereof).
Any such OTP contains the following fields:
- A sufficiently clear subject line with POLL or OTP in the subject
- Name of person(s) asking
- Description of the problem/question
- Discussion of the options available referred to with a label (YES means... NO means, etc) and their consequence.
- Any poll should have the NO option mean 'no change'
- Poll Deadline (DATE + TIME!)
- A description on how to vote (where to send the vote, how it should be formatted, see below)
The Vote owner and her role:
The vote-owner is the person who called for the vote in question.
The vote-owner is expected to answer questions about aspects that might be unclear.
The vote-owner is invited and encouraged to participate in any debate/argumentation that is held; he IS , however, expected to READ the discussion about it (on discuss@ or any future list with the same purpose)
The vote-owner is expected to remind people, one day in advance, of the impending deadline for a vote.
AFTER the deadline has passed, the result of the vote should be tallied up by the vote-owner and communicated to the mailinglist as a reply to the original vote-mail.
In case of a vote TIE between the two options, the vote-owner gets to chose which of the options is adopted as the result of the vote.
Results for the available options should be listed and the 'result' of the vote should be made clear; aka: what will now happen because of the vote.
The vote-result should be communicated within one 24Hour period after the end of the vote.
If the vote-owner cannot do this him/herself, he can delegate the task to someone else provided the vote-owner communicates this in a reply to the vote-mail. This person does NOT become the new vote-owner, but DOES need to adhere to the provisions above regarding vote-tallying, reporting, etc.
Vote-owners have the right to CANCEL any vote they started if the need arises. It is encouraged they do so ONLY when there's a severe NEED to do so.
Vote-owners can transfer owner-ship of the vote to someone else who then AGREES to be the new vote-owner. Communication should be in a reply to the original mail, informing members/participants of this.
Participants and their role:
Participants:
- need to be a member of the space.
- need to reply to the mail on the ORIGINAL mailinglist (the MEMBERS list, in other words)
- vote by having a line at the top of the email, stating 'I vote: <option>'. The mail can contain other content, but the vote should be at the top. The <option> should correspond to one of the options listed; ie: YES or NO, Nothing more.
- need to make votes without provisions. ie: 'I vote X , as long as Y'
is not possible.
- can change their minds later by re-voting as long as it's before the
dead-line. Only the LAST cast vote by any participant should be counted.
*ACCEPTED* Optional proposal parts:
Option 1: not listed as it was not accepted.
Option 2: A similar mechanism may be created , in the future, that conducts the vote-casting part on a web-based piece of instrastructure. The announcements/discussions/results, etc, would still be done to the mailinglist, but the vote-casting mechanism described could involve a service hosted on techinc-managed infra. Provided that:
- Any person can only cast one vote (though altering it allowed)
- Any person can be verified as being a member of the space
- The casted vote of anyone can only be altered by whomever cast the vote.
- A public audit-log is posted on every change to the mailinglist.
Option 3: Board has the power to cancel an OTP before completion: The board is granted the power to cancel/stop any OTP that is started. The board does so by posting a statement , in name of the board, in reply to the OTP, on members@ , stating 'The board has chosen to cancel this OTP' followed by the reason(s) it has chosen to do so.
All the other provisions described in the mailinglist-based method stands.
End of proposal texts + optional sections
ALV vote summary:
The proposal text above had been suggested to vote on at the ALV of March 2018
It was decided then to: A) Require at least 5 days of running time B) Not allow altering any poll after having sent it C) Permit creation of a similar mechanism via a webpage under certain terms (see original Huishoudelijk_Reglement/Proposed/Official_Techinc_Poll ) D) Permit the Board to cancel/stop any running poll in case of need.
Closing remarks:
It might be useful to state a number of expectations regarding what the effect of the proposal might be.
It is envisioned that an OTP might be conducted at least a few times each year.
It should be clear (again) to anyone that undertaking an activity does not and should not *require* an OTP before it can be undertaken. It is meant as a tool to help resolving inclarity or prevent conflict about something.
It should be made clear that an OTP is in a very real sense 'the will of the association', and a fully conducted OTP's end-result should be taken as such.
Short FAQ:
- Q: Why just Yes/No voting and not multiple options ?
- A: This would require a rather complex voting mechanism to prevent weird effects from happening with ties. The solutions to these (Condorcet, runoff-voting, etc) are very labor-intensive to manage and thus beyond the scope of something we can expect 'just someone' to pick up without software aiding it. It is anticipated in a next iteration a proposal might be made on how to handle it.
- Q: Why is option 3 even on the table ? This feels wrong
- A: The reasoning behind Option 3 to be proposed is to provide *some kind* of of mechanism to counter some potentially very problematic effects an OTP might end up having:
* Someone proposing a flippant/frivolous OTP on something personal * 'This is an OTP on the subject of whether or not MrAnon is not STUPID' * 'Yes - MrAnon is stupid * 'No - MrAnon isn't unstupid
* Someone proposing something that should be left to an ALV: * I propose an OTP on changing the statutes
* Someone proposing an OTP that ends up forcing someone to do something: * I propose an OTP on having MrAnon paint the space for us.
* Someone proposing an OTP on something that is impossible: * I propose an OTP on having all the tables and chairs mounted on the ceiling
* Someone proposing an OTP on the same thing, over and over and over * This is OTP nr. 65 on MrANon.... I await your votes (again)
The reason it is left as an optional part is to ensure that if people wildly disagree on such a power to rest with any group or the board in particular that the proposal could still be voted upon.
It is the opinion of the primary author that SOME mechanism should exist that allows an OTP to be cancelled if there is a pressing need to do so. While thinking about it, no obvious/useful alternative mechanisms presented themselves that would not depend on some particular 'trusted entity' to have that power. Given that the board is already entrusted with ensuring the wellness of the space, this power seems to fit naturally in their domain. A special remark might be in order regarding cancelling an OTP if it's deemed to be ALV material. That should result in the OTP's topic to appear automatically on the next ALV's agenda.
- Q: Hey, why not just use this cool website/our wiki/online-hosted-service/a script on my laptop/etc.
- A: While thinking of just how the OTP mechanism might work, a fair number of ideas about where to conduct communication about it were considered. A list of some of these and reasons they were not included in the proposed mechanism are listed here:
* IRC * Not everyone's there to see what's going on at any time. * Conducting a poll over a long time is very hard to do. * Wiki * Due to the alterable nature of a wiki, it is an ill fit. * Using 'modification history' might solve the above at the cost of work * Altering things as an admin is easy to do; making trust an issue * Forcing public audit trails is not easy/straightforward * Hosted solutions at 3rd party * Putting our data in the hands of third parties has trust issues * People might rightfully reject having to make an account elsewhere * An audit trail , again, is not straight forward. * Paper slips + voting box * Physical medium in the space; requires physical presence * You need to trust those who have access to the box. * Audit-trail issues.
- Q: Can you give us an example of what a OTP-mail would look like ?
- A: Sure, here goes:
----------------- From: JustaMember@stupid.example.com To: members@techinc.nl Subject: Techinc Poll: Kitchen-floor area. #OTP-time! Hi, Who: Me (Justa) and my fellow-member AnonyMouse have been hearing a lot of things about the kitchen-area and how the carpet there is really not working out. What: After some discussion with some people involved, it seems it's a good idea to rip the carpet out and replace this with something more useful like water-proofed wood, vinyl, what-have you. Something durable, slip- proof and water-proof. It'd also be nice to have it look good. Which: For this reason, I'm asking for a poll so that there's clarity on if this is something other people see as useful or not; since it'll take quite some tearing/ripping/etc to get this done. Perhaps people prefer carpet, who knows. We will set up a pledge to get the money together for the new flooring and make sure that it gets done in at most 2 days of actual work after the pledge is fulfilled. Options: YES: allow me and Anonymouse to organize this. NO: Floor at the kitchen stays at is is. When: Since there's no haste, the deadline is in one month from now , so cast your votes before $hour o clock on $day of $month, $year. How: Reply to this mail on members@techinc.nl (not discuss!) Write 'I vote yes' if you are in favor or 'I vote no' if you dont care for this. Put that line at the TOP of your mail, please. See our HR for the rest of the rules regarding polls: https://wiki.techinc.nl/index.php/Huishoudelijk_Reglement ---------------------------
- Q: What's up with the 'No' = 'No change' option ?
- A: The reason for any vote to have to include the NONE option is to make sure that people can vote to have nothing be changed. No poll should list only one 'mildly acceptable option'next to a 'totally outrageous/ impossible things' option.
- Q: Why allow changing of your vote?
- A: A concern that came up during discussion/design of the proposal is that a discussion about something is expected to start after an OTP is started. During the discussion, it's also expected that new viewpoints and arguments might well end up wanting people to change their oppinion about the matter or even desire to have other options available. Examining this issue seems to have resulted in the view that allowing people to change their vote should be made possible, and the OTP proposal foresees in this. It is however a very hard problem to tackle to try and design a mechanism that allows new vote options to be introduced somewhere halfway an OTP without bad effects being introduced. Hence this is not included/attempted.
- Q: any more things you thought about during the design-phase ?
- A: OTP's should avoid language geared towards any particular person. If the goal is to get a particular person's conduct or activity commented upon, it should be phrased as a general question regarding that kind of conduct or activity so that it should be clear these are allowed or disallowed for all people, not just one in particular.
- Q: Wait, you forgot a lower limit
- A: The OTP mechanism proposal doesnt include any lower limit regarding the amount of people that need to cast a vote for it to be valid. It is anticipated that having the minimum amount of days for a vote to run be long enough will result in enough votes OR enough trust that enough people had the opportunity to cast a vote if they cared about doing so. This should be kept in mind when deciding on what to vote for option 1 of the proposal.
- Q: It feels so analog, I like digital!
- A: As said; there's a fair amount of challenges that were discussed during the design of this proposal. The fact that multi-option votes are hard to conduct without some software-tool, for example. In the future, we expect that we might be able to provide some kind of 'hosted' tool that will allow someone designing a poll (aka: the vote-owner) to post a vote using a special form to a/the vote-related mailinglist. Also, to allow members to vote using the mailinglist or a web-page... and then lastly to give the vote-owner a tool to create a vote-report that includes the totals for each option as well as the exact overview of how tie(s) were broken. etc.
The Debian Project already works with things in this manner; it'd be good to have a good look at their tooling for this purpose.
As a last comment about this; it might be good to stipulate that keeping track of OTP outcomes on a wiki is perfectly allowed and encouraged so as to make it easy to check the history of outcomes.
