| layout | title |
|---|---|
post |
Open Source Workshops |
How to Build Community with Open Source Pairing Workshops
Volunteers and students often leave a Bridge Workshop inspired and excited by the experience. Students may attend more workshops, but find they want real-world experience. Volunteers find they want the opportunity to reconnect with the same people.
We've had success building community and creating mid-level and advanced learning opportunities through open source coding events. We found that experienced engineers really enjoyed being able to contribute even with a commitment of just one evening, and that pairing was great for people who were new to open source or less experienced with coding in general or with the particular technology stack used by the project.
- There are developers of all skill level who are interested in participating in open source software projects.
- There are many open source projects looking for help
- It can feel daunting to get involved in an open source project. Where to start?
- How to begin understanding the codebase? Where to look first?
- What is a good first contribution? A feature? Documentation?
- What is the right way to submit a contribution
- There are also a lot of collaborative processes that developers may not realize are at work in open source
- What place do PRs have in the contribution process
- How to solicit feedback on your work
Provide workshops, built around real world projects, that create a welcoming environment for developers to build their skills by contributing to open source.
The following steps outline what we believe made the workshops with 18F and Open Data Maker successful.
- An interesting / motivating project will create a sense of excitement at your workshop. Does the project have an altruistic goal? Does it provide value to the community?
- A project with a clearly defined goal / upcoming milestone will help focus the participants at your workshop.
- A project which has the opportunity for people at all skill levels to contribute will make it easier to help anybody who comes to the workshop find a way to contribute.
- A project with an easily visualize-able end state. Whether that is visual design of a set of screens, or a clearly understandable use case for a library.
- Somebody who can provide context for the project and its objectives
- Somebody who can articulate the upcoming milestone
- Somebody who can organize a backlog of work for the workshop
- Somebody who can facilitate getting started with the project
- Somebody who can answer questions about the features being worked on
- Figure out who your community is. Is it centered around a language? Is it centered around an activity?
- There are members of your community who have open source experience.
- Invite members of your community with varying experience levels. This is an easy way to show people new to open source that it’s easy to get involved.
- It can also be inspiring to have more experienced contributors around, they can provide context, perspective, and tell stories about how they got involved.
- People are generally excited to show others what they know. To help others learn how to do what they do. Communicate how valuable this is — for the students and for the project.
- Identifying features and bugs that cover a variety of experience levels means both new and experienced developers alike can find a way to contribute.
- Try to maintain close to a 1:1 ratio of people who have contributed to open source before and people who have not. Pair people who have contributed before with new contributors.
- If possible, use the new contributor's laptop so they are the one set up with the project.
- If possible, use the new contributor's github account. Have them fork the repo and make the PR. Not only do they learn about the process of forking and PRs but they also get the satisfaction of seeing work they did merged into the project's main code base.
- Keep the workshop casual, an evening after work
- A project maintainer, outside of identifying features to work on, shouldn't need to do too much prep
- Make it easy for people to submit partial work. A WIP PR is better than no PR. This way, the new contributor can get the experience they're after without needing to commit to finishing a bigger chunk of work.
- WIP PRs can be picked up by other people in later workshops, reducing the amount of work you need to do as a project maintainer.
- If you can schedule workshops every few weeks, make it easy for people to return to work if they're interested in completing a feature they picked up.
- We found that it was much easier to organize an open source night than a typical Bridge workshop, since there was very little preparation needed, except by the project mantainer who usually was doing that kind of issue grooming anyhow.
- Having two less experienced coders to one more experienced was fine, groups of three seemed to be as positive a experience as a pair
- Here's an example of the Event Description