Re: some thoughts about contributing to gnome

[Samuel Abels <newsgroups debain org>]

Am Mittwoch, den 11.05.2005, 09:57 -0600 schrieb Elijah Newren:
> 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.

Sorry, I caused confusion by using the "confirm" terminology in the
sense of "confirm a patch".

>   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

Yes, that is definitely not as important as patches.

> 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).

Agreed, that is what I meant.

> > 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.

While sorting to some 20 bugs today, I immediately wished there was a
short summary field, summarizing the actual problem. Many bugs turn out
to be completely different from the original problem which makes reading
longer histories a pain. If there were a short summary describing
the /current/ status and current "action items", that would definitely
be a great help.

>   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?

Sounds good, IMO. Don't forget to include a "I want to become the
maintainer!" link. ;)

-Samuel