Vote on Code Changes

Jump to: navigation, search

Code changes to a PEG use a system of voting similar to Apache Foundation. Voting on code changes is somewhat different between buildable and feature branches.

How do I know about code change votes?[edit]

The best way to know of code changes is to watch the PEG repository on Github. The Github notification system is flexible and allows you to decide which repository events (pull-requests, pull-request comments, merges, etc) you'd like to be notified of.

Another way to know of code change votes is to join the mailing list for a given PEG. Code changes must be announced on the list if the branch being merged to is a buildable branch and may be announced on the list if the branch being merged to is a feature branch.

How do I vote on code-changes if[edit]

...the proposed change is on a buildable branch[edit]

Proposed changes on buildable branches follow the review-then-merge system. In review-then-merge, you would post your vote on the pull request page on Github. The instructions for voting are at How to vote.

...the proposed change is on a feature branch[edit]

Changes to a feature branch follow the merge-then-review system. In such a case, if a pull request is proposed by a non-committer, it will be handled as if it were a pull request on a buildable branch (see last section). If the pull request is proposed by a committer, they can choose to merge the pull request immediately without consulting the community. In that case, a community member may bring up concerns on the mailing list or the now merged pull request. If the community member is not satisfied with the result, the community member may veto the change on the mailing list using the instructions on how to vote.

How to vote[edit]

No matter whether you're voting on a pull request, or on the mailing list, please put your numerical vote at the beginning of your message. Additionally, put your reasoning after that in the same message.

Votes are represented as numbers between -1 and +1, with -1 meaning 'no' and +1 meaning 'yes.' -1 is treated as a veto if a technical or community-related reason is provided.

Examples of valid reasons for -1:

  • "This patch will break compatibility even though we previously said we wouldn't"
  • "This patch doesn't build"
  • "The documentation and name for function 'punch_a_martian' is insulting to martians" (substitute another group)
  • "The patch doesn't follow our coding guidelines"

Example of invalid reasons for -1:

  • "I don't like the person who submitted the patch."
  • "I'm having a bad day"
  • "This contradicts with internal plans of my employer"

The in-between values are indicative of how strongly the voting individual feels. Here are some examples of fractional votes and ways in which they might be intended and interpreted:

  • +0: 'I don't feel strongly about it, but I'm okay with this.'
  • -0: 'I won't get in the way, but I'd rather we didn't do this.'
  • -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.'
  • ++1: 'Wow! I like this! Let's do it!'
  • -0.9: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.'
  • +0.9: 'This is a cool idea and I like it, but I don't have time/the skills necessary to help out.'

The content of this page is licensed under the Apache 2 License

The content of this page is a derivative work of [1], Copyright © 2012 The Apache Software Foundation.