Andre Klapper <ak-47 <at> gmx.net> writes: > Offtopic, but the obvious first step would be to improve the rate of > reviewed patches in general. > > While peer reviews are great, **in some projects** teams miss manpower > already to have reviews at all, without any peer. > (And if you are a first-time contributor and you never receive feedback > on your first patch you give up and won't know where to escalate. That's > where GNOME's contributor base remains small.) > I think Bugzilla is a terrible tool if you lack manpower, in particular if the manpower for a project is shrinking relative to the amount of bugs. I don't think Bugzilla was ever designed for the "you take over a project, here's 1000 bugs as a head start, it'll increase by 50 every week" case. Bugzilla works very well as long as you keep it in check, but once it grows too much and the necessary triage doesn't happen, you lose without a real chance to ever get it under control again. It's a bit like a zombie outbreak in that regard.
Another thing is that Bugzilla is essentially a large TO-DO list. Those lists require a certain kind of mindset that is a given for every developer. I think a large part can work well with it, but there are some that just can't [2]. I am one of those people.[4] Because I don't keep a TODO list though, I'm not usually in the need to get anything done.[2] So you can just poke me on IRC and I there's a high chance I'll review patches if I know things about the code you're looking at. I might even fix a bug that you have, just because I know how. > * gtk+: 637 unreviewed patches; 480 of them older than 12 months > I'm these days the main developer of GTK with Matthias together. GTK has > 2500 open bugs[1]. So it has passed the zombie outbreak state by now. So I don't look at bugzilla at all. I want to get things done. This means 2 things: (1) If you file a bug for something I broke, I'm not gonna know - unless Matthias (who's the only one triaging those 2500 bugs sometimes) throws it at me. (2) I'm not gonna care about bugzilla statistics, target milestones, bug severity or anything else people do in there. I have no idea how to improve that situation. The only possible solution I can even come up with is getting more developers to work on GTK - first learning the internals of the toolkit and then working on the bugs. But I have no idea where those people would come from. Benjamin 1: https://bugzilla.gnome.org/page.cgi?id=weekly-bug-summary.html 2: http://slobotski.wordpress.com/the-pmarca-guide-to-personal-productivity/ 3: http://www.paulgraham.com/makersschedule.html 4: A very sincere Thank You for that goes to both Red Hat and GNOME for adjusting themselves to work with me this way. It's not easy to work with someone who's so different than you are.[see also 3] This totally should not be a postscript, but it'd really confuse what I wanted to say above. Again, thanks. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list