[ 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 negligible). 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. Thoughts? Cheers. -- 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