Open Governance Roles and Responsibilities

Last week, in my blog on the Maturity Level List and in the previous week's Maturity Levels, I left some indications of what would be expected of a maintainer of a portion of the Qt codebase. In this blog I'd like to explain a bit more what's expected of people working via the Qt Open Governance, what roles will exist and what responsibilities will each have.

In short, there will be three levels only:

1. Contributor
2. Approver
3. Maintainer

The presence of a "Chief Maintainer" is not exactly a fourth level. More on that below.

Outside inspiration

For the Qt Open Source project, we set out with an idea that we wanted a very flat, very simple structure. The discussion on the mailing list was quite interesting, as we had in the beginning a top structure called a "board" or "oversight committee" (some early material I prepared included the recommendation: find a cheesy, non-sensical name out of a spy movie or series, like "Directorate", "Oversight", "Headquarters", etc.) But in the end we decided to replace this and focus on existing examples of successful, large Open Source projects.

The two we mostly looked at were WebKit and the Linux kernel. There are benefits and drawbacks to both and we don't think either would apply as-is. For Qt, we wanted to combine the best practices of each. We wanted to use the trust networks and use distributed development, but keep the number of hops between a new contributor and the code being in the final repository quite low. We also have a very aggressive regression testing and continuous integration system, which puts strong emphasis on quality.

The model I'm presenting here was discussed for a long time, but eventually it took one long IRC session between myself and Robin Burchell to put the ideas on paper. We posted all of our conclusions to the opengov mailing list then adjusted a little as the discussion required.

The Qt model

So we settled on basically two roles in addition to the contributor, as you can see in the drawing. The Contributor is anyone who has the will and skill to contribute to the project. I should also point out that contributions come in many forms, not just code, but that's what I'm focusing on here. The Contributor starts the process by doing the contribution over a code review tool we'll make available and use ourselves too for our own work (more on the tool on another blog). Once this contribution is in, anyone can make comments, offer opinions, suggest improvements, etc. It is not necessary to have achieved any higher level to participate.

The next level is the Approver, which matches WebKit's reviewer level. The Approver is a Contributor who has been given the right to approve a contribution for integration into the source code. Along with that right, he/she has the duty to ensure that the contribution follows certain guidelines, both quantitative, objective (the "Technical Fit") as well as qualitative and subjective (the "Spirit Fit"). The Approver also has the duty to be constructive when offering suggestions and even when rejecting. To become an Approver, a Contributor must basically earn the right, by making contributions and proving that he/she has the best interest of the project at heart. An existing Approver should nominate, another Approver second it and, provided there are no objections, the rights are given.

Rights easily given are also easily taken away. Approvers are expected to act in the best interests of the project, regardless of their work affiliation. They are given the approval rights over the entire codebase, but they are expected to exercise them with care, concentrating on the parts where they have knowledge about. Abuse is punished by the community by revoking those rights -- in my experience of Open Source projects, this happens very, very seldom.

In most circumstances, this is all there is to it. A contribution is made, reviewed by one or more people, an Approver, who may or may not be one of the reviewers, approves the contribution, and then the continuous integration system should take it away, test and integrate into the codebase. This is where we are supposed to be very close to the WebKit model.

So where does the Maintainer come in? Well, the Maintainer is a respected member of the community who knows quite well the code in question. Unlike the Approvers, the Maintainers are tied to the code. A Maintainer basically has one duty and one right to the particular codebase he/she's maintaining:

• The duty: ensure that the codebase is always ready for beta. That is, ensure that all contributions coming in are in the proper state to start the release process at any time (tested, stable, feature-complete, documented, API reviewed, etc.), ensure that the code is in that state all the time.
• The right: set future direction, reject contributions not following that directive (including removing code already approved because it isn't stable or finished), etc.

Along with those, there are other duties, like knowing what projects are happening in that module, offering advice to people who want to contribute new features to that module and ensuring that all contributions are reviewed (so they have to review if no one else does). Moreover, Maintainers are the people whom QA and the Release Team will contact in case something is wrong.

As the codebase grows, the need for new Maintainers will appear, so we always keep a healthy number of them. That is, we should have as many Maintainers as are really required to execute the job comfortably -- but no more. It is my expectation that whenever that happens, there will be a natural candidate for Maintainer: someone who is already mostly doing that job of counselling and oversight of the codebase. Another case for a person becoming a Maintainer is when the previous one is no longer doing the job properly, either because of lack of time and/or interest, or because the actions being taken are not in the best interest of the project.

Maintainers can, of course, delegate. As an example, imagine QtCore is a module and it has a Maintainer. This person may delegate all of the Tools and Containers subsystem to a person of his trust, while he/she focuses on another part of the module. It's important to note that this is a trust-based relationship: the actions of the sub-maintainer reflect on the Maintainer. Big modules like Qt 5's "qtbase" will have several maintainers dividing the work.

The Chief Maintainer is not to be understood as a fourth level in the structure. The Chief Maintainer is a Maintainer like the others (we're expecting this to be the Maintainer of the "qtbase" module, in fact). Instead, this person should be regarded as primus inter pares: a person whose opinion matters a great deal to the project, due to past and present contributions. Therefore, this person is accorded the right to break bigger stalemates and make overarching decisions. This person is recognised as such, which is why we're singling him/her out here.

You may be asking who will be allowed to fill in those roles. They are all open to anyone who shows merit, deserving to be in that capacity, regardless of work affiliation. However, when we go live, we will "bootstrap" the model with the people who are already working on Qt: that is, the Trolls and existing contributors. The names of the people should come naturally, but to be on the safe side we should allow for an adjustment period. Also, it's clear that the "bootstrap" will include mostly current Nokia employees. As time progresses, we expect non-Nokians to join in and participate, earning responsibilities.

A final note on other roles: the above description is really focused on the code workflow, which is what happens for virtually every Open Source project out there. But in addition to the above roles, there will be many other roles to make the project tick, like the QA team, the documentation team, the Release Management team, Community Management, communications and web presence, roadmapping and planning, etc. Each of those teams will probably work with just two levels: contributor and team lead (similar to the Maintainer), unless they choose otherwise. The people from Nokia currently executing those roles will be present at the Qt Contributor Summit, so we invite those interested in collaborating to talk to them and organise sessions during the summit to suggest ways of working together.