Re: infrastructure team procedures (fourth edit)
Josip Rodin writes ("Re: infrastructure team procedures (fourth edit)"):
> Got it. This is an essential component of my proposal - that somebody gets
> explicitly empowered by a general resolution of the developers to handle
> problems with teams expanding; and because DPL is convenient and
> democratically elected, they seem like a good vict... targ... candidate. :)
Yes.
> I see where you're coming from on this, but I'm not sure if it will help
> unfreeze the leaders in this regard. People will still be able to complain
> that timeframes or criteria set by the leader are arbitrary and this will
> make DPLs hold back both on setting deadlines and on adding members after
> they pass.
Well, how about including an example in an appendix ? Surely it would
be better to avoid tieing the leader's and the team's hands by writing
a detailed prescription.
> > Firstly because I don't think empowering the Leader in this way is a
> > conducive to good relations with the teams.
>
> Well, how does that differ from your text above? :)
It doesn't. So just to clarify, I don't think the text I posted is
the right approach. It's the right text for your wrong approach :-).
I feel that if I'm playing draftsman for you, I should try to give
best and clearest effect to your intent. After all many of the
problems we have are people arguing about the meaning of these kinds
of texts so if they are clear and without loopholes it can save a lot
of time.
> > I think instead you should create a duty of the DPL to resolve
> > complaints.
>
> This has merit, although it's also a slippery slope because it goes beyond
> general composition issues. I'd rather start with a general recommendation
> to the leader for them to start paying attention to team compositions,
> through a verbiage that will actually accomplish what I said at the top,
> and then that will greatly alleviate the number and scope of complaints
> (this is my experience of how it works in practice).
I see. Well, just for completeness, here is a text specifying I think
would be a better approach. It gives the leader the duty to resolve
complaints within a specified timetable and a duty to propose a GR.
So it does not subordinate a team to the leader without a further
vote.
Ian.
Debian developers acknowledge the following:
1. The Debian Project infrastructure is run by people who volunteer
their time and knowledge effort to help the Debian Project.
2. Infrastructure teams are groups of developers who deal with project
infrastructure and have access to resources in ways other than
the standard practice of uploading Debian packages.
3. We thank the infrastructure teams, and their members, for their
valuable contributions.
4. Infrastructure teams should continue to run their own affairs.
5. Nevertheless, it is sometimes necessary to intervene to improve
the responsiveness of an infrastructure team to maintain a level
of service that is generally acceptable to the developer body.
Therefore we the Developers, excercising the powers of the Project
Leader and overruling the Leader if necessary, decide that:
6. Any two Developers (`the Complainants') may make a joint formal
complaint to the Project Leader about any aspect of the work of an
infrastructure team (`the Team'). Such a complaint should be made
privately.
7. The Project Leader should then discuss the matter privately with
the Complainants, the Team, and others, as the Leader sees fit.
These discussions should include a draft statement of findings
from the Leader (see 8, below), within 21 days of the complaint.
8. Within 30 days of the complaint, the Leader must email the
Complainants a statement setting out how the complaint has been
resolved. In particular, the Leader must decide between the
following outcomes, in the Leader's opinion:
a. The complaint, misunderstanding, or disagreement has now been
satisfactorily resolved. No criticism of either side is
implied.
b. The complaint has not been satisfactorily resolved but further
action would not be helpful. The Leader must make a formal
statement of the Leader's conclusions on a mailing list
readable by all Developers.
c. The complaint has not been satisfactorily resolved
and further action is necessary to resolve it. The Leader
must immediately propose a General Resolution according to the
form below, empowering the Leader.
d. More time would be valuable to resolve the dispute. The
Leader must set a new deadline, not more than 90 days from the
original complaint.
e. The complaint is totally without merit (for example because it
is vexatious, incoherent or repetitive), and does not deserve
further investigation, discussion or action.
9. If the complainants strongly disagree with the Leader's decision,
or the Leader has failed to make a decision by the deadline, the
complainants are hereby encouraged to submit a General Resolution
according to the form below, empowering one of the complainants.
10. During discussion of such a General Resolution, once proposed,
all participants are entitled to publish all of the previously
private emails from negotiations mentioned in 7. above.
11. The General Resolutions to empower are of the following form:
1. The complaints of <first complaintant> and
<second complainant> against <team>, as discussed
elsewhere, have not been resolved satisfactorily.
2. <person empowered> is therefore hereby empowered, for a
period of 60 days from the passage of this resolution, to
determine the composition and structure of the team mentioned
above. This includes adding new members, removing and
replacing existing members, deciding the new team leader, and
all similar matters.
12. If the Leader fails to make a decision within the deadline,
the complainants are encouraged to make this fact public.
A Leader who is persistently unable to decide on complaints should
resign.
Ian.
Reply to: