On 2013-03-28 21:54, Charles Plessy wrote:
what you wrote here presents the end of a delegation as a final point.However, I was very interested by your use of "rotation", which I wasunderstanding as a faster turnover where the responsibility of the delegation is passed through developers according to the pool of compentent people.Taking the Debian Policy Editors as example, I would not mind being replaced in October 2013, and (provided that I still have the free time), I would not mind serving again from October 2104. All of this without reducing my contribution in terms of patches, but only rotating who is responsible for committing them.
Yes, that's the kind of thing I had in mind with "rotation". The appropriate speed and exact details would depend on the time. In general, it might not be necessary to define precisely when you will rotate back in, as long as you trust that there is going to be continuing rotation out and therefore the opportunity for you to re-join in the future if you step back now.
As another example, being a DebConf Chair is a heavy job, and being active as one for too long will probably lead to burn-out, but having a large number of simultaneous Chairs with some inactive might create different problems. It might well make sense to have this kind of rotation there, perhaps with people who rotate out remaining part of the wider DebConf Committee.
So can you clarify how proactive you intend to be in terms of promoting rotation for the existing delegations ?
It's something I would like teams to consider as part of drawing up a plan for team membership turnover, but I don't intend to try to enforce a single model for all teams. Of course, in many teams a more informal kind of rotation already happens, with people just becoming inactive for a period in an ad-hoc basis. Formal rotation is probably most appropriate when there are "gatekeeper" roles as part of a larger team.
-- Moray