Thank you for your interest in having your project participate in Dev Days, an event hosted by the Academy Software Foundation. This document outlines guidelines for projects to follow as they participate in Dev Days.
| Table of Contents |
|---|
Setup your Dev Days infrastructure
To particpate participate in Dev Days, the project needs to have a few things setup set up to make it easy for participants to identify issues to and work on how how to get engaged with the project.
Tag issues
...
for Dev Days participants
...
To have an issue be marked for Dev Days participants to choose from, make sure that the issue...
... has the labels "good first issue" and "help wanted"
... is OPEN
... is unassigned
... has been updated within the last year
You can validate this by looking for it in the list here! Some other labels you should add to these issues include:
Add the label "docs" or "documentation" to indicate if it's a documentation specific issue ( these are great ones for Dev Days! )
Mark the difficulty of the issue to help guide the participant
easy: the issue has the
...
label
difficulty/easy
...
or
level/easy.medium: the issue has the
...
label
difficulty/medium
...
or
level/medium.hard: the issue has the
...
label
difficulty/hard
...
or
level/hard.
You can also use the labels below to help participants filter on the kind of issue it is, but this is probably less crucial.
bug: the issue has a label that contains the
...
string
bug.feature: the issue has a label that contains the
...
string
feature.enhancement: the issue has a label that contains the
...
string
enhancementorimprovement.
Ensure the issues are well filled out and defined.
Know that the individuals coming to look looking at the issues available will be new to the project and will vary in their levels of experience.
A "good first issue" will have the following key characteristics...
The problem(s) and use case(s) are articulated.
The scope and expectation of the outcome is clear.
The methodology for determining if the issue is addressed is outlined.
One or more people identified that could provide mentorship to the contributor.
Check out this article for advice on ensuring your project has good first issues that new contributors can easily start on.
...
This page, which can live directly on the project's repository, wiki page, or even website, should elaborate on any project-specific details not covered on the overall participant page.
Things that the page should have can include:
Specific build instructions ( you might already be able to reference this in documentation, but you could also detail any first-timers' gotchas ).
Communication preferences for the project ( is it best to ping on Slack? Mailing Lists? What times are other project members generally available? )
Anything non-obvious about the project or not well documented that would confuse a first-timer.
Feel free to check out OpenColorIO's Dev Days page for examples of what your might include.
Choose A Dev Days Project Lead
Participating projects should have a member of their TSC specified as Dev Days Project Lead. This person will be responsible for organization on the project side, as well as communication between the Project and the Dev Days team. This person should fill out to project registration form below!
Register as a participating project.
You can register as a participating project using the form at XXX here. The Dev Days team will review the application and contact you if there are any questions or concerns. Once accepted, your project will be added to the Dev Days 2024 web page as a participating project.
Getting ready for Dev Days
Once the participant application period opens, expect many prospective contributors to contact you to get more information about the project. Be prepared for this, and try to be as responsive as possible. These prospective contributors are often quite excited about participating in your project but might feel intimidated. First impressions are key to harnessing this positive energy and having participant choose your project to contribute to.
Some other tips to consider:
Hold office hours or open house calls in the weeks before Dev Days to allow participants to ask questions.
Once a participant decides on the issue to tackle, reach out and ensure they have their dev environment set up.
Provide documentation and other resources to help them be productive during Dev Days.
Ensure you know the participant's planned working hours so you can have project maintainers and other contributors available to answer questions.
During Dev Days
The two days of Dev Days can be a whirlwind! Even with good planning, expect bumps along the way with participants having technical issues, questions, etc. Be empathetic with these participants; most have good intentions and are participating in open source for the first time. This article is a good read that will help you understand the journey from first-time contributor to maintainer in an open source project. We expect participating projects to plan for having at least one core developer available at a time to answer participant questions and review PRs.
After Dev Days
Once Dev Days wrap up, hopefully, you will have some solid contributions to your projects. If you have a few that are close but aren't quite there, help the participant finish things up.
We are in the process of defining post-Dev Days activities, which will include reports on who completed the event and the contributions made. Stay tuned!
In closing, thank you for having your project as a part of Dev Days. We hope that this experience is not only good for these first-time contributors but also helpful to the project in having new contributions come in and helping your project improve its first-timers experience.