Re: time-limited, auto-reinstated delegations (and reports)
On 28/03/14 at 18:15 +0900, Stefano Zacchiroli wrote:
> [ 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.
Heh, that's an interesting idea.
However, it feels a bit too much like using the time-limited delegation
to "extort" something from teams. Teams must provide accountability, and
do periodic reportings, and it would be sad if the only way to get that
from teams would be through expiring delegations...
I believe that teams deficiencies and problems should be worked on with
the teams, using constructive discussion as the starting point.
That doesn't mean that I am against using more extreme mesures. But I
don't think that time-limited delegations would really help, when the
DPL can, in the extreme case, revoke the delegation for a whole team.
[ of course, there are more specific cases where time-limited
delegations are totally suitable, such as GSoC admins ]