Re: [boost] [Bug Sprint] Policy on MIA maintainers

Subject: Re: [boost] [Bug Sprint] Policy on MIA maintainers
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-12-18 02:00:19

On Sat, Dec 18, 2010 at 1:15 AM, Jim Bell <Jim_at_[hidden]> wrote:
>
> On 1:59 PM, Dean Michael Berris wrote:
>> On Mon, Nov 29, 2010 at 9:32 PM, Jim Bell <Jim_at_[hidden]> wrote:
>>
>>> I'd like someone to walk through a case study right here on the list.
>>> (Or a few people!)
>> I'll take this up at a later time.
>
> It's a later time. ;-)
>
> <http://lists.boost.org/Archives/boost/2010/11/173547.php>
>

Yes, alright. So just to see if I get the context right, a case study
on what to do with an MIA maintainer is needed. I think Marshall Clow
had successfully taken on the Boost.Array maintenance when the number
of tickets filed against Boost.Array had piled up and the original
maintainer didn't have the time to actively curate the tickets
assigned the library.

Basically what had to happen is:

1. Someone has to care enough to look at the tickets filed against a
certain library that he either:
  a) Uses and depends on in his projects.
  b) Has enough time on his hands and a willingness to continue
maintenance of a library.
  c) both, and potentially more reasons for caring.
2. That someone has to (in the current set-up) either:
  a) Address tickets by verifying whether they are issues or whether
there are solutions not requiring changes to the library
  b) Submit patches to address the issues raised in the tickets
  c) Raise awareness of the issue on the mailing list to get the
maintainer's attention
  d) Track down the maintainer (usually via email) to get him to
respond at least to the ticket
  e) Go to BoostCon * and hope that the maintainer will be there to
get him IRL ;)
  f) All of the above, and possibly other means to get changes into
Boost by asking someone else with commit privileges to accept the
patches
3. After doing the above, the contributor would usually be one or all
of the below:
  a) Discouraged by the lack of maintenance on a given library
  b) Not try to contribute again because the cost of doing so is pretty high
  c) Choose to maintain a locally-patched version of Boost and just
maintain that for the organization/himself (I've done this BTW before)
  d) Just wait for a time when Boost would be more open/responsive to
contributions

Case in point would be with the bug sprints -- some people try to be
really active at that time, but either the maintainer has been busy
(as some have already confessed) or there's no maintainer around to
even respond to the tickets.

If I'm not making sense with the points above, please take into
consideration that I'm writing this as someone who's been trying to
get patches to Boost in with varying levels of success.

Thanks for the time and I hope this helps!

(About recommendations, check the other thread about Open Source
Forking, where I have a longer list of things I've shared about what I
think should happen with the Boost development effort).

-- 
Dean Michael Berris
about.me/deanberris