[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

New maintainer proposal



Here is the proposed procedure for handling new-maintainer requests. Any
comments are welcome of course, although I think it's pretty solid by
now.

At this stage I would also like to begin forming the new-maintainer
team; if you are a registered developer and are interested in joining
the team please mail me privately. Please put [NEW-MAINT] in the subject
so I can easily filter all your reactions. 

In general the following guidelines will be used in selecting new
members to the new-maintainer team:

- needs to have a *strong* oppinion for free software
- needs to have a *strong* oppinion for free software
- he needs to be able+willing to make long distance phone calls
- He needs to know what he's doing, that new people need some guidance,
  we have to prevent ourselves from trojans etc.
- we need to trust him - more than we trust *any* other active person
- He *has to* understand that new-maintainer is *more* than just
  creating dumb accounts on n machines 

Wichert.

------------------------------------------------------------------------------

New-maintainer procedure
------------------------

This text describes the procedures that are involved with accepting
new Debian maintainers. It describes all the steps that have to be
taken starting from the initial application until the final acceptance
or rejection of the application.

The procedures are based on a couple of basic ideas:
* keep the load of the new-maintainer committee as light as possible by
  involving other people
* try to help applicants as much as is reasonable
* don't focus only on maintaining packages
* make sure that applicants now what Debian is about, and agree with our
  principles.
* be as open as possible without compromising the privacy of anyone

The procedure can be divided in a couple of stages:
1. initial contact
   Here someone mails the new-maintainer ctte stating an interest to
   become a Debian developer. 
2. checking identification
   Since it is important that we know from both developers and applicants
   (since they will perform some tasks during the next stage) who they
   are and how we can contact them, we will verify the identity of the
   applicant at this stage and collect contact information.
3. `internship period'
   During this period the applicant perform some tasks under the
   guidance of a registered sponsor. This can be anything, such as
   packaging, developing Debian-specific software, writing documentation
  or other Debian-related tasks.
4. final acceptance as maintainer.
   After all the previous stages have been completed the new-maintainer
   ctte decides of the applicant will become a developers.

During any of these stages an applicant can be rejected by the
committee. (This means a sponsor cannot reject an applicant).

The new-maintainer committee can ask for help on any of these stages.
This means that they can ask people to help in checking someone's
identification to, preferably by somebody in the same time zone and/or
neighborhood. During the internship-period the committee isn't directly
at all.

Lets look at the 4 stages in more details:

Stage 1: initial contact
------------------------
This stage is the beginning of the new-maintainer procedure. If somebody
wants to become a maintainer he can submit an application request to
the new-maintainer committee stating his interest, along with a
reasoning for the interest (ie intended work to be done).

After submitting the application the applicant enters a queue, until
the committee (or one of its helpers) has the time to proceed with
stage 2. The applicant will get an status update every week stating
the size of the current queue.

Stage 2: Checking identification
--------------------------------
At this stage the committee (or one of its helpers) processes somebody
from the above mentioned queue to check the identification. If this
does not succeed for some reason (for example somebody can't be reached)
this is reported to the applicant (via email for example) and he/she
is returned to the queue.

For proper identification, we must know that the person actually exists
as the person that they say they are, that there is a known location for
that person where they can be spoken too, the persons current situation,
as well as long term contact information must be clear.

The exact way of checking the applicants identification is left to the
committee. Possible options are:
* pgp or gpg key, signed by an already registered developer
* a copy of a valid picture ID, with a valid mail correspondence
  address.

At this stage the wellknown phone-interview also takes place.

After the applicants identify has successfully been confirmed he/she
is ready to enter the next stage.

Stage 3: internship period
--------------------------
This is a new stage in the new-maintainer procedure. It is meant
to allow the applicant to prove himself. This gives us several
advantages:
* it gives us a good method to help a new maintainer with his new work
  and teach him about the Debian system (both technical and
  organizational).
* it allows us to get to know the person: is he responsive to bug reports
  or other requests, is he able to produce a quality product, and also
  very important: does he agree with our philosophy.

If the new-maintainer team is confident the applicant does not need this
(for example if a formed maintainer reapplies) this stage can be skipped.

Every applicant gets a single sponsor who help him through this stage.
The sponsor is responsible for verifying the work done by the applicant
and acts as a proxy, since the applicant will not have direct access to
Debian systems himself. Feedback on the work done by the applicant
should be sent to both the applicant and the sponsor (perhaps we could
setup a applicant@sponsor.debian.org address for this?). This allows the
applicant to directly experience what being a maintainer will be like,
while the sponsor can keep track of the work done by the applicant.

The committee can create a checklist with items the sponsor has to
check before allowing an applicant to advance to the next stage. This
can include things as `confirm the applicant knows how to create a
proper package', `confirm the applicant is familiar with the
constitution', or `make sure the applicant is familiar with the DFSG
and its implications'.

If a sponsor is not immediately available the applicant enters a
queue, which is handled in the same manner as the queue between stages
1 and 2.

A sponsor can sponsor multiple applicants at the same time. The
new-maintainer committee is responsible for making sure that sponsors
act correctly and will assign applicants to sponsors if an applicant
doesn't already have one.

Once the sponsor considers the applicant ready to become a full
maintainer (and the optional checklist has been finished) he can
request the new-maintainer committee to make the applicant a full
maintainer. This is done by sending a report on the internship to
the committee.

This stage will last at most 1 month, starting from the moment a sponsor
has been assigned to the applicant.

Stage 4: final acceptance
-------------------------
After all the previous stages have been finished we know who the
applicant is, we know that he knows what being a maintainer is all
about and is ready to become a real maintainer.

At this stage the new-maintainer committee has to review the report
made by the sponsor, and can ask the sponsor and the applicant for
more information if it desires.

When the committee reaches a decision it will inform both the applicant
and the Debian developers of the result. For the developers this will
be done in a weekly report send to debian-private which lists the name
of the (former) applicant and the decision.

-- 
   ________________________________________________________________
 / Generally uninteresting signature - ignore at your convenience  \
| wichert@liacs.nl                    http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Attachment: pgpp7sd7OLeB2.pgp
Description: PGP signature


Reply to: