On Wed, Nov 19, 2014 at 11:37:25AM +0100, Lucas Nussbaum wrote: > On 18/11/14 at 21:49 +0100, Stefano Zacchiroli wrote: > > + 5. A Developer is not eligible to be (re)appointed to the Technical > > + Committee if they have been a member within the previous 12 months. > > Even if the possibility is open, I doubt that many expired TC members > will actually re-apply the year after their expiration. The message sent > by the project is quite clear: they should probably do something else.
I disagree that that would be the message that the project send to CTTE members when they hit the term limit. There is nothing *personal* in a term limit, it's a common sense rule to ensure turn-over. Nothing more, nothing less. I do understand that *current* CTTE members might, in theory, take this GR the wrong way and think that it is a GR against them personally. (This is in fact why I do plan, as mentioned before, to explicitly invite CTTE members to get involved in this discussion once the landscape of proposals on the table has clarified.) If that were to happen, you're probably correct on the fact that those members will probably not apply again. My only answer here is that we should do our best to convey to them the rationale behind this change in the abstract. (Which is also why I try hard not to look at, or think of, the seniority ranking among current CTTE members.) But once the rule is agreed upon, I do not see why anyone should take reaching the term limit badly. It seems to me that the year off is a win-win scenario for all involved actors. The senior member get a chance of reassessing whether they want to keep on working with CTTE stuff without the social awkwardness of having to explain why they step down. If they come back, the rest of the CTTE and the DPL get a chance to reassess whether the reapplying member would still be a good fit for the CTTE and the Project. If they do not come back, then probably they should have stepped down more or less at the same time anyhow and, once again, we have spared them some social awkwardness. > On the other hand, the TC is the kind of committee where it's useful > to have members with quite a lot of memory about past decisions (and > possibly, mistakes). There's not so much activity (well, in general), > so experience builds up slowly. Also, even if there's a correlation in > general between age and ossification, we could have older members that > manage to stay young, active, and generally useful to the TC. Fine. We will then just offer them 1 year of vacation from CTTE duties every now and then, I believe many people in other Debian core teams dream of that :-) > I fear that, by reducing the average 'age' from 7.8 years to ~2 years, > we are going too far. I would like to make it easier, for some members, > to stay members of the TC for longer than 4 years. OTOH, I don't want > this decision to be taken lightly. Again, this is true only under the assumption that former members won't come back. But even with that assumption, it seems you're arguing for the fact that a term limit of 4.5 years (and therefore an average of about half of that, modulo the transition period) is too short. It's hard to judge that in the abstract, but my gut feeling is that it is in fact quite long. Volunteers, especially when active in stress-full roles, do need shorter cycles. > I'm not sure of how to achieve that. We could just drop the mandatory > vacation clause, and have expired TC members go through the same > process as prospective new members (nomination, etc.). The TC and the > DPL would then have to consider whether it's better to re-appoint an > old member, or to replace him/her with a new one. But maybe that's not > enough to ensure the suitable rate of change... > > What do you think? I see where you are going, but all in all it seems to me you have in mind a different model from what has been now distilled in the current draft. Which is of course absolutely fine. I'd love to see a more complete sketch of your model (e.g., as a draft GR) to better compare and contrast. Maybe the best way forward here is to come up with alternative models and have all of them in a GR. Cheers. -- Stefano Zacchiroli . . . . . . . z...@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 »
signature.asc
Description: Digital signature
