RE: PATCH keyword, again

[Murray Cumming Comneon com]

Jeff, these things can all help, particularly for big modules such as GTK+
and nautilus, which are special cases, but they should not be necessary for
most modules. Most modules do not get so many patches that they should be
ignored for weeks or months. You yourself know how difficult it is to even
get some maintainers to make a tarball release.

It really isn't that difficult to monitor a bugzilla query [1] or to catch
all the bugzilla spam that has the PATCH keyword. They don't even have to
apply the patch - just read it and say "please apply" or "please do XXX and
resubmit".

Of course it's completely understandable that some maintainers don't have
time even for this. But when that's the case, they should be delegating
responsibility, because there are people who would like to help. You can
make someone a co-maintainer after making it clear that he should only
approve simple patches at first, and make releases. I am confident that
there are lots of people who would like to help in this way. This is a route
to future full maintainership which maintainers should provide.

Personally, for my *mm stuff, I review patches as soon as possible because
every patch contributor is a potential full developer or maintainer. And I
make it clear that I want co-maintainers. And whenever possible, I give
maintainership away.

People often wait for patch A to be approved before contributing patch B,
but imagine how much more development would happen if the gap between patch
A and B was 3 days instead of 3 weeks. Some people contribute patch B
because they are so discouraged. Some people never contribute patch A
because they see what happens to other patches.

In summary, I believe that the neglected-patches problem is a major obstacle
to contributing to GNOME. I believe that co-maintainers are the answer, and
I think that we (the community/foundation board) should maybe declare that
all modules should have >1 maintainer. Single points of failure are bad.

[1] For instance, the bugzilla report that was created for this purpose,
http://bugzilla.gnome.org/gnome-25-report.html
Or 
see the patches links here:
http://www.gtkmm.org/bugs.shtml

> But the good news is: You CAN help.
> 
>   * Summarise a list of patches that you care about and send it to the
>     appropriate mailing list. Making sure maintainers understand the
>     benefits and implications really helps if it's not in 
> their field of
>     interest or expertise. Not everyone groks 
> internationalisation or a11y
>     issues intimately - help them understand.
> 
>   * Send it again! Sometimes maintainers have an overflowing 
> inbox, and find
>     themselves handling new mail only - if you resend your 
> patch, a summary,
>     or a description of a problem (not every day, but in a 
> reasonable time
>     frame), the maintainer is more likely to see it, or 
> understand that it
>     is a serious problem. I can guarantee from experience on 
> both ends that
>     this *does* get results, and maintainers will often thank 
> you for your
>     persistence. Look at Patch-O-Matic in the Linux kernel community.
> 
>   * If it's a module you enjoy working with, or have 
> significant interest
>     in, establish a working relationship with the maintainer. 
> Help them out
>     where you can. Offer to commit patches after initial 
> review, test things
>     out and provide feedback, and so on.
>     
>   * If you excel at the previous point, and earn the 
> trust/respect of the
>     maintainer you may even have a shot at becoming 
> co-maintainer or even
>     full maintainer if they feel you're doing a great job. 
> This is not some
>     kind of sadistic collegiate initiation process - this is 
> the circle of
>     life in Free Software! Get Darwinian on maintainers 
> arses! :-) [ This is
>     great stuff if it happens, because it lets the original maintainer
>     concentrate on other things, and you can have the 
> satisfaction / fame /
>     girls / sunglasses that are the hallmarks of GNOME 
> maintainer success. ]
> 
> If the maintainer says no, well, not much you can do about 
> that but appeal to a wider audience (such as sub-projects and 
> so on). But it's everyone's responsibility to help 
> maintainers get their stuff in - we have to help them out as 
> much as we can. :-)
> 
> You said above "so nobody feels responsible"... *Your* energy 
> can kick it off. :-)
> 
> - Jeff
> 
> [1] Tender Loving Care. Which roughly amounts to being nice. :-)

Murray Cumming
www.murrayc.com
murrayc usa net