closing out old bugs of unmaintained releases

Greg DeKoenigsberg gdk at redhat.com
Fri Jan 25 14:45:35 UTC 2008


On Thu, 24 Jan 2008, Jeff Spaleta wrote:

A big +1 to everything Jeff says here.

--g

> On Jan 8, 2008 12:53 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
>> Perhaps one option would be for non-programmer packagers to team up with
>> a programmer/sponsor to take on the task of package maintenance? Where
>> currently a package has one 'owner', there would instead be two rôles --
>> a 'packager' and potentially a separate 'hacker'. Those wanting to
>> package software which they can't fully maintain for themselves would
>> have to recruit a programmer-type to sign up for the job with them.
>
> Here's how I would like to see things go.  I want to see SIGs as teams
> with somewhat defined roles. We define these roles projectwide, but
> each SIG as a team figure out who fills what role.  Obviously you
> can't define all work in terms of roles. Some work will be
> specialized. Thats OKAY.
>
> But what the projectwide defined roles gives us, is a way to train up
> new contributors in a way so that we aren't burdening each SIG with
> the responsibility of training people to do the same common tasks.
>
> So what sort of roles would a typical SIG probably have.  Off the cuff I'd say:
> developers    (ie codemonkeys)
> maintainers   (ie packagemonkeys)
> triagers         (ie bugmonkeys)
> documenters (ie textmonkeys)
> artists           (ie mediamonkeys)
>
> So SIG A's triagers are basically doing the same stuff that SIG B's
> triagers do.  As a group all the triagers across all SIGs are building
> their own tools and processes to help each other out. But they focus
> their individual efforts on a particular SIGs piece of the bugzilla
> pie.
>
> Same thing with maintainers.... as a group maintainers affiliated
> across all SIGs would be doing the same sort of crap day in and day
> out. But the focus their attention on a SIG's scope of packages.
>
> And so on and so on.
>
> But what is really great about having defined roles at the project
> level.. is that we can attempt to organize projectwide training for a
> particular role.  We can attempt to organize projectwide recruitment
> for a particular role.  Once we recruit and do basic training for a
> role, projectwide, then we can plug those newly trained people into a
> particular SIG that has a role that needs filling without burdening
> the other experts in the SIG with the text of training for a role they
> aren't performing.  What a SIG can then focus on is integrating that
> person's role based skills into that particular SIGs development
> culture.
>
> Personally I want to get to the point where we can essentially have a
> role training effort every quarter or so.  One quarter we make a
> project wide push for triagers.. the next maybe its maintainers.. and
> so on and so on... then we repeat.  But for this to work we need to
> empower SIGs to be the team model and take responsibility for well
> defined chunks of the software repository.
>
> -jef
>
> _______________________________________________
> fedora-advisory-board mailing list
> fedora-advisory-board at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-advisory-board
>

-- 
Greg DeKoenigsberg
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"


More information about the fedora-advisory-board mailing list