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 _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers