Re: The future of the release team

[Mark McLoughlin <markmc redhat com>]

Hi Maciej,

On Wed, 2004-09-22 at 21:47, Maciej Stachowiak wrote:
> On 22Sep2004 08:29PM (+0100), Mark McLoughlin wrote:
> > > 
> > > So basically I think the idea of splitting all these tasks among
> > > different people is unlikely to work well.
> > 
> > 	That certainly sounds fairly reasonable, but in practise we've been
> > splitting up these tasks very successfully. There is a small bit of
> > overlap between the people doing the different tasks, but not much.
> 
> However I think there is a sense of shared responsibility for them,
> even if they are being done by separate people.

	Right, but there's no need for us to "own" the broad responsibility for
the release. Individuals can own tasks and the entire community should
share the overall sense of responsibility for the release.

> I think these release tasks have a degree of community-wide
> responsibility that requires a higher degree of accountability than
> just "I volunteered randomly".

	Okay, I need to drive home this point - I do not expect "random" people
to volunteer, but rather some of the many very competent people in our
community to step up and take on some of the tasks. It would be like
disbanding and re-forming the release team each release except its very
clear what each person is volunteering for.

> The release team page itself says: "It's probably a good idea for
> approximately half of the membership to change every 6 months to allow
> many people to experience a full release cycle and learn about the
> release process. This would also avoid stagnation." I wonder why this
> approach doesn't create enough opportunities for new volunteers?

	Well, I see a few problems at the moment:

  - because there's not a huge amount of visibility into the release 
    team, and because the release process is actually running quite
    smoothly, there's a perception the release team doesn't need
    new volunteers. But the release process could be better, it does
    need evolving, it does need fresh perspective and energy, and
    while it might be "good enough", we should be trying to do better.

  - people may be put off volunteering because they feel like they're
    volunteering to be partly held responsible for the entire release
    process, rather than a specific task. That's a bit daunting.

  - people who have been on the release team for a time build up 
    experience that is invaluable to the release process. If a team 
    member decides to drop out, they know they lose the opportunity to
    put that experience to good use.

> That's really all I have to say on this topic though. I am not closely
> involved in GNOME development these days. Mainly I wanted to pass
> along my wisdom based on being on the front lines in the old days when
> dates were set more in mud than in stone. I think it *is* possible for
> a smooth process to get messy once again. 

	Your input is very welcome - its obvious that you care because you've
seen how bad it can be. But the problems that worried us all back then
are not the same problems that worry me now.

	Have you noticed how little interest there has been in this discussion?
That worries me. It suggests to me that we've grown complacent[1] about
the release process. What we need is renewed energy, rather than
complacency. I'd prefer the process to get a little messy again for a
time rather than continuing down this downward slope of complacency.

	So, we could tackle the problems with the release team incrementally,
but because of the complacency I don't think we're going to have
significant impact. We've been trying to fix problems with the release
team for a number of cycles now.

	Just to summarise again what I hope to achieve:

  - Increased participation in, and awareness of, the release process
    from the entire community

  - New energy, ideas and people

  - A real sense of ownership of specific tasks by individuals, rather
    than a team that can let things drop on the floor because of poor
    co-ordination.

  - Increased redundancy - the more people that have experience with 
    release tasks, the easier it is to transfer ownership of those tasks
    when necessary.

  - Anders in lingerie.

Cheers,
Mark.

[1] - I hope people don't take offence from that - if we've grown
complacent, its only because things have gone well.