On 2013-03-25 10:24, Lucas Nussbaum wrote:
In his platform, Moray writes:| I would also like us to take a more pre-emptive approach to such issues| by encouraging more turnover of members between different teams I think that most teams require quite specific skills, and most teammembers like what they do. So I'm not going to force or encourage people to move to other teams. However, I think that it is important that ourteams are sufficiently staffed so that one can leave a team without feeling guilty.
You quote here some introductory text from my platform. The paragraph that the sentence above summarised explains things a bit more:
I would encourage teams to plan ahead how they will enable a turnover of people in delegated roles. This could mean, for example, that a team defines in advance a rotation schedule that commits it to recruiting new members. It isn't healthy for team membership to stay static until too many members get bored or burn out. Our ideal should be for people to retire from roles while they are still performing them well, and then transfer their experience toother areas of the project.
You seem to be reading what I wrote as having a negative sense, where I intended a positive one. I am certainly not intending any purge of the old regime! I am not setting out to change the current delegations, but to change some aspects of our culture around teams/delegations.
Stepping down should be seen as a sign of accomplishment. It should not be seen as losing the ability to provide advice. It should be seen as an opportunity for someone to use their skills in other aspects of the project, to produce more great things. Separately but importantly, it should be seen as a healthy thing for the project.
Many questions during the campaign period have been about how to foster innovation in Debian. Every year, candidates make promises about it, but the constitution severely limits what the DPL can do. What the DPL can do is make official delegations. While delegations are good, including for transparency, a side-effect can be to make teams more static than they would otherwise be. Along with the power of delegation comes a responsibility to ensure that delegated teams continue to be dynamic.
I am not proposing to force immediate changes in team membership, since my concern isn't so much to fix specific current problems as to avoid future problems. Indeed, my suggestion that teams make plans in advance about how membership will change, at a rate they are comfortable with, is intended to *reduce* the need for direct DPL intervention to change team membership to fix problems.
For the "rotation" part of turnover in teams:Of course people who work in our teams need the appropriate skills. We already have people who become part of many different Debian teams concurrently or in series, so I don't think it's surprising to suggest that people who succeed in one team might also be able to find another team where they can help. One reason for people not wanting to leave current roles in Debian is that they will then be at a loose end. I would like us to value people who retire from delegated roles or from other teams, and to actively seek to use their experience elsewhere in the project.
-- Moray