This is a recipe for teaching new coders how to contribute with open source projects. It also serves as a practice for validating feelings of uncertainty that learners often and shows them how these feelings can be fertile ground for improvements to the open source project and prompting larger conversations amongst other community members of the project.
In open source projects there is often a power dynamic between maintainers and newcomers where maintainers decide what is important and newcomers obey. Open source doesn’t have to be like this. As someone who helps maintain p5.js, I learn from newcomers often! Newcomers are experts on how easy it is to learn a tool and often have other unique and valuable perspectives to share.
This recipe was adapted from an assignment I created for the p5.js Approachability Lab, which took place in 2019 at UCLA under the advisement of Lauren McCarthy and was based on prior workshops I facilitated with Write/Speak/Code around 2016. In both contexts, all participants were women or non-binary individuals. Given that open source maintainers are predominantly white cis men, this activity was also created to specifically validate and empower the voices of women and people of other marginalized genders in public spaces where software is made.
This recipe is an offering to all beginners, newcomers, and first-timers. You have knowledge to offer. We can all learn and work together.
Key words: open source, collective learning, feedback
This is designed as an add-on for another coding-based activity because it hinges on the participants having direct experience learning how to use at least a couple parts of the library.
I’ve written this recipe for p5.js because that is the open source library I use in my teaching, but this can be adapted for any open source creative coding tool that has a publicly accessible forum for feedback. This could also work with UI-based tools like Wick Editor.
Think back to the last project you made with p5.js. What was confusing about the commands you used? Did you encounter any bugs? What would have made it easier? For this assignment, you will document one of these moments and share it in the p5.js GitHub repository. Please include one idea for how you might change the commands, behaviors, or documentation to help future learners.
Your suggestion can be a small change or a large one, and it’s okay if you don’t know how to make it yourself. The feedback and ideas you have are valuable input for the continued development of p5.js.
Please share your submission with your facilitator before posting it to the p5.js GitHub repository.
The issue templates for p5.js at https://github.com/processing/p5.js/issues/new/choose are meant to provide a guiding structure to share feedback about the library. You can use those to structure your submission. Here are some things to include:
- what they were trying to accomplish
- what you expected to happen that didn’t or what was missing that would have been helpful
- screenshots or animated GIFs to help illustrate are very helpful
Navigate to the p5.js GitHub issue creation page and submit your issue. If you don’t have a GitHub account, you will need to sign up for one.
It is likely you will get questions or comments on your issue, either from the maintainers or other community members. You should respond to these in a timely manner (think of it like email), but remember that it’s okay to say you don’t know or ask clarifying questions before sharing more information.
A few notes on what I usually do as a facilitator for this activity.
I will have participants share their submission with me before they post it on GitHub, primarily so I can reassure that their idea is valid and worth sharing. I sometimes offer feedback on how they might communicate their idea more clearly, or of other issues I’ve seen related to theirs.
Once students have submitted their issues, I will occasionally check in on their issues to see how the conversation is going. If I see miscommunication in the conversation, I will comment to try and clarify from my own point of view. I usually don’t publicly weigh in on wether the idea is “good” or not because I think it’s important for them to get feedback (and validation) from the wider community at this point.