Update contribution rules

Proposer
Floppy
State

Accepted

Vote Score

5

Age

3362 days


@Floppy edited contributing.md - about 9 years ago
  1. Make your change in the editor. Formatting uses Markdown.
  2. Once you've made your change, enter a short comment in the box that says Update {filename}.
  3. Click the 'Commit Changes' button.
  1. If this is your first edit, please agree to the Contributor License Agreement to state that your submission is in the public domain.

Your change will be entered into the discussion queue. There will then be a vote, and possibly debate, amongst contributors on whether to adopt the change.

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

Want to contribute but aren't sure what you can start with? Check out the issue list for some ideas.

Want to contribute but aren't sure what you can start with? Check out the issue list for some ideas.

The Rules

{::options parseblockhtml="true" /}

  • Anything can be changed.
  • All contributions and discussions should be public, ideally on GitHub.
  • 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.
  • Changes need not be fully detailed or final. In fact, accepting partial improvements which we then build upon is encouraged, as it keeps things moving faster.

Merging Changes

Voting on changes

We are not using a straight majority voting system, as it's not suited to a long-tail participation model. Instead, we're using a type of blackballing, where anyone can block, but only a small number of contributors are required to actively agree in order for a change to be accepted.

Only votes from existing contributors are counted. In order to get a vote, you need to get a change accepted first.

Votes

Voting is done using special symbols in the comments for a change:

| Text | Symbol | Meaning | |------|--------|---------| | :+1: | πŸ‘ | Agree | | :hand: | βœ‹ | Abstain | | :-1: | πŸ‘Ž | Block | {: .table .table-striped}

For a change to be accepted, two existing contributors must agree to the change, and it must have been open for 7 days. If a change is amended, votes are reset and are only counted for the latest version of the text.

Blocks

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.

Any contributor can place a block on a proposal, as long as that block comes with reasoning and constructive comments for improvement. A change cannot pass while it has a block on it. A block can be removed by the original blocker changing to an agree or abstain vote.

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.

Closing old changes

All changes (aside from very minor ones) should remain open for discussion for at least 14 days before being merged.

A change will be closed without merging when it is more than 3 months old without passing.

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.

Counting votes

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 Votes page for details and vote counts. Changes are merged by a repository administrator once consensus is reached.

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 Votes page for details and vote counts.

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

If the script detects that a change has been passed, it will be merged automatically

Help

Floppy

@Floppy - about 9 years ago

This changes the contribution rules in a couple of important ways, and improves the layout and wording of the rest of the guide. This is based on experience of the system over the last year or so, and a desire to make things move more quickly.

Changes to voting: 1. Only two existing contributors are needed to pass something. This is no longer based on a percentage of existing contributors. We have enough active members that incompatible ideas will be blocked before being merged. 2. Reduce minimum open vote time to a week. Two weeks is long enough for things to grind to a halt, one week should increase momentum. In my experience, consensus forms quickly or not at all. A week is enough. 3. Changes will be closed after 3 months if they're not merged, to keep the backlog clean and remove the interference from other old PRs hanging around. 4. Changes will be automatically merged on passing by the script so that admins can't sit on approved changes if they're not 100% happy with them. Block or pass.

We should also be encouraging blockers to counter with their own proposal, or if blocking for reasons of "this isn't detailed enough", to allow the change and build on it in future PRs.

This PR will be merged using the existing system, which means we need 5 yes votes to pass it.

Floppy

@Floppy - about 9 years ago

Pinging @PaulJRobinson @philipjohn @digitalWestie @tmtmtmtm @yellowgopher @rufflemuffin @BenTrimble @frabcus

As our most recent contributors, you guys are most likely to have opinions on this change, and we need your votes :)

@Floppy edited contributing.md - about 9 years ago
  1. Make your change in the editor. Formatting uses Markdown.
  2. Once you've made your change, enter a short comment in the box that says Update {filename}.
  3. Click the 'Commit Changes' button.
  1. If this is your first edit, please agree to the Contributor License Agreement to state that your submission is in the public domain.

Your change will be entered into the discussion queue. There will then be a vote, and possibly debate, amongst contributors on whether to adopt the change.

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

Want to contribute but aren't sure what you can start with? Check out the issue list for some ideas.

Want to contribute but aren't sure what you can start with? Check out the issue list for some ideas.

