Re: [all candidates] delegation

2013-03-29 Thread Gergely Nagy
Gunnar Wolf  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

2013-03-28 Thread Moray Allan
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

2013-03-28 Thread Moray Allan

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

2013-03-28 Thread Gunnar Wolf
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

2013-03-28 Thread Charles Plessy
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

2013-03-28 Thread Moray Allan

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

2013-03-28 Thread Moray Allan

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

2013-03-28 Thread Gergely Nagy
Thomas Goirand  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

2013-03-27 Thread Thomas Goirand
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

2013-03-26 Thread Gergely Nagy
Thomas Goirand  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



Re: [all candidates] delegation

2013-03-25 Thread Lucas Nussbaum
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