Doug Hellmann wrote: > I would like for us to collect some more data about what efforts teams are > making with encouraging new contributors, and what seems to be working or > not. In the past we've done pretty well at finding new techniques by > experimenting within one team and then adapting the results to scale them > out to other teams. > > Does anyone have any examples of things that we ought to be trying more > of? >
Okay, here I am sticking my foot in it after reading all the other excellent replies. Lots of good suggestions. Matt, Zane, Chris, Rico, etc. Here are is another one: I've noticed that as the projects mature, they have developed some new processes that are regular, but not daily. Some are baked into the schedule, others are scheduled on a semi recurring basis but not "official. One that I've seen a few times is the "bug swat day". Some projects are scheduling triage and fix days throughout the cycle. One project just decided to make it monthly. This is great. Invite Ops and users to participate. Invite the folks who filed the bugs you might fix to participate. Use IRC, paste and etherpad to develop the fixes and show the symptoms. Maybe to develop the test to demonstrate the fix works, too. If an operator really wants to see a bug fixed, they let the project know and let them know when she will turn up in IRC to help. If they help enough, add them as co-owner of the patch. Don't make them get all the accounts (if that's possible with Gerrit), just put their name on it. They'll be overjoyed to both have the bug fixed *and* get some credit for stepping up. This get devs, users and ops all on the same IRC page, focusing on enduser problems and collaborating on solutions in a regularly scheduled day(time) slot. And the "needs more info" problem for bugs gets solved. You can also invite everyone to Spec review days, or test writing days, or documentation days. And you can invites students, academicians, etc. If people know to show up, and they know *if* they show up *and* they are willing to discuss symptoms, ask questions, provide logs, whatever, that some pain in their butt will be closer to getting fixed, some will show up. You give them credit and they'll feel even better showing up. Not quite drive-by contributors, but it means pain points get addressed based on participation and existing contributors partner with the people who know the pain points to solve them. On a regularly scheduled basis. Oh, and you can put these days on the OpenStack event schedule, too. --Rocky __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
