This document should be read by project leaders at least 1 week before the event. It contains the necessary information to aid the project in being successful at the event.
This doc also serves for sending out to people who show interest in being a project leader, by clarifying what are the responsibilities. This way they can make an educated decision whether it’s suitable for them and for the project.
Those could be bugs, features, documentation, tests, usage etc. If there are github labels like “up for grabs” or “good first bugs” that’s great.
It’s easier for participants to get a small printed paper with instruction and important data. Here’s a template with 4 sheets per A4 page with the relevant data for you to fill out: https://docs.google.com/document/d/1rEw6BDuNxSJBvn6G7fmlN9PP7RgeSI1HgeCcKfUK_cw/edit?usp=sharing
Installation can take up too much time during the event. We’ve seen this happen, even to the extreme of spending the whole event just installing a local dev environment. To avoid this, add the instructions from the cheatsheet to the event’s project document. The registered participants will get a link to the document, and be able to install local dev envs for the projects they might choose to participate in. This will speed things up and help you avoid unnecessary delays in development during the event.
Optionally, you can prepare a theme for the event - a big feature for everyone to work on, or a similar task like code cleanup, visual polish, tests, documentation, etc. You could prepare a few themes and divide into groups.
Present the project in 1 minute. Highlight its purpose, work that needs to be done. Inspire people and attract them. No need to get technical or talk about how contribution works in this specific project, unless it’s part of the pitch.
After project presentations, take ppl who want to join you and do a deeper intro session about how to start. From here on it’s freestyle based on the project, people and you.
Tell people to tag the issues and PR’s they work on with #goodnessSquad (just add this hash tag in one of the comments). Then we can show what was worked on by running this filter:
https://github.com/search?o=desc&q=%22%23GoodnessSquad%22&ref=searchresults&s=created&type=Issues&utf8=%E2%9C%93
During the session it’d be great if info is gathered about what was done. What issues were resolved? Opened? PR’s opened? PR’s merged? docs/tests written?
At the end of the event one of the team members you can present those statistics to everyone.
You are responsible to gather this info.
TBD: a structured checklist should be filled by the lead. Based on the first 2 events where this went a bit astray. Still need to make up this checklist.
NOTE: in the first 2 events the one who reported what was done was a team member. This was nice in terms of engagement, but my feeling is that the project lead has this info much closer to heart and can deliver it from a better perspective