The Rules

{::options parseblockhtml="true" /}

  • Anything can be changed.
  • All contributions and discussions should be public, ideally on GitHub.
  • 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.
  • Changes need not be fully detailed or final. In fact, accepting partial improvements which we then build upon is encouraged, as it keeps things moving faster.

Merging Changes

Voting on changes

We are not using a straight majority voting system, as it's not suited to a long-tail participation model. Instead, we're using a type of blackballing, where anyone can block, but only a small number of contributors are required to actively agree in order for a change to be accepted.

Only votes from existing contributors are counted. In order to get a vote, you need to get a change accepted first.

Votes

Voting is done using special symbols in the comments for a change:

| Text | Symbol | Meaning | |------|--------|---------| | :+1: | πŸ‘ | Agree | | :hand: | βœ‹ | Abstain | | :-1: | πŸ‘Ž | Block | {: .table .table-striped}

For a change to be accepted, two existing contributors must agree to the change, and it must have been open for 7 days. If a change is amended, votes are reset and are only counted for the latest version of the text.

Blocks

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.

Any contributor can place a block on a proposal, as long as that block comes with reasoning and constructive comments for improvement. A change cannot pass while it has a block on it. A block can be removed by the original blocker changing to an agree or abstain vote.

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.

Closing old changes

All changes (aside from very minor ones) should remain open for discussion for at least 14 days before being merged.

A change will be closed without merging when it is more than 3 months old without passing.

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.

Counting votes

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 Votes page for details and vote counts. Changes are merged by a repository administrator once consensus is reached.

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 Votes page for details and vote counts.

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

If the script detects that a change has been passed, it will be merged automatically

Help

tmtmtmtm

@tmtmtmtm - about 9 years ago

"We should also be encouraging blockers to counter with their own proposal, or if blocking for reasons of "this isn't detailed enough", to allow the change and build on it in future PRs

I disagree with this: I thought the aim was to avoid policy based purely on ideology? Where no justification whatsoever is provided for a policy, for example, it should always be acceptable to say "this needs more information".

(The version in the PR itself is somewhat better as it refers to "partial improvements". (Emphasis mine))

Floppy

@Floppy - about 9 years ago

Yes, take the version in the PR as the important one, but I see what you mean there. I really want to say that if we know something is basically good, but would benefit from expansion, we encourage adoption and improvement in subsequent PRs. Iteration over big bang. Does the proposed text do that, ignoring my bastardisation of it in the description, do you think?

tmtmtmtm

@tmtmtmtm - about 9 years ago

I think the text in the PR itself is OK; but it would be better if applied in parallel with something for #71

tmtmtmtm

@tmtmtmtm - about 9 years ago

If the script detects that a change has been passed, it will be merged automatically

I suspect there should be at least some delay between the final 'yes' vote, and the auto-merge.

philipjohn

@philipjohn - about 9 years ago

Firstly, +10 manifesto points for mentioning #71 (there's no badge/prize/whatever, sorry)

I thought briefly about whether we could do something around that. We would perhaps have to rely on the voters to be blocking something that isn't evidenced well (within reason) though.

I suspect there should be at least some delay between the final 'yes' vote, and the auto-merge.

My interpretation is that a change would get merged after one week if it's passing the criteria. Are you suggesting that if, for example, the required votes happen on day 7, the merged should be delayed by X amount of time. I.e. "merge after 7 days if last vote was less than X ago"

tmtmtmtm

@tmtmtmtm - about 9 years ago

yes β€”Β or even later. I'm thinking here of a scenario where, after 7 days, there has only been one yes vote. Then, a week later (say) there's a second yes vote β€” at which point (by my reading of this), the change will get merged straightaway. I'd like to see even a 24-hour delay or so here, to allow people time to react to it. Yes, everyone should have been paying constant attention, and all that, but still...

philipjohn

@philipjohn - about 9 years ago

Yes, everyone should have been paying constant attention

Ha, it's all too easy to glance at a PR and then forget about it though, so it does make sense.

24 hours sounds good. I wonder if we could rig up the option for folks to be notified the moment a PR is 24hrs away from being merged.

Floppy

@Floppy - about 9 years ago

OK, yeah, fair enough. We could have the auto-merge have a secondary delay, though of course a manual merge could happen quicker. Do we want to have a minimum delay before merge, or would it be OK to do immediately on passing if a human does it?

