propose a concensus building process for groups

[codersquid]

I'm pasting in some text based on the OSC blog's decision making process. I helped review it for the group. I'll replace text about the OSC blog or just leave it blank.

Group Structure

Within the SciPy conference, there are several domains of responsibility or “working groups”:

(note: I'll just list a few here, there were more for the OSC blog)

Technical:

• conference site development/maintenance/training
• proceedings platform development/maintenance/training

Community Management:

• inviting new team members
• dealing with conflict resolution between members
• oss support/outreach

  Membership

Working group membership is open to anyone who is interested, and a person can belong to multiple groups.

Documentation of workflow

Group meetings should be:

• recorded: either directly, by being held in a text-based medium such as IRC or gchat, or by assigning someone at the meeting to take notes
• planned: it’s recommended that an agenda be created and shared before the meeting, and that decisions and action items be created and shared during/after the meeting
• open: when choosing how to meet, be mindful to use non-proprietary tools so anyone can join

Work style, leadership, and decision-making

As an open project, the most critical features of work style, leadership, and decision-making are open communication and respect for all contributors. How decision-making actually occurs can vary widely as long as the values of openness and respect are embodied in the process. While the default process is that which is established by the entire OSC blog group (see below), groups should feel free to determine their own system, organization of leadership, and/or division of roles and responsibilities. They should make sure all group members find the chosen process acceptable, and it is recommended that they check in occasionally with members to make sure it remains so.

Conflict management

If their process fails to solve a problem, and help from a community manager/disinterested party doesn’t help, they can put the process before the full “oscblog” group, either informally or through the formal consensus-based process defined below.

Decision-making process:

It’s important to us that individuals have the freedom to make decisions about their work and to use their own time efficiently. Therefore the default decision-making process is “do-ocracy” - if you’re willing to make the effort to do something, do it! If it’s a decision that affects other people, it’s requested that you look for informal agreement among working groups or the SciPy organizers as a whole. Informal agreement typically means sending an email and waiting 12-24 hours to see if anyone objects.

Occasionally, however, there will be major decisions that need to be made, disagreements over how to proceed or conflict between individuals. To deal with these circumstances, we’ve defined a consensus-based resolution process. Anyone may request that a more formal process take place, however practically speaking we do not expect this to be very common.

Formal Consensus-based Process:

“Getting consensus” does not mean that every member of the group has to agree enthusiastically, or even agree at all.

What it means:

1. Anyone who cares about the decision has had the option of being part of the consensus process. (Anyone who doesn’t care can abstain!)
2. “Being part of the consensus process” means that everyone participating who wants to make their opinion heard can do so. Ideally discussion focuses on clarifying disagreement and seeking compromise. The outcome of a consensus discussion is a proposal (often this is the initial proposal that began the discussion, but is also frequently a modified or alternative proposal). The group should aim to make sure discussion is finished before bringing the proposal to a vote.
3. Participants are asked to vote for or against, abstain, or block the proposal. Some threshold/percentage of for vs against votes, pre-determined by the group, ensures the proposal’s passage.
   • “Voting for” - participants want the proposal to pass and be enacted
   • “Abstain” - participants do not care enough about the proposal to vote either way
   • “Voting against” - participants do not want the proposal to pass but will accept the outcome
   • “Block” - participants are very strongly against the proposal. Blocking should only be done on issues where the blocker is willing to leave the group over the disagreement.
4. When a proposal is blocked, a second round of consensus-seeking occurs, with the goal of formulating a new proposal that addresses the blocker’s objections. Members of the group who had not been participating may be made aware of the seriousness of the disagreement. After discussion, another vote happens. (Groups may require that a greater % of votes must be positive when someone is blocking.) If the proposal passes, it is enacted, and it is up to the blocker whether to remain as part of the group.

[aterrel]

@codersquid : I think most everything said here goes into the manual. I put the decision things at

https://github.com/scipy-conference/scipy-conference/blob/master/manual/decisions.rst

I think the discussion on the group structure and workflow should be a separate document. We should also see about getting sphinx or pelican to generate a nice page for the manual too.

[codersquid]

I am very happy with that document you created, and it resolves this issue for me. Thank you very much!

[scopatz]

Thanks Andy!