Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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.

Setup your Dev Days infrastructure

To particpate in Dev Days, the project needs to have a few things setup to make it easy for participants to identify issues to work on how how to get engaged with the project.

Tag issues that are for Dev Days participants to choose from

To have an issue be marked for Dev Days participants to choose from, make sure that the issue...

  1. ... has the labels "good first issue" and "help wanted"
  2. ... is OPEN
  3. ... is unassigned
  4. ... 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 enhancement or improvement.

Ensure the issues are well filled out and defined.

Know that the individuals coming to look 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.

Create a Project Specific Landing Page

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 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.



Register as a participating project

You can register as a participating project using the form at XXX. 

Getting ready for Dev Days

During Dev Days

After Dev Days

  • No labels