Last modified by Vincent Massol on 2024/01/19 11:54

Core Committers (a.k.a simply Committers in the rest of this page) are long standing contributors who have been voted in to a level with more responsibilities to the XWiki project. They are interested in the XWiki project over the long run (this is different from a contributor who might be interested in contributing a fix to XWiki in order to help him using XWiki on a particular project). Committers are the people ensuring that the project is healthy and goes in the right direction.

The list of committers is available in the Hall of Fame.

Roles and Responsibilities of Committers

  • Committers must follow all the practices and rules defined inside the Dev wiki.
  • Committers are committers in the xwiki organization on GitHub, meaning they have write access to the source repositories there (see also source repository).
  • Committers must do a best effort of watching/doing code reviews of everything that goes in the source repository and ensure it’s of good quality, follows the development practices, and matches with the direction of the project
  • Committers must do a best effort of accepting Pull Requests (PRs) from contributors, reviewing them and when they are satisfied the quality and relevance are good enough, applying them.
  • Committers must do a best effort of following and participating to the XWiki discussions. They must answer when there are votes posted (identified with the vote tag in the forum topic). See the voting section below.
  • Committers can (and should) propose to vote in new committers when they identify a contributor they judge adequate for the role. In which case they should send a vote to the committers list, proposing the new committer and explaining why that person is fit to become a committer in their opinion.
  • Committers must do a best effort of participating to project duties, such as being a Release Manager or a Build Manager.


In general votes should be sent in case of big changes (whether it's about code or about processes or people). A vote is mandatory for voting in new committers or from removing committers. It's not necessary to send a vote when performing minor or even sometimes substantial modifications provided the author judges everyone would agree to them. This is called lazy consensus. However should someone objects to the code committed, the author must then be prepared to revert it if asked.

  • A successful vote must have at least 3 committers answering
  • Votes are carried for 72 hours by default. This is the minimum we allow. However, a longer period can be specified if defined explicitly in the vote itself. The votes are tallied after the time has elapsed.
  • A summary email containing the result of the vote must be sent by the person proposing the vote after the 72 hours have expired
  • Contributors can vote but their vote is only indicative and not binding
  • Committers must vote as part of their duties
  • There are several possible votes:
    • +1 -> I agree and I'll help as I can
    •  0 -> I'm ok but I'm letting the others decide and I'll be happy with whatever the outcome is
    • -1 -> I'm against it and I veto the change
  • A vote cannot pass if a committer has voted -1. In that case the proponent should try to explain his rational to the vetoer and try to convince him/her to remove the veto. Possibly the proposal should also be reviewed and changed.

Active Committers

A committer is considered active if he/she's been committing at least once in the past rolling year, in one of the repositories of the xwiki organization on GitHub.

Emeritus Committers

If a committer is no longer active his status can be changed (with his agreement) to emeritus. This means that he'll no longer have write access to the repository and his votes will be non binding. However, it also means that if at any point in the future he wants to contribute again to the XWiki project he'll just have to ask to get his rights back (without going through a vote).

The rationale behind the emeritus status is that non-active committers make it more difficult to reach consensus in decisions as they are expected to vote and take part in discussions and they won't if they're not active in the project anymore.

How to become a Committer

Here's a good strategy to be voted in as a committer:

  • Start contributing
  • Send lots of good PRs. A good PR is a PR that applies cleanly, meaning that the committer who applies your PR doesn't have to do extra work like add documentation not provided, rework the code because it's of poor quality, add unit tests not provided, etc (yes we know the current XWiki code is currently subpar in these domains but we'd like to change this going forward! ;-)).
  • Show dedication and interest for XWiki over the long run. You must be interested in the project itself and not simply on fixing something because you need it for one of your projects. If this is the case then PRs should be good enough.
  • After some time, the current committers applying your PRs will get fed up applying them and if they're of good quality you'll be proposed to become a committer.

Active Contributors

Becoming a committer might take time, and if you're an active contributor doing lots of pull request you might want to have a bit more capabilities on Github, like being able to request for reviews or to handle labels on your pull request. We created a dedicated Active Contributors team on Github specifically for that, you can request to be added in that team if you've opened several pull requests. We will remove people from that team once they are committers or if they stopped contributing in the past year.

Checklist to add a new committer

It's the time of year when you need to add a new committer (hurray!), let's get on to it then:

Get Connected