On Sat, 2015-07-11 at 22:38 +0100, Jonathan Underwood wrote: > Dear All, > > Recently I started a thread drawing attention to the large number of > folks who have submitted packages for review and require sponsorship, > and the length of time some of those sponsorship requests have been > outstanding. A number of people (notably Ben Rosser and Michael > Schwendt) eloquently shared perspectives on this from the perspective > of a new contributor who recently sought sponsorship, and long time > contributors and sponsors feeling somewhat burnt out by the > review/sponsorship processes. It was very pleasing to see the thought > and time people put into those responses, so thank you. > > I'd like to attempt to distil some of that discussion, and offer some > thoughts on how we might improve things. > > 1) Fedora as a project has evolved massively from the early days, when > contributors were part of the Fedora Extras project, in terms of > culture, goals, tooling, nature of its contributors, processes and > documentation. In that time, one thing that has changed very little in > the midst of all that is the sponsorship process. > > 2) Improving the sponsorship process in terms of attracting new > contributors rather than leaving them discouraged with long waits for > sponsorship would surely be a big win for the project. > > 3) There's a very strong feeling (that I too share) that we don't wish > to achieve (2) at the expense quality and commitment of contributors > (by eg. allowing drive by packaging, and packages of low quality). > > So, how might we change the sponsorship process to reduce burn out of > sponsors and reviewers, and avoid discouraging would-be contributors? > Here are some suggestions I'd like to make, and I'd welcome thoughts > on these, and other suggestions too. I am hopeful we can then come up > with a solid proposal for an improved process. > > 1) One piece of tooling we now have that is ideal for new contributors > is COPR. We should make more of this as it is an ideal proving ground > for new packagers with the benefit that it allows these contributors > to put their contributions into the hands of users and reviewers > quickly and easily, and so feel the warm glow of contributing - this > should not be underestimated - to attract and keep new contributors we > need them to feel a sense of accomplishment and achievement as soon as > possible in the process so they stay motivated. > > 2) We now have the possibility of obtaining sponsorship through > co-maintaining packages, but that's somewhat low profile and less used > as a route to sponsorship (just an impression-I have no data on this). > > So, rather than the initial entry point for new contributors being to > submit a new package review request, it looked more like this: > > Hi, it's great that you want to contribute to the Fedora project, and > drive it forward. Here's how to become a contributor: > > 1) Develop some new packages for software you want to see in Fedora in > a COPR repository to demonstrate your package creation and maintenance > skills. Keeping the packages up to date and of a high quality and in > compliance with current guidelines and practices is what you're aiming > for here. Also apply to co-maintain a package or two that are > currently in Fedora so you can learn from our experienced packagers. > > 3) When you think your COPR repository is looking like it has packages > of a high standard in it and they're ready to transition to Fedora > proper, and you feel you have gained sufficient experience to become a > fully fledged packager, contact the sponsors mailing list detailing > your portfolio of packaging experience and asking someone work with > you to transition a package or two from your COPR into the project. > Once your sponsor is happy with your level of expertise and > commitment, you'll become a fully fledged contributor. > > > In other words, rather than a package review ticket being the entry > point for new contributors, make COPR and co-maintainership combined > the entry point. > > So, that's something we could do with current tooling. > > But, I was also thinking of how things could be improved if COPR was > tied into Bodhi somehow. The badges system that we have hooked into > Bodhi is mostly a bit of fun at the moment. But, actually, if somehow > that badges system were available to COPR, then we'd have quite a nice > way to track new contributors activity, and could even require certain > badges to be achieved before the sponsorship could be approved. What I > have in mind here is that each COPR could (optionally) itself have an > updates and an updates-testing repo like the real Fedora repos, and > activity tracked through badges. Thoughts from the COPR folks? > > Cheers, > Jonathan. Hi, Jonathan, I am a long time user and observer of the process. I have not participated beyond that, although I once helped with a null pointer problem in some C++ code even though I didn't have the tools on my system at the time to look at the source code in a debugger. I manually tracked the pointer via search tools and text editors. I have experience in coding and design of projects in more than 20 languages and 9 operating systems. But always as support for existing systems, and always as tightly coupled code (basically every thing I wrote ran in real time with multiple hardware pieces interacting.) I have zero experience with COPR or repository systems in general, and have only used RCS's systems a few times because I am basically an independent contractor in terms of the support of customers, and as such most companies are hesitant to give a contractor access to their specific networks and systems. Also there are many different RCS's out there and I don't have time in most real world applications support positions to learn extra stuff aside from the requirements directly affecting the support (think of writing a 12,000 line program with real time support in less than 10 weeks, and also doing the hardware design and development in an additional 2-3 weeks, along with researching about 1200-1500 pages of device and support documentation.) I talk about all this because when you have someone who is interested, and even motivated enough to get involved, where does one go to learn the accepted techniques and support systems as a total newbie to the process? Do you have a link to an educational process? Are people greeted and provided links and encouragement? Where and who knows the requisite information to get started? I have personally given up on the idea of contributing directly, but there are others out there that you might capture if the tools and introduction are good. Regards, Les Howell -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
