[Bf-committers] patch tracker

[Mike Erwin]

Harley:
> It seems to me that the patch tracker is currently designed to fill up with
> crap.  What I mean is that once a patch is accepted it just disappears from
> the list, while the unaccepted ones just linger there forever.

Well said, sir! I don't have much experience with the tracker, but if
it works as described here, it's focusing on the wrong things.

Patch authors need feedback on their proposed changes, and not just
code review. Getting a patch accepted is a good thing, right? So that
should go up on the wall as an achievement. Closed (dumb ideas), Under
Review, or Accepted all stick around. A new contributor should be able
to look through the tracker and learn what makes a good (or bad)
patch.

Reviewers are more interested in what needs to be done next. Recently
active patches rise to the top (like builds in graphicall), and
submitters can nudge their item to the top if they feel it needs
attention. Not so much a competitive thing, just a way to focus on
newer stuff.

Back to what Tom was saying, we do need a stronger emphasis on patch
review. It sucks working hard on something just to watch it die from
lack of attention. Whether this happens as part of the meetings, or as
individual "homework" assignments for developers, or both, seems fine.
As long as we find a way to consistently show contributors that their
work is valued.

Another FLOSS project (forget which one...) actually has a
leaderboard, and contributors are given points for actions that are
valuable to the project. Like 100 for code commit, 150 for patch
review, 200 for wiki docs, etc. Have lots of orphaned patches? Bump it
up to 400 and they'll get attention. Cheesy, but fun!

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire