Beyond Programming: New Ways to Help With Fedora Repository Development
Submitted by on Mon, 2010-08-09 14:10
From Thorny Staples, Director of Community Strategy and Alliances and Director of the Fedora Project, DuraSpace
Ithaca, NY In my recent travels, I have been hearing that there are people out there who would like to get involved in the Fedora repository development process in ways other than programming. I thought that I would use this opportunity to get the conversation started.
I hope that everyone is aware by now that the development process has moved completely (and rapidly!) away from being a DuraSpace project to a completely community-based project for which DuraSpace provides resources and acts more as the catalyst. We now have a commiters group who control the code-base completely, voting on which features get added based on a database of feature and bug-fix requests that is added to by the community in general.
I am very pleased to say that we now have 11 committers, 8 of which are not directly associated with DuraSpace, who come from Denmark, Germany, the UK and the US. They meet every Tuesday at 11:00 eastern time in the US in a joint conference call and IRC chat. Information about the process can be found on the wiki at:
Meetings are open to anyone who would like to participate. All code development discussions happen on the Fedora-developers mailing list.
Several other possible roles have been discussed that would help out immensely. These roles could be filled by individuals or groups, but would generally involve participating in the meetings and email discussions to provide help in ways other than the programming.
The first role is a communications function. It would be great to have regular reporting going on the help the community at large know what is going on with the core development process. This would involve direct participation in the process and regular reporting to the list about what features were under discussion, why they get onto the list of features for the next release or not, how the features will be implemented, surveying the community when there are questions that need answers from the wider community, etc.
Another function that is related to the first one is helping with recruiting for new contributors to help with the programming. Many features are deemed to be important and appropriate for inclusion in the
code base, but the committers just do not have the time to do them all. Help with connecting with programmers who work for institutions that need particular features and bug fixes to be done more quickly would be really help. Note that the governance structure for the committers group specifies that new committers can be voted onto the group based on code that is contributed.
Help with the documentation would be a great addition to the group. If anyone is interested in participation in testing and documentation at release time, working with a programmer to develop more elaborate docs for new features, re-writing and improving existing documentation, adding to and updating information on the wiki like the “Getting Started” pages, etc., we would love to hear from you!
If you are interested in participating in these ways, or other ways that we haven’t thought of, you can let me (firstname.lastname@example.org) or Chris Wilper (email@example.com) know, or write to the developers list directly. We can also get discussion about any of these roles on the agenda for a commiters meeting.