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

time-limited, auto-reinstated delegations (and reports)

[ questions for candidate below, see "Q:" ]

On Thu, Mar 27, 2014 at 10:25:44AM +0100, Lucas Nussbaum wrote:
> There are also good reasons for not keeping them in the team: they might
> be perceived as "badge collectors" by the rest of the team, or as people
> who like to express their opinion and influence the team's decisions but
> do not do the resulting work. That can have a very negative impact on
> the atmosphere inside the team.

An extra reason for not keeping [people who no longer contribute] in a
delegated team is that, if those people add up, it might give the false
impression from the outside that the team is properly staffed, whereas
in fact it is not.

> It's difficult to draw a general line, and I believe that each case
> should be examined separately, with the delegate in question, and with
> the rest of the team.

There is some sort of autarchic trait in DPL delegations that I've never
liked very much. Due to the volunteer nature of Debian and to our
understandable desire of not having the DPL "mess up" with teams, every
time the DPL delegates someone there is a risk of creating a
self-perpetrating power within the project, with potentially than
accountability than what would be the optimum.  I believe this potential
risk exists for all non time-limited delegations.

A way around that would be to use time-limited delegations *only*.
Q: What do the candidates think of that idea? If you agree it'd be good,
would do you engage in doing so for the duration of your term?

Of course there are drawbacks, for instance: 1) given time-limited
delegations are not (yet) a custom in our project, teams that have been
non time-delegated up to now might feel bad about this in the beginning;
2) the delegation bookkeeping will increase substantially (having been
there I am aware of the pain, and I can assure that it is far from being

But there are also mitigation strategies.  For (1), it is really about
growing our culture to realize that every position of power within the
project should come with accountability and periodic reporting to all
members, no excuse. And to affirm that culture we need discussions,
communication on the subject, etc.  For (2) we might have simple schemes
(and tool that implement the needed public reminders) like: at the end
of every delegated term (say 1-2 years) delegates send a report to a
dedicated mailing list (e.g. debian-reports) and express they desire to
be reinstated; barring DPL objection within a reasonable time-frame (say
1-2 weeks) they are automatically reinstated.

As "related work":

- in the Tor project --- where they do not have delegates but they do
  have people paid on project's money and they want them to be publicly
  accountable for their salaries --- they have an implementation of the
  periodic public reports ides, have a look at
  https://lists.torproject.org/pipermail/tor-reports/ . I'll probably
  never cease to admire them for that, and it's very interesting how
  much you can learn about the inner project working by following a list
  like that.

- we have had in the past similar transparency problems with the use of
  Debian money to attend/organize $event. I think we have considerably
  improved on that front with the simple reimbursement rule that
  requires to have sent a public report about $event *before* asking for
  reimbursement on project money.


Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Attachment: signature.asc
Description: Digital signature

Reply to: