The mockups created to illustrate my assumptions were tested with users. Although my initial goal entailed testing the Contributor page, early research indicated that various aspects throughout the website could better support newcomers. For this reason, solely soliciting feedback about the Contributor page during testing would’ve felt like a missed opportunity. For example, if a newcomer lands on the website they may overlook the Contribute link in the footer. Therefore, I wanted to see the path users took to navigate to the Contribute page when links to it were included in the top navigation and the body of the homepage.
Four representative users similar to the personas were recruited to review the mockups. A script outlining the process and scenario was read to each participant. They were then observed while completing 6 tasks and answering follow-up questions related to each activity.
Activities and questions were structured around important goals for newcomers, which include:
- Learn about contribution opportunities
- Contact the project to ask a question
- Identify members behind the project
- Locate documentation
- Join the mailing list
Continue reading “User Feedback”
Before testing the design and content additions to support newcomers, I wanted to document the rationale behind the initial suggestions after several “in-house” design iterations.
Outlining the reasoning of design decisions is a process that can be helpful in producing stronger designs. It forces you to thoroughly think through your design and limits personal opinions when collaborating with others or discussing changes with stakeholders.
Join the Team Section
Join the Team Heading
Assumption: The “Join the Team” heading is vague and is a missed opportunity to briefly explain the mission.
Experiment: Change the heading to “Help Us Improve the Web” to make the page more scannable.
Ways to Contribute
Assumption: Linking to the report form and open issues disorients new visitors who want to learn more about contributing.
Experiment: Add additional context by explaining the process and allowing the current links to serve as calls to action.
Continue reading “Documenting the Initial Iteration”
As illustrated on our experience map, potential contributors often lurk and review a project’s online spaces in order to gain an understanding of the community. While the Web Compat project has great content for lurkers, it’s spread across the mailing list archive, Github, and personal blog posts. Thus, building out the content for the main site will be an important aspect in attracting newcomers.
Continue reading “Content Design”
After gaining an understanding of open source contributors and their experience with joining new projects, I reviewed the websites of 5 open source communities along with webcompat.com. The goal was to assess each site’s content as it relates to attracting new contributors.
I initially began with a list of three projects but decided to approach the process through the eyes of one of my personas. During the ‘Discover’ stage, as outlined on my experience map, a potential contributor searches for and or reads an article in order to find an open source project to join. As such, I found an article listing the “10 most exciting, active new projects” in open source. I then picked two additional communities that potential contributors could alternatively join.
Continue reading “Reviewing the Competition”
Third party research, stakeholder input, and information from public forums allowed me to further develop my initial assumptions about the site’s users. My findings included feelings and behaviors which were then grouped into broad personas in order to synthesize the research.
Continue reading “Understanding Users”
Sustainable open source projects rely on attracting and keeping new contributors. However, many newcomers fail to participate beyond their initial post and core members can leave at any moment.
So what drives potential contributors to join or stick with a new project? And what can communities do to attract and retain members? Below I outline several motives and barriers to open source participation along with potential strategies to support newcomers.
- Self-promotion: Experienced developers will often join a project to build their own reputation. Communities can motivate these developers by acknowledging and publicly celebrating contributors.
- Completing coursework: Students enrolled in computer science courses are often required to contribute to an open source project as part of an assignment. Delayed answers can be a major pain point for this group, as they’re often working against a deadline. Responding promptly to communication helps keep students motivated and engaged.
- Learning: Improving one’s programming skills and learning a new tool are common motivators. Supporting beginners with clear documentation, learning resources, and “how to start” guides can help foster a supportive learning environment.
- Cultural differences: Messages can be misconstrued as rude due to language and cultural differences. Maintaining regional newsletters and connecting members who speak the same language can help mitigate cultural obstacles.
- Development environment: Setting up the development environment is a common hurdle experienced by newcomers. Providing preconfigured development environments and step-by-step tutorials may help.
- Task selection: Newcomers may find it difficult to choose a task that matches their skill level. Communities can help by providing meaningful direction in the form of mentorship as well as information about task size, required skills, and difficulty level.
To learn about additional contributor motives and barriers checkout the sources below.
Continue reading “Motives for and Barriers to Open Source Participation”