Debian-news is about one simple thing - news about Debian GNU/Linux and the top free distributions based on Debian GNU/Linux.


 

Reforming the NM process

Marc Brockschmidt has made a request for reforming the the New Maintainer process for Debian develoopers.
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

No Response to “Reforming the NM process” »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Debian-News is not related to the Debian Project.
All logos and trademarks on this site are property of their respective owners.