Updated contributing guide with voting rules

Proposer
Floppy
State

Accepted

Vote Score

2

Age

3676 days


@Floppy edited contributing.md - about 10 years ago
  1. Make your change in the editor.
  2. Click the Save icon, enter a description of your change, and hit commit.

Your change will be entered into the pull request queue for discussion

Your change will be entered into the pull request queue for discussion

before being merged into the master version.

If you're more familiar with GitHub, you can of course use the standard fork / pull request model.

s

The Rules

  • Anything can be changed.
  • All contributions and discussions are public, and should take place as part of a pull request.
  • Plain English is essential - follow the GDS style guide if you can, or use Hemingway to test readability. Try to avoid political weasel-words.
  • Make changes small, self-contained, and simple. Large changes will take a lot longer to get agreed upon and merged. Small is agile.
  • All content is public domain. By submitting a change, you agree that you are putting your work into the public domain. See the full license for details.

Merging Changes

Changes will be merged when a quorum of existing contributors have approved the pull request with a 'thumbs-up' symbol in the comments. Any contributor can block a merge by including a 'thumbs-down' symbol, as long as they include constructive reasoning and alternative proposals.

We are not using a straight majority voting system, as it's not suited to a long-tail participation model, certainly not with our current contributor numbers. Instead, we're using a type of blackballing, where anyone can block, but only a relatively small proportion are required to actively agree in order to accept a change.

Once an author has had a change merged in, they will become an existing contributor and thus can vote on new changes.

Changes will be merged when 20% of existing contributors excluding the proposer (currently 2) have approved the pull request with a 'thumbs-up' symbol in the comments. This proportion may change later, based on how active contributors are; it would be good to increase it, but at the moment this is a practical level.

The Rules

Any contributor can block a merge by including a 'thumbs-down' symbol, as long as they include constructive reasoning and alternative proposals. A change cannot be merged as long as there are blocks in place.

  • Anything can be changed.
  • All contributions and discussions are public, and should take place as part of a pull request.
  • Plain English is essential - follow the GDS style guide if you can. Try to avoid political weasel-words.
  • Make changes small, self-contained, and simple. Large changes will take a lot longer to get merged. Small is agile.
  • All content is public domain. By submitting a change, you agree that you are putting your work into the public domain. See the full license for details.

Votes are counted by an automated script, which sets the GitHub build status on the pull request depending whether enough votes have been received. See the Open Votes page for details and vote counts. Changes are merged by a repository administrator once consensus is reached.

Once an author has had a change merged in, they will become an existing contributor and thus can vote on new changes.

Floppy

@Floppy - about 10 years ago

As guidance for new admins

PaulJRobinson

@PaulJRobinson - about 10 years ago

👍 My concern with the 20% of contributors threshold for a successful proposal, is that the evidence of participation thus far indicates that we're good at getting 'new' contributors who will increase the overall number, but less good at retaining their involvement for more than a couple of weeks or PRs. So I would be worried that our overall number of listed contributors continues to increase without increasing the number of 'regulars'. The 20% rule may make it hard to get successful PRs before too long.

How do we increase the number of 'regulars'? How do we retain interest enough to get them to continue to vote on everyone else's PRs once they've written/merged their own one or two pet projects? Hopefully the CleanWeb April meeting will help.

Floppy

@Floppy - about 10 years ago

Yes, this is a concern of mine as well, and it's one of the things we will learn as we scale. If it doesn't cope well with the long tail, then we will have to change this in another PR.

PaulJRobinson

@PaulJRobinson - about 10 years ago

I know it may be in the minority on this, but I think this project will need to start having a 'real-world' presence to maintain and build the sense of community interest and involvement. Existing solely as an online organisation won't be enough. The UnParty meetups are good (sorry I couldn't make the last one) but I think we need an explicit Open Politics physical presence to encourage discussion (both on policies and ways forward for the group) to maximise the sense of involvement.

Floppy

@Floppy - about 10 years ago

I was considering organising a regular hack night, where people could attend IRL or virtually to work together on policy. Might be a step in that direction...

philipjohn

@philipjohn - about 10 years ago

Gah, I deleted my own comment. Fool.

After speaking with someone about the manifesto last week they got me thinking about how we could spread the idea further.

I thought we could look at hooking up with the likes of Bite the Ballot and (especially) the Rational Parliament.

In fact, I mused over the idea of having some sort of effort to create PRs based on a RatParl debate, or a follow-on/parallel "hack" type event to get RatParl folks contributing.

PaulJRobinson

@PaulJRobinson - about 10 years ago

Bite the Ballot is a good idea. Especially if you give them the angle that they could improve youth turnout by encouraging them to engage in this project.

philipjohn

@philipjohn - about 10 years ago

Oh that reminded me, I've been meaning to suggest #146