Hi,
Let's start with a citation of a part of the constitution,
Project Leaders Delegates Powers:
---+++---
8.1. Powers
The Project Leader's Delegates:
1. have powers delegated to them by the Project Leader;
2. may make certain decisions which the Leader may not make directly,
including approving or expelling Developers or designating people as
Developers who do not maintain packages. This is to avoid
concentration of power, particularly over membership as a Developer,
in the hands of the Project Leader.
---+++---
This means that we, the DAMs, have the responsibility under the Constitution
to handle developer admission and expulsion. There is currently no
process for handling expulsions in cases of disciplinary problems (with
MIA-people there is a well defined process available).
Historically the power of expelling people hasn't been used much. In
fact it has only been used twice so far, both times due to violations of
the DMUP.
The following few points should give any Developer a clear guide on what
steps needs to be followed if they feel there is another Developer
who should get their account removed.
NOTE: This does *NOT* affect anything else, like immediate account
deactivation if someone loses their key, has a compromised machine or
violates the DMUP, etc.
The following doesn't even add power to the DAM-delegation, it just
formalizes a power that was always there, but mostly unused.
1. Nomination
-------------
Any existing DD[1] can propose any other Developer to be excluded from
the Project. As this is a drastic step we require a signed mail to
da-manager@debian.org which includes extensive reasoning behind the
nomination for exclusion.
We reserve the right to reject any nomination if we think the nomination
will not survive the following process or is caused by animosity between
two developers, like simple packaging disagreements.
This process is only for use in instances when someone's membership
in the project is intolerable, not for minor squabbles.
Hint: This is intended as a last resort - not the first one. Most of
the times a disagreement with someone else is a simple
misunderstanding, so please start with talking together. Or let others
help you trying to communicate. Don't start with this process, thanks.
2. Get support
--------------
The next step is to get other Developers to support your nomination.
To proceed, Q[2] developers need to support the nomination.
Constitution 7.1.1 defines the Project Secretary as the delegate who
defines Q, so everytime this process starts, secretary@debian.org is
asked for the actual number.
Supporters need to send a signed mail to da-manager@debian.org, stating
a detailed (see step 1) reason (own ones please, not simply copy&paste)
why they support the explusion of the nominee.
The time limit for this step is 2 weeks. If there are not Q supporters
after 2 weeks, this process ends.
Note: It is the duty of the nominator to get support, we will not help
you.
3. Informing nominee and the public
-----------------------------------
If the nominator gets enough supporters we will write a mail to the
nominee about it, including the names and reasons of all
people involved.
They then have up to 2 weeks to respond with their own statement,
describing their position. They are also free to gather other DDs who
send supporting statements for them to da-manager@debian.org.
The nominee can decide if they want the explusion request to be
handled publicly and if they do they can mail the debian-project
mailing list with all the details. If its decided to be non-public
either the nominee themself or we will mail the debian-private list with
details.
We will then wait additional two weeks, and any Developer is free to
send a (signed) support statement for any one of the two sides in. They
all will be taken into account in the next step. Such a statement should
be sent as a signed mail reply to the initial mail of the nominee to the
mailing list, but CCed to da-manager@debian.org to make sure we have
it. Statements sent only to da-manager@debian.org will get forwarded to
the list.
4. Decision
-----------
We will take all the arguments from both sides and decide what to
do. This will either lead to a rejection of the request which will be
sent to all involved parties with an explanation, or to the expulsion of
the nominee. Similar to the DAM-Rejections in the New-Maintainer-Process
this will be mailed to the nominee and the NM-Committee[3] with our final
decision and reasoning.
The nominee is free to reply to this mail, pointing out any flaws present
in the reasoning.
The members of the NM-Committee are also free to express their support
or their disagreement with this decision. If there is enough
disagreement within three weeks (lets say more than a third of the
active members), we will ask the project secretary to run a vote on the
subject.
5. Vote
----------
The Secretary will then start a vote about the account suspension.
Vote options are simple:
1. Support of the decision
2. Rejection of the decision
Any member of the FrontDesk and the NM-Committee can vote.
A 2:1 majority is required to overrule the DAMs decision.
6. Action
---------
If (in step 4) it was decided that the request should be rejected nothing
special happens.
If the DAM agrees to the request and decides to expel the Developer
the account, voting and upload privileges are suspended immediately. Mail
forwarding will continue to work. If there is no vote required or the
vote confirms the nomination the account will get deleted and key
completly removed from keyring. Mail forwarding will continue to work
for another 6 weeks to give the former Developer the possibility to move
its mail handling to another address.
If the vote gets the 2:1 majority to overrule the DAM decision then the
account will be unlocked and upload and voting privileges given back.
In both cases, if the nominee decided to make the discussion public,
we will inform the debian-project mailing list, otherwise the
debian-private list will get the information.
7. Timeframes for bans
----------------------
If we decide to expel a developer we will set a timeline. The
NM-Committee is free to give their input on this in the three weeks they
have to comment, but the final decision on the length is up to us.
Possible timeframes include one or more years and, in truly extreme
cases, a lifetime expulsion, depending on the impact that the actions leading
to this process may have had to the project.
If we set a time limit people are free to attempt to get back into the
project after that time passed. They will need to go through full NM.
Footnotes:
[1] Defined as having a LDAP entry of gid 800 ('Debian') and a key
associated with the account.
[2] At the time of writing this mail the secretary defined Q to be 15.
(Well, Constitution defines it, but secretary defines our actual
number of Developers, so simplify this and directly ask for Q). :)
[3] The NM-Committee is defined as:
- All members of DAM and FrontDesk.
- All application manager that are marked as active and processed at
least one NM in the last 6 months.
There is a mail alias which reaches all members, it is regularly
regenerated by FrontDesk.
--
bye Joerg
<Fubak> /msg NickServ IDENTIFY arschloch
<codebreaker> /msg nickserv ghost Fubak arschloch
-!- Fubak has quit [Nick collision from services.]
Attachment:
pgpRQ8Z9f2Iaw.pgp
Description: PGP signature