@Floppy edited contributing.md - about 9 years ago
  1. Make your change in the editor. Formatting uses Markdown.
  2. Once you've made your change, enter a short comment in the box that says Update {filename}.
  3. Click the 'Commit Changes' button.
  1. If this is your first edit, please agree to the Contributor License Agreement to state that your submission is in the public domain.

Your change will be entered into the discussion queue. There will then be a vote, and possibly debate, amongst contributors on whether to adopt the change.

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

Want to contribute but aren't sure what you can start with? Check out the issue list for some ideas.

Want to contribute but aren't sure what you can start with? Check out the issue list for some ideas.

The Rules

{::options parseblockhtml="true" /}

  • Anything can be changed.
  • All contributions and discussions should be public, ideally on GitHub.
  • 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.
  • Changes need not be fully detailed or final. In fact, accepting partial improvements which we then build upon is encouraged, as it keeps things moving faster.

Merging Changes

Voting on changes

We are not using a straight majority voting system, as it's not suited to a long-tail participation model. Instead, we're using a type of blackballing, where anyone can block, but only a small number of contributors are required to actively agree in order for a change to be accepted.

Only votes from existing contributors are counted. In order to get a vote, you need to get a change accepted first.

Votes

Voting is done using special symbols in the comments for a change:

| Text | Symbol | Meaning | |------|--------|---------| | :+1: | πŸ‘ | Agree | | :hand: | βœ‹ | Abstain | | :-1: | πŸ‘Ž | Block | {: .table .table-striped}

For a change to be accepted, two existing contributors must agree to the change, and it must have been open for 7 days. If a change is amended, votes are reset and are only counted for the latest version of the text.

Blocks

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.

Any contributor can place a block on a proposal, as long as that block comes with reasoning and constructive comments for improvement. A change cannot pass while it has a block on it. A block can be removed by the original blocker changing to an agree or abstain vote.

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.

Closing old changes

All changes (aside from very minor ones) should remain open for discussion for at least 14 days before being merged.

A change will be closed without merging when it is more than 3 months old without passing.

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.

Counting votes

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 Votes page for details and vote counts. Changes are merged by a repository administrator once consensus is reached.

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 Votes page for details and vote counts.

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

If the script detects that a change has been passed, it will be merged automatically 24 hours later.

Help

@Floppy edited contributing.md - about 9 years ago
  1. Make your change in the editor. Formatting uses Markdown.
  2. Once you've made your change, enter a short comment in the box that says Update {filename}.
  3. Click the 'Commit Changes' button.
  1. If this is your first edit, please agree to the Contributor License Agreement to state that your submission is in the public domain.

Your change will be entered into the discussion queue. There will then be a vote, and possibly debate, amongst contributors on whether to adopt the change.

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

Want to contribute but aren't sure what you can start with? Check out the issue list for some ideas.

Want to contribute but aren't sure what you can start with? Check out the issue list for some ideas.

The Rules

{::options parseblockhtml="true" /}

  • Anything can be changed.
  • All contributions and discussions should be public, ideally on GitHub.
  • 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.
  • Changes need not be fully detailed or final. In fact, accepting partial improvements which we then build upon is encouraged, as it keeps things moving faster.

Merging Changes

Voting on changes

We are not using a straight majority voting system, as it's not suited to a long-tail participation model. Instead, we're using a type of blackballing, where anyone can block, but only a small number of contributors are required to actively agree in order for a change to be accepted.

Only votes from existing contributors are counted. In order to get a vote, you need to get a change accepted first.

Votes

Voting is done using special symbols in the comments for a change:

| Text | Symbol | Meaning | |------|--------|---------| | :+1: | πŸ‘ | Agree | | :hand: | βœ‹ | Abstain | | :-1: | πŸ‘Ž | Block | {: .table .table-striped}

For a change to be accepted, two existing contributors must agree to the change, and it must have been open for 7 days. If a change is amended, votes are reset and are only counted for the latest version of the text.

Abstentions

An abstention cancels out one agree vote. So, if there are two agreements and one abstention, another agreement is requirement in order for the vote to pass. This means it can be used as a sort of temporary hold, or a request for more evidence.

Blocks

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.

