| <?php |
| $title="Policy on Committers and Reviewers"; |
| include("../header.inc"); |
| ?> |
| <h2>WebKit Committers and Reviewer Policy</h2> |
| |
| <p>The WebKit project has two kinds of special status beyond being a |
| contributor. WebKit Committers have direct read-write access to the |
| Subversion repository, enabling them to commit changes by themselves |
| or others once reviewed. WebKit Reviewers are permitted to review |
| patches and may grant or deny approval for committing. Details of the |
| review and commit process are available |
| on the <a href="http://webkit.org/coding/contributing.html">contribution page</a>.</p> |
| |
| <p>New WebKit Committers and WebKit Reviewers will be selected by the |
| set of existing WebKit Reviewers. We will create a mailing list, |
| <<a href="mailto:webkit-reviewers@lists.webkit.org">webkit-reviewers@lists.webkit.org</a>>, |
| for this purpose.</p> |
| |
| <p>An up to date list of current WebKit Committers and WebKit |
| Reviewers will be maintained at webkit.org.</p> |
| |
| <h3>Choosing Committers and Reviewers</h3> |
| |
| <p>A candidate for WebKit Committer or WebKit Reviewer should |
| initially be nominated by a reviewer on the reviewers mailing list, in |
| accordance with the criteria below. If at least two more reviewers |
| second the nomination, then it carries within 5 business days unless |
| someone objects. If an objection is raised, the reviewers should |
| discuss the matter and try to come to consensus; failing this, the |
| matter will be decided by majority vote of the reviewers.</p> |
| |
| <p>Once someone is successfully nominated for WebKit |
| Committer status, Apple will take care of sending the committer |
| agreement and setting up a Subversion account once signed and |
| received.</p> |
| |
| <p>Once someone is successfully nominated for WebKit Reviewer status, |
| the nominating Reviewer or another responsible party should inform the |
| candidate and ask for indication of acceptance from the potential new |
| reviewer. If the candidate accepts, a notice will be posted on the |
| WebKit blog.</p> |
| |
| <h3>Criteria for Committers</h3> |
| |
| <p>A WebKit Committer should be a person we can trust to follow and |
| understand the project policies about checkins and other matters.</p> |
| |
| <p>Normally a potential Committer would be nominated once they have |
| submitted around 10-20 good patches, shown good judgment and |
| understanding of project policies, and demonstrated good collaboration |
| skills. To be nominated and seconded, they will have to interact |
| with more than one project reviewer. If someone submits many patches |
| but does not show good judgment or effective collaboration, that |
| contributor might not be nominated right away. If someone submits fewer patches than |
| this but has experience working in another WebKit-based or |
| khtml-based engine and has a track record of good collaboration with |
| the WebKit project, they may be nominated sooner.</p> |
| |
| <p>Significant contributors to testing, bug management, web site |
| content, documentation, project infrastructure and other non-code |
| areas may also be nominated, even without the normal threshold of |
| patches.</p> |
| |
| <p>A person who will be working under the supervision of a WebKit |
| reviewer on WebKit-related projects can be nominated if the reviewer |
| is willing to vouch for them and supervise them to ensure they follow |
| project policies on checkins. Supervision does not necessarily imply a |
| manager/employee relationship, just that you work with the potential |
| committer closely enough to make sure they follow policy and work well |
| with others.</p> |
| |
| <h3>Criteria for Reviewers</h3> |
| |
| <p>A WebKit Reviewer should be a person who has shown particularly |
| good judgment, understanding of project policies, collaboration |
| skills, and understanding of the code. Reviewers are expected to |
| ensure that patches they review follow project policies, and to do |
| their best to check for bugs or other problems with the patch. They |
| are also expected to show good judgment in whether or not they review |
| a patch at all, or defer to another reviewer.</p> |
| |
| <p>Typically a potential Reviewer would be nominated once they have |
| submitted around 80-120 good patches. They should also be in touch |
| with other reviewers and aware of who are the experts in various |
| areas. If someone submits fewer patches than this, but has experience |
| working in another WebKit-based or khtml-based engine and has a track |
| record of excellent collaboration with the WebKit project, they may be |
| nominated sooner.</p> |
| |
| <p>A person who submits many patches but does not show good |
| collaboration skills, code understanding or understanding of project |
| policies may never be nominated.</p> |
| |
| <p>For Reviewer status, there is no supervision exception.</p> |
| |
| <h3>Suspension and Revocation of Committer or Reviewer Status</h3> |
| |
| <p>WebKit Committer or WebKit Reviewer status can be revoked by 2/3 |
| vote of the reviewers, not including the person under consideration |
| for revocation.</p> |
| |
| <p>Someone actively damaging the repository or intentionally abusing |
| their review privilege may have it temporarily suspended on the |
| request of any two Reviewers. In such a case, the requesting Reviewers |
| should notify the webkit-reviewers list with a description of the |
| offense. At this point, Reviewer or Committer status will be |
| temporarily suspended for one week, pending outcome of the vote for |
| permanent revocation.</p> |
| <?php |
| include("../footer.inc"); |
| ?> |