Re: [boost] [Guild] Getting volunteers' changes back to trunk

Subject: Re: [boost] [Guild] Getting volunteers' changes back to trunk
From: David Abrahams (dave_at_[hidden])
Date: 2010-11-12 11:29:09

At Fri, 12 Nov 2010 05:41:23 -0600,
Jim Bell wrote:
> 
> 
> 
> On 1:59 PM, David Abrahams wrote:
> > First things first: I want to call this program "Boost.Guild." Agreed?
> 
> Agreed. (I like it!)
> 
> > At Sat, 06 Nov 2010 08:55:31 -0500,
> > Jim Bell wrote:
> >
> >> Say you have a team of volunteers attacking failed regressions and
> >> tickets. They're creating (hopefully) good trunk patches. They can't
> >> commit to the trunk, but can modify tickets.
> >>
> >> If maintainers are active, they could review and incorporate
> >> them. But this increased activity may be more of a strain for
> >> them. If maintainers are MIA, it won't happen.
> >>
> >> So we need at least one person to bring these changes back into the
> >> trunk. Changes to libraries they're not familiar with.
> > BoostPro is willing to commit resources to help with that if there's
> > someone else (like you) running the program with us.
> 
> I envision it to be self-study and group-study. What do you see my role
> being? (Besides keeping an e-mail list of members and organizing the
> lavish annual appreciation banquet. ;-)

General leadership.  That means deciding what you think needs to be
done and convincing others to work with you in that direction.

> > We'll need a list of libraries whose maintainers authorize such
> > changes, and libraries whose maintainers want to control all
> > changes themselves.
> 
> Agreed. I envision active maintainers establishing rapport with
> guild members whose work they liked.

I think we should work hard to keep that direct interaction optional,
though, or maintainers may not want to get involved.  They need to
know that this doesn't necessarily have to be a drain on their
resources.  Of course, any maintainer can eventually promote a guild
member to co-maintainer if all are agreed.

> >> What's the best way for the volunteers to signal to these
> >> trunk-authority people to pick up their change?
> >>
> >> A Ticket keyword and corresponding report should work. Is there a
> >> better way?
> >
> > I can't think of one.
> >
> >> Should we look for a person or two from the volunteers for this
> >> role?
> >
> > I don't think the volunteers themselves can be authorized to commit to
> > trunk.  We need more trusted people to do that.
> 
> I agree. One trusted person should sanity-check marked changes and
> merge. 

I don't think it has to be just one person, but as I said, we're
willing to devote some resources to this.

> (And revert!) And a single person would be good in terms of
> getting to know guild members whose work needs closer scrutiny. (And
> they could ask other guild members to help with that scrutiny.)
> 
> But could this alone be a significant effort?

Yes, that's why you should split it up.  Maybe we have one or more
guild liaisons, and have different people doing the commits.  I think
we may be able to offer some testing resources.

> >> A regular schedule (say, twice a week) to run the report and patch
> >> would be good, I think. Trunk regressions need time to bake.
> >
> > Sorry, which report?
> 
> A Trac ticket keyword query showing the trunk patches that guild
> members suggest.
> 
> In fact, we could build a sophisticated guild workflow using trac
> ticket keywords alone. I haven't decided if that's crazy or
> brilliant.
> 
> Should there be a guild mailing list?

If the guild members or organizers want one.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com