Am Mittwoch, den 11.05.2005, 09:57 -0600 schrieb Elijah Newren: > On 5/11/05, Vincent Untz <[EMAIL PROTECTED]> 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 _______________________________________________ Gnome-bugsquad mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-bugsquad
