Dafydd Harries, Hanna Wallach, and Moray Allan gave an interesting Debconf talk on the Debian New Maintainer (NM) process and thought I would throw in my two cents. If this looks familiar, it’s because I made the second half of this argument on debian-newmaint a long time ago without much effect.
I see two major problems with NM as it stands right now:
- The idea of "developership" in Debian collapses package maintainership and membership or citizenship into single quality.
- Quite simply, NM focuses too little and too indirectly on the qualities that make good Debian developers.
At a certain point, the end result of each of these is the same: we create barriers to entry that block good developers. Some believe that the procedure also fails to block bad developers although I’m personally less concerned about that.
Developership and Citizenship
Being a Debian developer means that you have a key in the Debian keyring. This allows all developers to upload packages into Debian but also allows them to vote in General Resolutions and Project Leader elections. There is only one keyring for both of these things. Because all developers can upload packages, the process to become a developer tests packaging skills. While it is possible for non-technical folks (e.g., documentation or translations folks) to become developers, there is a understandable queasiness about adding keys to the keyring for folks who have not and do not intend to upload.
My favorite example was always Greg Pomerantz who is Debian’s lawyer. In terms of time, effort, and impact, Greg contributes to Debian more than most developers. However because he did not maintain packages and was not interested in doing so, he was not enfranchised within the Debian political system. Greg’s example is now less good because he’s started maintaining packages and jumped into the normal NM queue but I think his example highlights a serious shortcoming in the Debian system.
In Ubuntu, we have split "membership" from upload privileges. Members are people who have testimonials from trusted members of the project, who can demonstrate a history of substantial contributions, and who have agreed to our foundation documents. Membership conveys voting rights but — unlike Debian — expires with inactivity. While only members can upload, members cannot upload by default. They must first be checked off by a board of technical guardians who will look at their sponsored package history.
Now, I’m not convinced that Ubuntu’s model is the best way for Debian. However, if Debian really can’t separate uploaders from voters, I think that our NM process should test less on specifics and more for people that know their own limitations. Branden Robinson had an interesting idea I’ll let him propose on his own but I think might be a great retroactive fit for Debian.
Selecting For Quality Maintainers
On the second point, I am increasingly frustrated with the way that tasks and skills are handled in Debian. When I went through NM I was asked (and answered) exactly zero task and skills questions. I made packages, upgraded packages and fixed bugs. My work was vouched for by others and left to speak for itself.
What I ask to my NMs is similar to what was demanded of me. I ask few, if any, questions but look for, and require, active engagement with the Debian and free software communities. If people are doing good work and have great technical reviews from sponsors and are creating clean, well documented packages, and demonstrate that they know when and how to read a manual, this should be enough. I heard a talk from a famous biologist a couple years ago who told a story that went something like this:
A group of scientists bred mice so that they were really good at running through a maze. Many generations down the line the mice that made it through the rigorous breeding selection process were really good at running through the maze; but they were also partially deaf and partially blind. Partially blind and deaf mice are less distractable and are better at running through mazes. The mice were no smarter or better than other mice — just worse in a way that was helpful in the narrow case of the test.
I’m afraid the length and depth of the NM process is, in many cases, selecting for something other than competence, reliability, and knowledge of and adherence to our policy, philosophical, and quality standards. I half-jokingly believe our system is selecting for people who like researching and writing very long series of emails over people who enjoy going out and getting high quality programming work done in a consistent and reliable way.
Imagine the flame wars of the future.