On Feb 22, 3:22 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Tue, Feb 22, 2011 at 3:49 PM, Julien Phalip <jpha...@gmail.com> wrote: > > I know there already is a "Has patch" flag, but I actually find that > > one a bit useless since there's no way to distinguish from the mass of > > tickets where there are good, solid patches (whose authors themselves > > think could be RFC or simply in need for review) versus the draft or > > tentative patches. In fact, I'd make both the "Has patch" and "Patch > > needs improvement" flags redundant and instead introduce a new "Patch > > ready for review" stage. > > This smells a bit like a bikeshed to me. What's the difference between > having a *state* that says "patch needs review" and a boolean flag > that says "patch needs review"? > > A draft or tentative patch is a patch that the author has themselves > flagged as "needs improvement". Or, demonstrating the flexibility of > the system -- you could also treat that case by simply not flagging > the 'has patch' state. Either way, it is possible to provide a patch > without indicating that it is ready for review. > > > To illustrate this, I've got two patches currently in this virtual > > "Patch ready for review" state: #13091 and #12475 :-) > > #13091 isn't ready for review, because it's still marked DDN. That > means that a decision still needs to be made. > > #12475 turns up here: > > http://code.djangoproject.com/query?status=new&status=assigned&status... > > ... along with 313 other tickets. I've just added this query to the > "reports" page [1], which is itself linked from the > code.djangoproject.com home page. A range of other queries have always > been there, but there wasn't a simple "needs review" query. > > [1]http://code.djangoproject.com/wiki/Reports
Thanks Russell, you've convinced me I was doing a little bike-shedding there :-) It does seem that some reports can already be generated to get the results I was after. > Like I have said many times in the past -- issuing queries to find > tickets needing review isn't a problem we have. The information that > is needed is all there. What we *do* have are two other problems: > > 1) Finding people willing to be altruistic and review someone else's > work, rather than their own > 2) Directing people who are inclined to be altruistic to the right place. > > I know that UX can affect engagement, so it's entirely possible that > the whole Trac process is an impediment to engagement of potential > reviewers. However, I strongly challenge the assertion that either of > these problems can be fixed by simply adding a triage states alone. A > triage state just changes the query (arguably simplifying it) -- it > doesn't by itself increase the number of people volunteering. > > The problem we have is a much deeper problem of community engagement. > Unfortunately, this is also problem that I don't have any magic > solutions for. Convincing people to be altruistic is hard. > > A triage state also doesn't help people who *are* inclined to help to > actually find the information that would allow them to help. That > means the contribution guide, and the Trac reports page. Hopefully, > #14401 will address this somewhat. Either way, I don't think a Trac > flag will help -- it's a more fundamental IA problem for the project > itself (i.e., how to direct people to the right information). > > One Trac feature that I suspect *might* help in this regard is one > that I've raised before -- allowing users to flag individual issues > that they have an interest in seeing solved. This isn't just another > flag, because it provides a way to slice and present the data in a > different way. It would allow us to provide a project-wide leaderboard > of the "most wanted bugs", providing a focus for volunteer activity > that doesn't currently exist. However, this requires someone to spend > time developing that feature for Trac, because it isn't (to my > knowledge) an out-of-the-box feature. I'm voting +1 for the voting feature suggested by Daniel in his previous reply to this thread. As far increasing community engagement is concerned, off the top of my head there are at least three things worth exploring: 1) Advertise For example: * The reports page is useful but it's easily missed. Perhaps there should be a reminder and a link to it in every future sprint announcements. * There should be a huge "Contribute to Django" button (with round cornerz) on the djangoproject.com homepage linking to more info (e.g. to the page that Gabriel has been drafting recently). * I believe the vast majority of django users come to the djangoproject.com website primarily to view the documentation. So a hard-to-miss "Contribute to Django" link could be displayed on every single page of the doc. 2) Make the barrier for contribution seem lower. Gabriel has already done an awesome job with the new "Contribute to Django" page in the doc. The reports page is also great but could be improved with more query links and more descriptive scenarios explaining what types of contribution could be done based on one's programming abilities, or on one's familiarity with Django's internals, or on one's mood, or on one's available time, etc. It should be emphasised that there are lots of quick and easy ways to contribute meaningfully. 3) Make contributing enticing The two points above combined would probably themselves increase entice-ability but clearly that wouldn't be enough. Some common catalysers for user participation based on peer recognition are: user rankings (automatically based on the number of comments, for example) or users voting for other users (like it's done for example at ted.com). I'm not sure how hard that type of things would be to implement in Trac though, or if some plugins already exist. Julien -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
