The roles one takes in an open source community are defined around the ways a role participates, collaborates, and contributes to the community and the various community outputs. It is a common misconception that the only or most valuable way to contribute to an open source project is to write code. There is a saying, "All contributions are of equal value," that sums up the best approach to take.
One part of this is simply not trying to predict the future—you literally cannot know or predict which contribution or contributor is going to have lasting impact on the project. An accumulation of small contributions, for example, can easily have the same impact as a smaller number of large, splashy contributions. Someone might participate in a short user experience workshop and provide a valuable, lasting impact they are not even aware of beyond their brief interaction.
The most important part of why all contributions should have equal weight is that a community is made up of people, and the feelings and experiences of these people literally are community. The things each person brings to the community—their contributions—become a very personal currency in the project, a way of knowing who can be relied upon to do what.
As people grow in their skills over time in a welcoming and inclusive community, whatever the nature of their contributions are, they will have impact far beyond the reach of one person. They are better able to grow to their greatest potential by being allowed to stretch themselves into, then beyond, their roles. One way this "being allowed" manifests is by removing any level of judgement, difference of value, or even shame over different types of contributions.
So it’s a way of recognizing that all people are of equal value in the world, and what they bring each day needs to be weighed as simply the best of a human being in that moment. This is a meaningful way of being inclusive, permitting people to be a 100% contributor regardless of however they are able to participate and behave on any given day.
It’s never too early to think of how you can make a contribution to a project or group you’d like to join. By doing so, you catapult the project further ahead in meeting your needs and the needs of all its users. Furthermore, you can get recognition, improve your skills in a safe environment, and build your network through the people you work with.
This document covers several roles played by contributors. It may be interesting to see how roles are similarly or differently defined by the [CRediT](http://credit.niso.org/) project for academic papers.
Documentation and training materials are crucial to recruitment and to making new members of a group productive. Writing technical documentation is one of the major under-appreciated contributions one can make. As one blogger put it, "Computer documentation has long been like government funding: nobody wants to contribute to it, but everybody wants it to be there when they need it." This section walks you through steps to creating documentation.
If you notice a hole in the documentation for a project or team, approach the project leaders or ask on the community forum whether anyone is working on documentation for a topic. On a site that allows "issues" such as GitHub and GitLab, you can also request a document by creating an issue, but it’s simpler to start by asking informally whether someone is working on such a document.
If you find someone who is already working on a document you believe necessary, offer to become a reviewer. Sometimes you can even help as an author, but authors must be careful to cleanly and clearly separate the topics assigned to different authors. Documentation tends to be less modular than software.
If no one is working on a document, and the community or project leaders support the creation of a new document, the next question is: who would be the best author? The answer normally is: you. There may be other people with more expertise in the topic, but if they haven’t created the document already, they probably are unable to do so because they are busy, don’t like to write, or for some other reason. The best author is the one with the desire to write the document, and if you proposed it, you are probably that person. Subject matter experts can feed you ideas and review your writing.
At this point, make a formal announcement, such as by creating an issue. A due date is recommended, to provide some pressure to finish the document. Remember that a document needs to be reviewed, which could add several weeks to the project. It is also useful to create milestones, which could include:
-
Start writing
-
Circulate first draft
-
End of review period for first draft
-
Circulate final draft
-
End of review period for final draft
-
Submitted for approval
-
Approved and published
To be accepted into a project, the leadership or advisor group responsible for the project must approve it. These leaders should be liberal in approving documentation projects, because any new document that is relevant to a project will usually prove useful to at least some members.
After you get approval to write a document from leadership, go through the following steps.
Find out the preferred format—such as Asciidoc, Markdown, etc.--used by the team. Most projects integrate documents like source code files, so that the project doesn’t have to invent special tools and processes for such tasks as filing bug reports on documents.
You probably looked at your project’s documentation while researching whether a new document was needed. Before starting to write, you should do searches online and check project documentation for projects similar to yours. Collect links to relevant documents and other materials such as videos that provide background for your readers, or sources of advanced information they can look at after reading your document.
Viewing existing documents written by your project or other projects on similar topics might help you get started. Look for documents written for an audience like yours: developers, end-users, etc.
Writing is a skill with many levels of proficiency, but a few guidelines can help inexperienced writers produce a useful document.
-
Always think of the people you’re writing for. Defining the audience is the most important part of planning a document, after the topic is chosen. Ask questions such as: will most of my readers know the technical term I’m using? Do end-users need to know the technical details that developers talk about? Do I need to describe how to find a web page or other resource before I talk about using that resource?
-
Try to frame directions as procedures divided into small steps. Those are usually the easiest directions to follow, particularly if you lay them out as an order list. Don’t write from memory: always go through the procedure while you write it up. Otherwise, you’re almost certain to forget a step or describe something incorrectly.
-
Structure your document. Keep sentences short. Try to break up long paragraphs. Assign new headings frequently. If you find that you’re writing a dozen or more paragraphs in a section and can’t figure out how to break the section into smaller ones, you are probably creating badly organized text that doesn’t flow well.
Usually, the author should circulate an outline for review before writing the document. The outline ensures that all important topics are covered, but that the document won’t contain unnecessary topics. Reviewers can also suggest reorganizations. However, the author often finds reasons to add topics or move them around when turning the outline into the actual document.
References to related documents are an important part of most documents. Authors should do research to find relevant documents, as stated earlier, and include them. Inline links can be useful, particularly to send readers to background in case they have to learn certain basic information to understand your document. However, it’s generally most useful to provide a section of references as the end of the document.
Reviews of documents are crowdsourced, meaning that we welcome reviews from a variety of people who differ in knowledge and ability, formal training, race, gender, geographic location, and more. This greatly increases the value and readability of the documents.
You can tell us what you think is incorrect and what is missing. Recognize that we try to keep documents short so that busy people have time to read them. References to good documents and other resources are very valuable.
Editing, proofreading, and spell-checking are also valuable ways to contribute.
Reviewing is a good way to pick up our tone and style in preparation for writing your own documents.
These committees also need leaders. After you participate for a few months, we hope you will consider stepping up into a leadership position. Expertise pertaining to the goals of the group is helpful, but leaders can also help by coordinating people in their tasks, facilitating meetings, and other organizational tasks.
A personal appeal from a respected friend or colleague is the most effective way to recruit new team members. When you find a project you support, think of other people who would be valuable additions to the team. After you learn enough about the project to describe its goals and how the team operates, reach out to prospective new members.
Most volunteers bring useful knowledge into a project, and learn more as they participate. You can share this in many ways: by answering questions on forums and chats, mentoring people, and showing up at group meetings.
- What is translation
-
Translation the software interface and documentation into a different language. The result is a software package that has been localized for people to read the interface and documentation in their preferred language.
- What a translator does
-
Works with tools and processes to translate the software interface, documentation, marketing material, release notes, etc. into one or more languages. Many projects use a common process or model, so learning how to translate in one software project may be a reusable skill in another project. Linux distributions such as Fedora Linux have translators who work on all parts of the operating system, translating it into many dozens of languages.
- Why do people like this role
-
One way many people have contributed to the spreading of open source softwae is by translating the software and documentation into their local language. They use this as a way to bring the benefits of free and open source software to their locale.
- What is system administration
-
Creating and maintaining operational computing systems on behalf of the project. The role skillset may call for a range of sysadmin/operational/DevOps experience, depending on existing systems and what is planned.
- What a system administrator does
-
Works with all aspects of the project on underlying infrastructure. This infrastructure provides the ways to participate and collaborate in the project.
- Why people like this role
-
Learning new skills and working with new technologies. Often people have experience or an inclination to do this work, if not professionally, then as a serious hobby. Especially with modern automation, the role of administrating systems is continuing to change.
- What is fundraising
-
This is the act of finding people and organizations interesting in donating money, hardware, or services to support the project and community. Sponsorship can take many forms. For projects that are not enabled to take in cash donations, sponsorship more often comes in terms of access to events, travel, booth staffing, and so forth.
- What a fundraiser does
-
Works with project leaders, any parent organizations such as foundations, and the people and organizations interested in donating and sponsoring. This involves working through the details of the sponsorship, whether it’s a one-off or part of an ongoing campaign to close aspects of the deal. It may involve further administrating of the sponsorship, funds, grant, or whatever form the donation takes.
- Why people like this role
-
They understand the importance of creating sustainability around open source communities, and want to make a difference. They may have some skills or personality traits that make the effort more interesting or valuable to them individually.
- What is marketing
-
In open source software, marketing is the act of promoting the community and its software efforts. Other practices, such as market research and advertising, do not typically happen in the community itself.
- What a marketer does
-
Works with different parts of the project to help them ini understanding what their users want and need, then to simplify and amplify those messages out to the world. Feedback from users in open source often goes directly to the development team, in the form of bug reports and user help. Unlike in a closed software development method, the contributors closest to the content and code tend to have a high level of knowledge about the user base. Marketers can help gather, clarify, organize, and prioritize that information into feature sets and roadmaps.
- Why people like this role
-
People who are interested in the modern world of marketing beyond the "it’s all digital" point-of-view can see the aspects of truth, openness, and transparency that are hallmarks of some brands in the world, mirrored in the very processes of open source development.
- What is outreach
-
This is the work involved in connecting with users, participants, and potential contributors, as well as the world in general. These connections are for more than marketing, it may involve aspects of recruiting, user help, feedback gathering, audience analysis, tech support, and so forth.
- What a outreach coordinator does
-
Works directly with creators in the project (code, content, design, marketing, etc.) and acts as a two-way conduit from the project into various forums. The forums might be web-based or mailing lists the project maintains, they may be blogs and tech journalists, they may be websites users go for asking and answering questions. A person doing outreach is knowledgeable to some degree about nearly every aspect of the project, able to identify and establish conections from those parts of the project to the outside world.
- Why people like this role
-
This role involves getting to know people and processes, and communicating about them. It’s an opportunity to be the proxy for people who otherwise might not get heard from in the project, helping to bring those voices to the forefront.
- What is community architecture et al
-
With the success of an open source project hinging as much on the community as the code base, most projects have people formally or informally doing the role of designing and helping maintain the community itself as a top priority.
- What a community person does
-
As a core part of their role, this person would be aware of and oversee or directly implement the many best practices in this guidebook. When this role is comprised of multiple people or is only part-time staffed, people involved tend to focus on the practices most germain to the project. In this way a project that is light on community management/enablement resources can still get the key parts done, eventually.
- Why people like this role
-
This role is for people who enjoy communicating, collaborating, and connecting other people. It’s helpful if you get as much joy out of watching other people succeed—while helping celebrate that success, of course—as you do outy out of your own successes. The role is also attractive to people who are interested and skilled at doing a lot of many varied things (a jack-of-all-trades
The range of possible pieces of software that can be written for one field or another gives some idea of what can fit in here. This can mean specific technical skills, such as a geographer in a Geographic Information Systems (GIS) project. This can be general technical ability, which is often needed for complex problem solving.