On Wed, Feb 23, 2011 at 2:53 AM, Julien Phalip <jpha...@gmail.com> wrote: > On Feb 22, 3:22 am, Russell Keith-Magee <russ...@keith-magee.com> > wrote: >> 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.
Agreed that the Django homepage needs some work, and this is one of the things that needs to be addressed. In fact, I seem to recall talking to someone about this exact problem... :-P > 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. Agreed that this is an area where we could improve. Suggestions and patches welcome. > 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. The risk here is turning the process into something that can be gamed, which means you end up having people playing the game -- and, since we're dealing with hackers, looking for ways to beat the game -- rather than actually contributing in a useful way. If we introduce game mechanics, we have to be careful that those mechanics don't undermine or distract from our actual goals. However, I'm not completely opposed the introduction of game-like mechanics, subject to a someone making a concrete proposal that will meet this criterion. This is something that could be tied into a revised djangopeople.org (e.g, get your "opened a ticket" badge, or your "supplied a patch that got committed badge". It is also an area where DSF funding might be able to help out -- e.g., a special t-shirt for contributors who hit some 'score', or an invitation to a 'high value contributors' party at DjangoCon. So - I'm certainly interested in hearing proposals around this idea -- especially if they are accompanied by people willing to volunteer to do the heavy lifting, not just come up with a grand idea. Yours, Russ Magee %-) -- 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.
