View source for Huishoudelijk Reglement/Proposed/Official Techinc Poll

Agreeing on something over Email

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 (3, 4, 5, 6, 7 *) 24-hour
periods in the future. (* to be voted on seperately, majority wins)
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.

Optional proposal parts:
------------------------
Extra options (as part of the ALV vote):
Option 1: It is allowed to alter/refine parts of the vote-text and
options for up to 3 days before the deadline of the vote to compensate
for errors/typoes/etc. NOT to alter the impact of the result.

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 suggestion:
--------------------
The proposal text above is suggested to be voted upon on the next ALV.

Given the nature of votes, the order in which they proceed are often
very important to the effect a particular decision might have. People
might agree to a proposal only if they know what kind of minimum/maximum
limits might be set. If these are unclear , people often opt to vote
'defensively' and an (otherwise good proposal) doesnt make it. Hence,
the following voting-process:


A - First vote for the value of 'X': the minimum amount of 24-hour
periods a vote should run for. The options are '3, 4, 5, 6, 7'.
Majority-vote accepted. If tied, re-voting is done between the members
of the tie until broken and one result is achieved.

B - Second vote is for Option 1 to be part of the proposal. A yes/no
majority-vote.

C - Third vote is for Option 2 to be part of the proposal. A yes/no
majority-vote.

D - Fourth vote is for Option 3 to be part of the proposal. A yes/no
majority-vote.

E - Fifth vote is to determine if the ALV agrees to include the
proposal into the HR with the value of X determined in vote 1, and the
inclusion of Option 1, 2 ,3 determined by Vote B,C and D . A yes/no
majority-vote.

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 oppinion 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.
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
trackof OTP outcomes on a wiki is perfectly allowed and encouraged so as
to make it easy to check the history of outcomes.