Re: [all candidates] delegation
Gunnar Wolf gw...@gwolf.org writes: However, this topic does raise a question: Knowledge transfer. I might be arguing on something marginally related to the vote at hand, but anyway, when delegations shift (be it due to burnout, retirement, rotation or whatever), we should make it as easy as possible to transfer the acquired knowledge from the ex-delegates to the new delegates. Yep, agreed. In some teams, there's the wizard role, someone who isn't all that active anymore, but there's knowledge in his head, and he's willing to share it. I find this a great way to not loose the knowledge, while still allowing someone to move on. Writing documentation is often seen as a boring, painful task. Yet, it is a very important thing to do. So, prospective DPLs, would you see as part of the delegation the requirement for outgoing (if possible, I know it's not always the case) and incoming delegates an obligation to check and update documentation with the latest practices? I'd encourage it, yes. But would not make it a strict requirement. I value hands-on training more than written documentation in many cases (esp. when it comes to using and working with our own tools), and in that case, if I'd have to choose whether to encourage the aforementioned wizard role or writing/updating docs, I'd go with the former. This should also apply to DPL transitions, by the way. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obe27db3@galadriel.madhouse-project.org
Re: [all candidates] delegation
Thomas Goirand z...@debian.org writes: On 03/26/2013 09:28 PM, Gergely Nagy wrote: I see Zack's DPL helpers initiative as a step in this direction, and I'd like to take it a little further. How? Make it formal? Have new official positions? Or just push more people to help and that's it (which is ok too...)? I was primarily thinking about shorter term, formal delegations, for one particular task. And of course, promoting the idea further, encouraging people to participate. (Which will likely need more and better communication) -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc8b7sb9@galadriel.madhouse-project.org
Re: [all candidates] delegation
On 2013-03-25 09:55, Thomas Goirand wrote: One of the key role of the DPL is to delegate. What are your intention in this regard? Do you think that the current teams and roles are well filled? Or would you like to change some of the people currently holding a position? Why (not) changing anything? I might be able to answer more clearly if you narrowed down what teams (if any) you are thinking of. I guess that you are primarily thinking of the major technical teams that are already delegations? In that case: - I don't think that delegations to our technical teams should be political matters, so I think there should be a very clear desire for it from the project before a new DPL removes existing delegates at the start of a DPL term. I currently don't see any case where I would want to do that, though you are of course free to try to persuade me that it is needed. - In some teams I perceive there to be a shortage of available time/energy, and therefore additional delegates might be useful, but again that's not something where I would want to jump in and delegate my own preferred candidate(s) on day one. It would be rather counterproductive to take such action before working with the teams in question, as it would be likely to reduce the time/energy provided from existing team members. In my platform I wrote about some things that I think Debian teams need. Clearly I don't think that every team is doing all these things perfectly yet, or I wouldn't be focusing on this topic, but my suggestions for improving how our teams work are ones that I think any team members could follow, and aren't intended to require changing team memberships. -- Moray -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874a0c8ed0347b20be33f7db69d99...@www.morayallan.com
Re: [all candidates] delegation
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 team members 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 our teams 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 to other 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 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/998f50acb744c7eda882cc71a750a...@www.morayallan.com
Re: [all candidates] delegation
Le Thu, Mar 28, 2013 at 08:46:28PM -0600, Moray Allan a écrit : 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. Hi Moray, 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 was understanding 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. So can you clarify how proactive you intend to be in terms of promoting rotation for the existing delegations ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130329035424.ga2...@falafel.plessy.net
Re: [all candidates] delegation
Charles Plessy dijo [Fri, Mar 29, 2013 at 12:54:24PM +0900]: Hi Moray, 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 was understanding 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. I propose a toast, both for your projected longevity and for our project's! I don't see it as healthy, however, to set a period of *90 years* between stepping down from a delegated role to occupy it again. However, this topic does raise a question: Knowledge transfer. I might be arguing on something marginally related to the vote at hand, but anyway, when delegations shift (be it due to burnout, retirement, rotation or whatever), we should make it as easy as possible to transfer the acquired knowledge from the ex-delegates to the new delegates. Writing documentation is often seen as a boring, painful task. Yet, it is a very important thing to do. So, prospective DPLs, would you see as part of the delegation the requirement for outgoing (if possible, I know it's not always the case) and incoming delegates an obligation to check and update documentation with the latest practices? (yes, the question is almost trivial and somewhat silly... But lost knowledge due to insufficiently communicating team members can hurt the whole project!) -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130329043624.ga53...@gwolf.org
Re: [all candidates] delegation
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 was understanding 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 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/23da472bc13c5729e149864d0efa1...@www.morayallan.com
Re: [all candidates] delegation
I thought I'd answered everything again, but then I made the mistake of mentioning Charles's post to Gunnar Which reminds me: please tell me if I've missed a question on this list during the campaign period that you were hoping for me to answer. On 2013-03-28 22:36, Gunnar Wolf wrote: However, this topic does raise a question: Knowledge transfer. I might be arguing on something marginally related to the vote at hand, but anyway, when delegations shift (be it due to burnout, retirement, rotation or whatever), we should make it as easy as possible to transfer the acquired knowledge from the ex-delegates to the new delegates. Writing documentation is often seen as a boring, painful task. Yet, it is a very important thing to do. So, prospective DPLs, would you see as part of the delegation the requirement for outgoing (if possible, I know it's not always the case) and incoming delegates an obligation to check and update documentation with the latest practices? I definitely agree about the importance of good documentation, including within Debian teams. And it would make sense to document as part of our good-practice guidelines for teams (that I propose in my platform) that this kind of documentation is expected. But equally I'm not sure that it would be useful to un-delegate a team because they had failed to write the documentation that their potential successors would find necessary to get started in their job. -- Moray -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/3c3213f839f66abf3297dca1198f7...@www.morayallan.com
Re: [all candidates] delegation
On 03/26/2013 09:28 PM, Gergely Nagy wrote: I see Zack's DPL helpers initiative as a step in this direction, and I'd like to take it a little further. How? Make it formal? Have new official positions? Or just push more people to help and that's it (which is ok too...)? Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5153d8d3.1080...@debian.org
Re: [all candidates] delegation
Thomas Goirand z...@debian.org writes: One of the key role of the DPL is to delegate. What are your intention in this regard? Do you think that the current teams and roles are well filled? Or would you like to change some of the people currently holding a position? Why (not) changing anything? I believe that the current delegations are well deserved, if elected, I wish to reaffirm people currently holding a position (unless they wish to step down, of course). On the other hand, most of our teams are lacking manpower, which is something I would like to improve. To remedy the situation, I'd need to learn a bit more about the various teams than I was able to while peeking in from the outside. I'd like to think that we have quite a bit of manpower to spare, we just need to aim them at the right team. Or if that fails, improve our recruitment to make joining the teams lacking manpower most more appealing, and more rewarding. In some cases, likely more visible, and better defined too. I also plan to delegate more tasks, to make the DPL job sustainable in the long run. These would include representational tasks just aswell as organising things on behalf of the DPL, and so on and so forth. I see Zack's DPL helpers initiative as a step in this direction, and I'd like to take it a little further. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d2um8f49@galadriel.madhouse-project.org
[all candidates] delegation
Hi all, One of the key role of the DPL is to delegate. What are your intention in this regard? Do you think that the current teams and roles are well filled? Or would you like to change some of the people currently holding a position? Why (not) changing anything? Cheers, Thomas P.S: I have read the history, and didn't find anyone asking this. If I missed it, then sorry... -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51507354.1050...@debian.org
Re: [all candidates] delegation
On 25/03/13 at 23:55 +0800, Thomas Goirand wrote: Hi all, One of the key role of the DPL is to delegate. What are your intention in this regard? Do you think that the current teams and roles are well filled? Or would you like to change some of the people currently holding a position? Why (not) changing anything? Hi, Our teams are generally working very well. Are they well filled? They are surely filled by very qualified people, but not all the teams have a lot of spare manpower. If elected, one of my first tasks will be to do a status check of our core teams, to: - understand who is active currently, who is going to be active in a year, who is active but would like to step down, ... - encourage the teams to think about possible new members, so that they can be contacted and trained early. (I will not go through every team (including all packaging teams), but instead focus on the teams that have the ability, when malfunctionning, to severely harm the project.) 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 team members 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 our teams are sufficiently staffed so that one can leave a team without feeling guilty. Lucas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130325162417.ga9...@xanadu.blop.info
Re: To all candidates: delegation process
On Sat, Mar 11, 2006 at 08:47:16PM +0100, Florian Weimer wrote: As you might have noted, the Constitution does not spell out the process how a new delegation is made. Would you please summarize the process you intend to follow if you are elected? Thanks. For tasks not currently under anyone's specific responsibility, I'd describe the task, and announce the delegation on an appropriate mailinglist. The appropriate place is depending on the importance of a task, delegating someone to deal with a specific negotiation is something else than a delegation of an ongoing infrastructural task. For selection of who to delegate, I'd inquire with related delegates, related teams, and any other stakeholders, and of course with my DPL team -- but make the decision myself. For tasks currently delegated, or at least, currently performed by someone or some team, I'd leave that to the current responsibles, and merely rubber-stamp. Where task descriptions are unclear[1], or even disputed, I'll work on documenting that. Only when there's a very strong reason to do otherwise, I'd do so, but that's a sort of last-resort action, only to be done when there couldn't be an agreement any other way. --Jeroen [1] Not many people know what tasks are exactly done by wanna-build maintainer, buildd maintainers, port maintainers and ftp-masters respectively, for example -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: To all candidates: delegation process
On Sat, Mar 11, 2006 at 08:47:16PM +0100, Florian Weimer wrote: As you might have noted, the Constitution does not spell out the process how a new delegation is made. Would you please summarize the process you intend to follow if you are elected? Thanks. A few steps: 1. Talk to the current delegates and teams and ask for an honest appraisal - how things are going, whether they need help, etc. 2. Where more delegations are clearly needed, look for volunteers. Discuss the task with them thoroughly, and make sure we're agreed on what needs to be done. 3. Announce the delegations publically to d-d-a. I think the above is nothing more than common sense. How would you do it? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] We don't need no education. We don't need no thought control. signature.asc Description: Digital signature
Re: To all candidates: delegation process
On Sun, Mar 12, 2006 at 09:27:24AM +0200, Lars Wirzenius wrote: su, 2006-03-12 kello 11:21 +1000, Anthony Towns kirjoitti: if a delegation is necessary, make it, by posting the details to -project, or if necessary, -private. Why -project and not -devel-announce? I just wasn't assuming they'd all be worth a post to d-d-a. Ideally, it'd be because the delegates would be posting details of what's going on themselves to d-d-a; so an additional post authorising their delegation would just be repetitive. But basically: no particular reason. Cheers, aj signature.asc Description: Digital signature
To all candidates: delegation process
As you might have noted, the Constitution does not spell out the process how a new delegation is made. Would you please summarize the process you intend to follow if you are elected? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: To all candidates: delegation process
Hi, * Florian Weimer ([EMAIL PROTECTED]) [060311 20:48]: As you might have noted, the Constitution does not spell out the process how a new delegation is made. Would you please summarize the process you intend to follow if you are elected? Thanks. Well, there are two parts of the answer. The formal part, and the social part. First of all, I will delegate only people if they are ready for it. As some example, if e.g. the policy team asks me to extend themself by someone, I will (usually) do as requested. The formal part is: Even if the constitution doesn't specify it, I think delegations for an ongoing area of responsibility should be done public. It is important for the rest of the project to know who got assigned what task and authority. I think the delegations that actually were done publicly during the last term were good examples of the process. A little prompter at times would have been good, though. signature.asc Description: Digital signature
Re: To all candidates: delegation process
On Sat, Mar 11, 2006 at 08:47:16PM +0100, Florian Weimer wrote: As you might have noted, the Constitution does not spell out the process how a new delegation is made. Would you please summarize the process you intend to follow if you are elected? Thanks. See also http://lists.debian.org/debian-vote/2006/02/msg00686.html Find a need and volunteers; see if that can be handled without a delegation; if a delegation is necessary, make it, by posting the details to -project, or if necessary, -private. Generally, I think that delegations should be fairly limited in scope, and the actions undertaken with the special delegated powers should be easily followed by others subscribing to some list; either -project, -private, or one specific to the area being delegated, eg -release or -legal. Cheers, aj signature.asc Description: Digital signature
Re: To all candidates: delegation process
Andreas Schuldei [EMAIL PROTECTED] wrote: First of all, I will delegate only people if they are ready for it. As some example, if e.g. the policy team asks me to extend themself by someone, I will (usually) do as requested. If this is the case, why were you supporting a motion to forcibly delegate various people within the project? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: To all candidates: delegation process
su, 2006-03-12 kello 11:21 +1000, Anthony Towns kirjoitti: if a delegation is necessary, make it, by posting the details to -project, or if necessary, -private. Why -project and not -devel-announce? -- Policy is your friend. Trust the Policy. Love the Policy. Obey the Policy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
