Update contributing.md

Proposer
frankieroberto
State

Accepted

Vote Score

0

Age

3615 days


@frankieroberto edited contributing.md - almost 10 years ago

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.

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

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.

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.

frankieroberto

@frankieroberto - almost 10 years ago

I'd like to see a minimum period for proposals to remain open for discussion before being merged, to give people more time to contribute.

Floppy

@Floppy - almost 10 years ago

This is a good idea, but I do worry that a 1-month minimum will mean it's impossible to make quick progress. That sort of thing will kill momentum, I expect. Can we find a middle ground perhaps? I'm not dismissing this, but we need to consider the optimum period.

Incidentally, @frankieroberto, a question. Are you watching the repository - do you get emails about new PRs, etc? I suspect most contributors aren't, so don't see the changes coming by.

PaulJRobinson

@PaulJRobinson - almost 10 years ago

I'd be happier with a week. Anything more than that will indeed be too sluggish.

On 7 May 2014 08:13, James Smith [email protected] wrote:

This is a good idea, but I do worry that a 1-month minimum will mean it's impossible to make quick progress. That sort of thing will kill momentum, I expect. Can we find a middle ground perhaps? I'm not dismissing this, but we need to consider the optimum period.

Incidentally, @frankieroberto https://github.com/frankieroberto, a question. Are you watching the repository - do you get emails about new PRs, etc? I suspect most contributors aren't, so don't see the changes coming by.

— Reply to this email directly or view it on GitHubhttps://github.com/openpolitics/manifesto/pull/183#issuecomment-42396286 .

frankieroberto

@frankieroberto - almost 10 years ago

@Floppy I turned off the e-mail notifications as my inbox is too noisy. Need to find a way to get push notifications to desktop instead.

I don't think we should measure progress/momentum by how quickly stuff gets merged. For me the real value is in the discussions rather than the output.

That said, perhaps a fortnight is a reasonable compromise – people often go away for a week's holiday, so that feels too short to me.

philipjohn

@philipjohn - almost 10 years ago

We've already had plenty of instances where we've had to go back through PRs that have been 'forgotten' due to a lack of activity so it's not so much a problem of momentum I think, but the risk that a waiting period could lead to more forgotten PRs.

A 'grace period' may be useful so that folks who don't pass by as often get the chance to look at, and vote on, stuff that's been given the thumbs up.

Is there the ability, @Floppy to have some kind of alerts system (probably e-mail) that let's contributors know when a PR has received enough votes to be merged, that encourages them to make sure they cast their vote within X timeframe before it merges? Could we also allow folks to sign up to these alerts before they've contributed, encouraging participation?

frankieroberto

@frankieroberto - almost 10 years ago

Perhaps the simplest thing is to set a guideline for a minimum length of time since the last comment? That's easy to check, and means that once consensus has been reached, and the conversation tailed off, the PR can be merged.

Floppy

@Floppy - almost 10 years ago

Can we change this to 14 days since last comment? I think we would be happy with that.

Floppy

@Floppy - almost 10 years ago

Loomio's default period is 3 days, but I'm assuming that everyone is explicitly notified that votes are required. It would be nice to move over there, but are we happy to make the period 14 days in the interim?

philipjohn

@philipjohn - almost 10 years ago

👍 sounds good

frankieroberto

@frankieroberto - almost 10 years ago

Sounds good to me too.

Floppy

@Floppy - almost 10 years ago

@frankieroberto nice one - want to update your branch and I'll merge in?

@frankieroberto edited contributing.md - almost 10 years ago

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.

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

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.

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.

Floppy

@Floppy - over 9 years ago

The votebot now only marks things as passed and safe to merge after 14 days have passed.