Heya, Problems with the New Maintainer process have been a regular topic on Debian mailing lists in the past few months. As I'm both interested in not reading more flamewars and actually improving things, I've summarized my experiences and tried to come up with something that is perhaps able to fix most of the problems. Please note that this is *my* opinion, not something decided by the NM team.
1. Current situation ==================== The New Maintainer process hasn't changed in the last few years, so I'm not really willing to come up with a description of the involved procedures. For reference, see the official documentation in the Debian New Maintainer Corner [1] and the excellent introduction given in the talk Hanna Wallach, Moray Allan and Dafydd Harries held last year [2]. 1.1 Known problems ------------------ As Debian consists of volunteers, we have to work with an ever-shifting amount of free time the involved parties are willing to invest. This is not always based on a lack of free time, but also on demotivation, often so-called burn-out syndrome caused by repetitive procedures and a lack of positive variety. 1.1.1 Applicants ~~~~~~~~~~~~~~~~ Quite a lot of applicants are frustrated by the NM process. The reason for this are mostly unresponsive AMs, waiting for AM assignment or waiting for FD/DAM approval. This has become worse in the past few months, mostly because our mailing list archives show applicants that they're not alone with their problems, but nearly nothing has been done to improve the situation. Some applicants start the NM process with a wrong impression of the amount of time needed to finish successfully. This is part of the reason for the high number of people that are set on hold and eventually rejected by their AMs. They also block AMs, as it needs some time to identify this type of applicant. A larger group of applicants isn't really fit to be a DD (yet). The last year has shown an improving number of people applying early, both because it's a well-known fact that AM assignment needs another 6 months after the initial application and because they're urged to do so by their sponsors and advocates. These people show a lack of knowledge in basic parts of the P&P checks and are usually not able to keep proper care of their packages, which comes up in the packaging check at the very end of the process. Luckily, the group of people that are just applying to get a cool @debian.org address is quite small. 1.1.2 Application Managers ~~~~~~~~~~~~~~~~~~~~~~~~~~ The lack of free Application Managers that led to the accumulation of applicants waiting for an AM is mostly based on the fact that many developers don't care about the NM process, so only a few people are actually helping out. These few people are normally quite active developers in other areas of the project, so their time resources are limited. They are also often bored by the usual questionnaire/answer games with applicants. A lack of motivation also affects the actual processing of applications, AMs are sometimes unresponsive in regard to NM things because they're too frustrated to actually sit down and finish the applications for NM they've accepted. They also don't reflect on this unresponsiveness and (almost) never ask for help or a substitute. The problems with applicants discussed above often frustrate AMs and add to the load of the NM process. 1.1.3 Front Desk ~~~~~~~~~~~~~~~~ That one's easy. Brian has not much time, I'm bored by reading the same answers over and over and over again. Also, the amount of time I'm able to invest fluctuates, as my studies sometimes take up quite a lot of time (usually right before exams...) 1.1.4 Debian Account Managers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The situation in this area has improved after Joerg Jaspert was added as new DAM, but his free time is also limited, while he keeps amassing other important jobs in the project. There is no urgent need to do something, but in the long term, another developer should be found to help out. 1.1.5 Template-driven, uniform and *boring* checks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We encouraged AMs to use templates for communication with their applicants, to ensure that certain areas are covered by the questions. The downside is that the templates have grown to full-blown questionnaires, with questions often not fitting to the particular situation of NMs. It's not the most interesting way of showing your knowledge, also taking time for research and actual writing of the answers which could be used for projects useful for Debian. These templates have been the cause for some flamewars in the recent past. 1.2 Already proposed solutions ------------------------------ Discussions in the past have lead to some proposals in this area, a short summary seems in order to point out problems. 1.2.1 Add more people ~~~~~~~~~~~~~~~~~~~~~ Adding more people to all teams has been proposed more than once, though it was never clear who's actually willing and able to do the work. Assuming that these people could be found, this proposal would still not fix all problems we have to face. The NM checks wouldn't become a big oh-nice-and-how-motivating thing, but would still be boring. After some time, our new AMs will also become frustrated, so new people would need to be found. Still, as a short-time solution, this would work - assuming there are dozens of people who can't wait to help out with the NM process, but have not yet shown this interest. 1.2.2 Fewer checks ~~~~~~~~~~~~~~~~~~ The number of questions in the normally used NM templates and their obscurity is something often remarked on, so it was proposed to remove some of these questions and shorten the NM process. This is only a partial solution and wouldn't help much with most of the things I've listed above. 1.2.3 Drop Front Desk/merge with DAM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The opinion that the FD check of reports is not needed has been presented more than once. Assuming this would be a real possibility, it would leave the problems not related to the DAM/FD unfixed. 1.2.4 Task-based checks ~~~~~~~~~~~~~~~~~~~~~~~ Some people, including me, have discussed the possibility to use a task-based approach to the NM process. As far as I know, I'm the only AM who has actually finished this with an applicant. It was an interesting experience, more challenging for applicant and AM than the usual templates, but the amount of time needed for it is enormous. Also, it misses the best feature of the NM templates - comparability. Each applicant takes on other tasks, with other demands. After doing this once, I'd not recommend it as a regular replacement for the checks based NM templates we use at the moment, mostly because of its time needs. 1.2.5 More than one AM per applicant ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the recent past, people suggested to "share" applicants between a number of AMs, and/or assign a certain part of the questions to AMs who are experienced in that area. Looking at the current problems with AMs, this will not reduce the load, but add more load, as every one of the respective application managers needs to follow the application process to notice when he's needed. Also, we've experienced in the past that team work on boring tasks lead to a distribution of responsibility, to a degree that no one felt responsible. In conclusion, this may solve the problems applicants have with unresponsive AMs, but increases the load on the whole NM team. 1.2.6 Web-based checks ~~~~~~~~~~~~~~~~~~~~~~ It was proposed to change the NM process to be based on simple HTML pages with some forms, checking for some things. This makes it quite easy to "cheat". Also, our current checks include a lot of free writing, discussing matters of philosophy, which won't be possible in a fully automatic system. The current questions also allow to educate NMs in areas they don't know much about. 2. Possible solutions ===================== As shown above, the proposals made in the past would solve our problems only partially, so we should probably think of something else. 2.1 Multiple advocates ---------------------- Ask for more than one advocate (at the moment, I'm thinking about two). This should get the number of people advocated with a "Errr, I met him, he seemed nice" down. At the same time, encourage prospective advocates no to advocate too fast. Also, two advocates are not a problem for someone who should apply in the NM queue - if there is only one project member who's willing to advocate you, something is foul anyway. 2.2 Requiring (more) work before applying ----------------------------------------- At the moment, we ask applicants for some proof of their work. This can be packaging or some documentation they've written, translations or something like that. Anyway, for packagers, we require one package at the moment. This has become a problem, as some applicants have done one upload and believe that their contribution is done with that. In the future, I would like to change to clear rules. For packagers, these would look a bit like this: * At least two packages in the archive (or one that is big enough such that it requires substantial repeated maintenance work), or equivalently, co-maintaining packages. * Long-time commitment: At least 6 months of continuous (i.e. repeated) contribution (e.g. own uploads, BTS activity, etc.) For other contributions, I want to ask active developers in those areas about possible rules. This would reduce the number of people who apply before having the needed experience to finish the checks. These people usually need much time to finish or are rejected after some time, so reducing their number should free AM resources. Implementing this could be helped by more clear requirements in the application form, together with a free-form text-field where applicants can explain what they're doing and what their plans are. 2.3 Separate upload permissions, system accounts and voting rights ------------------------------------------------------------------ This one is a long-time goal. There's a discussion about this at the moment anyway, but the problem is known for a long time. By splitting these three things apart, we gain a lot of flexibility and could solve things like sponsoring on the way. This is mainly based on a proposal Anthony Towns made to me in private. The big idea is to split the NM process up and add privileges after each step, so that people don't need to go through the whole process to maintain their two pet packages on their own anymore. The current sponsoring process encourages this, as the work invested in getting a DD to sponsor a package is often greater than the actual package maintenance. For the first stage, applicants need to identify themselves and speak about the Social Contract, the DFSG and a bit about Debian's structure. For package maintainers, an intensive package check follows. If everything went fine, these people get upload permissions for *these* packages (and nothing else). If they want to adopt new packages, their AM does a package-check once and fitting upload permissions are added. We may need to create tools to automate this, as it could become quite much work for the DAM. For translators and documentation NMs, a check if they're able to work with the used tools (debiandoc, docbook, revision control systems, .po files, ...) should follow. If their work looks fine, write access to fitting source repositories should be made available to them. For the next stage, a more intensive check needs to be done. This should cover working with the BTS for everyone. For package maintainers, parts of the current P&P and T&S questions should be recycled for this stage, while doc-NMs could get more advanced questions from the first stage. Work done since finishing the first stage should be thoroughly checked. To get actually useful data for this, we could make it mandatory to wait 3 or 6 months between the first and the second stage. After finishing this part, packagers could get full upload rights (so they can sponsor, NMU, ...) - I'm not sure what doc-NMs need at this point, as write access is normally everything they need. Everybody should get the right to vote at this point. Anyway, actual system accounts could either be given out at this stage or after another set of checks, though I don't see a reason to allow people to upload everything, but not log in on Debian boxes... This part is *very* experimental, I'd love to hear other people's opinions, suggestions and changes. I'm really not convinced that this is the perfect solution, but it has some very nice aspects. 3. Conclusions ============== Discussions about NM stuff in the past often happened without relevant people taking part. This has lead to proposals for solutions that often ignored the actual situation. I hope to avoid this problem with this mail, describing the problem from a position that gives a quite good overview. I'd like to have an open discussion about my summary and the proposed solutions, with not too many flames. So, please read what other people have already posted before replying yourself, remember that all people discussing this issues are trying to help in their *free* time and avoid purely polemic replies. I'd like to implement the proposals I made in (2.1) and (2.2) as fast as possible, especially applying the rules in (2.2) to people already in the queue waiting for an AM. (2.3) is, as I said, a long-term thingy - it would be nice if it could happen at some point, but many details are not yet worked out, the infrastructure needs to be changed for it and we really need to decide if this is actually a good way. Marc Footnotes: [1] http://www.debian.org/devel/join/ [2] http://www.srcf.ucam.org/~hmw26/publications/debconf5.pdf
pgpV3hHXqjPXW.pgp
Description: PGP signature
