Contributors are Empowered When They Know the Process

There is a saying in the legal profession that you should never ask a question you don’t already know the answer to. Despite how this sounds, it is actually a rule most people follow in life. This is the source of that feeling you get when you’re too scared to raise your hand and ask a question. In Open Source we need to make sure that contributors feel like they already “know” the answers, so they will feel confident in making the request.

As a university lecturer, I always encouraged my students to first think about what they thought the answer was and then ask the question. In some cases, I encouraged them to actually write down what they thought the answer was. In this way, they could judge both their skills and their ability to grow based on what the answer turned out to be. It created an additional feedback loop.

In Open Source, we see people making requests or asking questions when they already know the answer a lot. Highly experienced contributors already know whether a patch or feature proposal is likely to be accepted before they make it. This is because they are applying their experience, their domain knowledge, and they have often had multiple small conversations with other contributors before they even got around to code or proposals.

This backfires when contributors are working in an area where they lack domain knowledge or where they don’t know the norms and standards. At that point, they tend to not ask questions and get nervous about making proposals. They fear rejection or getting an unexpected answer. This is where policies and documentation can help a project.

Defining the Process

In the Fedora Project we have a group of teams we refer to as the Mindshare Teams. They are focused on helping our community grow both the number of users and contributors. The teams in Mindshare are each focused on a different aspect of this goal. These are teams such as Marketing, Design, and Documentation as well as a steering committee. These teams operate as part of the project in tandem with our Engineering Teams.

The Fedora Project has been working to make it easier for people to work on Mindshare activities. These are activities to increase awareness about Fedora and spread the news about the Project. This includes holding release parties, attending conferences, and giving talks. The Project enables these activities by providing swag, funding, and by connecting people to work together.

We have found that people have an unlimited pool of great ideas and are very open to meeting and working with new people. Where they get worried is asking for swag and funding. They don’t know what is “too much” or if their idea is “right.” They don’t know how long the process can take and are worried that even if approved the reimbursements could take forever. They lack domain knowledge.

What we did in Fedora was create policies and documentation for different kinds of activities. These docs spell out exactly how a decision will be made and what the norms/standards are. For example, we have a document about holding small events that lets you know that the typical budget is $150, that you can ask for swag, and that it takes about three days to approve the request. It even spells out what is required for approval and how to get the swag and your reimbursement. If a contributor already knows the facts and can look at the history of decisions they are now domain knowledgeable and will be comfortable making this request.

But, we didn’t stop there, we also wrote documents about medium-sized events, those with a budget of $1000 or less, and large events. These explain the longer timelines and how we expect large event requests to result in a conversation, not just an up/down vote.

Does it Work?

We see lots of success with smaller events like release parties and new ideas like meetups. We’ve had some medium and large requests around travel funding for conferences like Red Hat Summit. Where we have had the most interesting conversations have been around sponsoring and participating in events like OSCAL and SELF. The most exciting outcome is that we are seeing requests from a greater variety of people than in the past. This is good for our project as it means we are reaching new audiences and locations and that more of our community feels empowered to be successful. Now that people know how they can ask and what our norms are, they are asking.

By clearly setting expectations we are hoping that many of our contributors will help us achieve our Mindshare goals by not only improving the project output but also through attracting more users and contributors who are like them. By defining our process and decision making we are making it easier for contributors to participate, especially in areas, like Mindshare, where they don’t feel like they are knowledgeable.