Re: some thoughts about contributing to gnome

[Elijah Newren <newren gmail com>]

On 5/11/05, Vincent Untz <vincent vuntz net> wrote:
> Le mercredi 11 mai 2005 à 00:49 +0200, Samuel Abels a écrit :
> > Am Dienstag, den 10.05.2005, 16:25 -0600 schrieb Elijah Newren:
> > > We've pinged d-d-l a few times about this.  My question to
> > > you is: do you have any ideas about how we could be more effective at
> > > getting developers to review patches?
> >
> > I am probably going to make myself unpopular, but I would suggest
> > regular notifications (once per 48 hours) on bugs that have a new
> > attachment and have not been confirmed. (Implement an automatic "cvs
> > commit" right remover for those who do not review their product's
> > patches properly and you also get my vote ;-).)

Honestly, I don't think unconfirmed vs. new has much use.  We've made
periodic pushes over the years to try to make it more useful by
confirming bugs and starting all bugs as unconfirmed and various other
things, but I've found that it just isn't useful to me even for the
products I help maintain--and that I almost never bother confirming
bug reports against those products or even for bugs where I can
duplicate problems that others have reported.  Personally, I'm
starting to think that it's just another setting to tweak for the sake
of tweaking settings, and that all we're doing with it is generating
bug spam instead of genuinely helping.  Do others get this same
feeling?

However, sending email reminders about unreviewed patches periodically
is something that I think would help (though there'll be some people
like Vincent for whom this won't help, but I don't think it'll hurt
either).

<snip>

> Sending more mails won't help me: I'm already receiving tons of bugzilla
> mails and I perfectly know how to find patches in bugzilla. 

But would it hurt to receive another email every day or two
summarizing the unreviewed patches in bugzilla?  While it may not help
you, there are those for whom this would be very helpful (e.g. Havoc
responds to emails like this when I manually send them to him, but he
won't go looking for them and he sometimes doesn't have time to look
at new patches when they arrive but then they become lost in a huge
inbox.  Honestly, I think it'd help me too).

> Telling me I
> should review patches quickly won't help me either: I know this but I
> don't have time right now and I just can't. And I know this is a problem
> for newcomers. I'm blaming myself everyday for not reviewing patches.
> I'm even ashamed to go to GUADEC with so many bugs and no new features
> in 2.11!

I'm in the same boat with metacity and libwnck...

> I don't have any real proposition. Maybe we should help newcomers
> understand how hard it is for maintainers to have all those bugs and
> deal with them. Or maybe we should have a maintainer status page so
> newcomers at least know when they'll have an answer: "maintainer is busy
> right now, he will come back to check your patches on May 22nd"...

Actually, I was thinking of a product/component status of some type,
which could appear directly on show_bug.cgi.  Originally, the idea was
just a maintained/unmaintained status (where nothing is shown if the
product is maintained but some big warning is shown otherwise--just so
users or potential new developers know to be patient or even know that
they should try an alternate means of communication if really
important), where the state can be set by manual request and/or by
some automated criteria (e.g. if any product has more than 20% of its
patches, which were submitted between 14 days and 6 months ago, in the
unreviewed state then mark the product as unmaintained).  Thoughts?


Elijah