On Thu, May 15, 2008 at 9:33 AM, Jeffrey Tadlock <jeffreyt@xxxxxxxxxxxxxxxxx> wrote: > I want to be sure I understand the problem trying to be solved before > commenting. Is the problem trying to be solved encouraging and > increasing direct user participation and contributions? And then once > we have that, a method in place to retain our contributors? Yes the underlying goal for me is to structure how we do work so we can more easily recruit and retain contributors. And I think restructuring how we expect our project to interact with users so that users can more easily connect with people with the same software interests is going to be the way to do it. Let me harp on recruiting for a second. So far we've been relying significantly on people with a certain level of pre-existing experience. I think to grow further we must start the process of being able to train a larger pool of inexperienced but enthusiastic people into become effective contributors and taking on some of the workload we know we need to get done day-to-day and release-to-release. And I think we most easily do that by capitalizing on a new person's particular software interests and make room for them inside a work group (a SIG) organized around all the tasks associated with managing the user-experience for a subset of software that matches why they are using Fedora. I want to build a structure that works like this: Users find software they like or need, then they join the community based around that software (the SIG) looking for help or advanced training or just new information about upcoming versions, then they start contributing to that community's effort to push that software forward by responding to a SIGs specific need to fill one of the easily defined roles. Experienced SIG members act as mentors and sponsors for the new contributors. The subproject that supports that role participates in the training of the recruits across the different SIGs. As they get comfortable with that role the new person can choose to become more involved in development of policies and tools as part of the subproject that defines the best practices for that role. If they find out their particular talents aren't suited for that role, they can continue to work inside the SIG where there interests lie, but take on a different role. if there interest grows beyond a specific SIG and wants to take on tasks with Project wide impact, they can then look into participating in one of the support subprojects like infrastructure, or translation. For example, It'll be a lot easier to sucker someone into helping with QA, if we make the QA effort a role that each SIG is encouraged to fill internally from its userbase. Once SIGs establish a user-communication aspect, a particular SIG should have an easier time of asking its users to fill a QA role specifically for software the SIG shepards. Instead of the pain of asking users on a project wide to jump into a project wide QA effort spanning all software that they are unfamiliar with. Looking at things project-wide becomes daunting. But if we set things up in such a way that we can ask users to take on a piece of the responsibility for the relatively small subset of software they care about, through a SIG role, then its going to be a lot easier to get them to take that first bite. The same with documenters, and maintainers and so on and so on. The structure of the role based SIG also gives us the ability to start looking at retainment issues, which we have put exceedingly little thought into. Formalizing the roles should make it easier for people to move around and do new jobs, gaining new skills, when they are getting burned out doing the same thing...but still within the scope of software they are most interested in working with. -jef _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