Any contributor can place a block on a proposal, as long as that block comes with reasoning and constructive comments for improvement. A change cannot pass while it has a block on it. A block can be removed by the original blocker changing to an agree or abstain vote. Blocks are discouraged; it's preferable to use an abstention to make it more difficult for a vote to pass while more evidence is gathered.

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.

Closing old changes

All changes (aside from very minor ones) should remain open for discussion for at least 14 days before being merged.

A change will be closed without merging when it is more than 3 months old without passing.

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.

Counting votes

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 Votes page for details and vote counts. Changes are merged by a repository administrator once consensus is reached.

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 Votes page for details and vote counts.

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

If the script detects that a change has been passed, it will be merged automatically 24 hours later.

Help

Floppy

@Floppy - about 9 years ago

OK, I've updated the text to include a 24 hour delay after passing before auto-merge, and to make abstentions cancel an agreement. I think we will need to pass this under the proposed rules rather than the existing ones though, otherwise we'll stall completely.

Floppy

@Floppy - about 9 years ago

@tmtmtmtm do you think this is OK now?

tmtmtmtm

@tmtmtmtm - about 9 years ago

Hmm. I suspect that someone looking at it fresh will likely be very confused as to why the 'hand' is a -1 count, and the '-1' is a halt...

Floppy

@Floppy - about 9 years ago

That's true, but unless we integrate to a more complex voting system, that's probably the best we can do. Unless we change block to something like :x:, perhaps.

tmtmtmtm

@tmtmtmtm - about 9 years ago

By 'more complex', you mean for the voter? Or for the code of the votebot? It's certainly not ideal to reverse the meanings, but if we were to do so, then now is likely to be better than at any time in the future. Making '-1' actually mean -1, and then taking 'hand' or 'X' to mean stop seems like it could avoid significant confusion later, and (with suitable handwaving) could be handled with date conditionals in the code for a while.

Floppy

@Floppy - about 9 years ago

I meant something like Loomio. I don't mind complex code in the votebot. I'd rather have a new set of symbols to avoid confusion though, especially when reading back. Do you think we could proceed with the current symbols to get the rules in place, and change the symbols as a separate PR?

tmtmtmtm

@tmtmtmtm - about 9 years ago

Ah, gotcha. That's a good point about being able to read historic PRs, so a slightly hesitant πŸ‘ for now from me[1]. It would be good if we could produce a list of changes that will be affected by this, before merging though, so that people have a flurry of activity on ones that people have forgotten about.

[1] Aside from the oddness of the back-to-front signals, I'm also a little concerned that to "make things move more quickly" is potentially a step in the wrong direction. But I'm not sure how much of that is simply to do with mismatched expectations as to what a process like this should (IMO) be, and my thoughts on this aren't quite coherent enough yet to really express them in any detail. But I can live with that for now :)

digitalWestie

@digitalWestie - about 9 years ago

Seems legit πŸ‘

philipjohn

@philipjohn - about 9 years ago

Pinging @yellowgopher @rufflemuffin @BenTrimble @frabcus as we just need another vote or two to get this in (if you agree)!

yellowgopher

@yellowgopher - about 9 years ago

OK, sounds reasonable to me. Need to get my head around this. Can I vote? Thought I wasn't eligible yet...!

yellowgopher

@yellowgopher - about 9 years ago

OK, sounds reasonable to me. Need to get my head around this. Can I vote? Thought I wasn't eligible yet...!

philipjohn

@philipjohn - about 9 years ago

@yellowgopher My mistake, looks like you don't have an accepted proposal yet :(

Floppy

@Floppy - about 9 years ago

We have 4 votes out of 5 needed for this, but the fact we can't get another one to just shows how necessary it is. I'm going to be controversial and merge this with the 4 votes we have now, given that we've had a good debate and there is no opposition that we can get people to express. Will do so in a few hours, so you have chance to object to my blatant subversion of democracy.

Floppy

@Floppy - about 9 years ago

@mikera I thought you'd left us forever :smile:, but if you're around, I'd love to get your vote on this proposal to change the voting rules. We're slowing down a bit here, and need to re-inject some agility and energy!

mikera

@mikera - about 9 years ago

πŸ‘ I generally think getting changes in faster and iterating is a good idea.

Floppy

@Floppy - about 9 years ago

BOOM. And we're done. Thanks @mikera.