Getting Started

Responsibilities

We encourage you to read through this section of the handbook to get a feel for contributor expectations and how we work, but when it boils down to it, our main asks for contributors are to:

• Not be a jerk
• Keep their assigned issue status' up to date
• Communicate any hurdles via issue comments or reaching out in the appropriate Discord channel

Getting further involved

If you're interested in becoming more than just casual contributor for Sone, we ask you to complete a small application on our website for us to get to know you a bit.

Why do I have to apply?

While the public is open to make a merge request on any our public projects, becoming a recognized contributor allows you to work on our private, work-in-progress endeavors before they are open sourced. It also gives us the ability to track your work properly, and allocate you resources in a more official capacity.

Contribution Lifecycle

To get an understanding of what the average contribution looks like, let's take a look at a usual lifecycle of events:

1. A user story is created in a planning session and an issue is added in the corresponding repository's issue list.
2. A contributor browses a repository's projects/issues that they are interested in working on, and looks for an issue with the Ready For Work status label.
3. The contributor then:
   1. Self assigns the issue to themselves.
   2. Updates the issue's status label to In Progress.
   3. Starts the time tracker.
   4. Leaves a brief, concise comment saying that they're starting work on the issue.
   5. If the work needs to be merged into the repository, the contributor creates a branch and assigns it to the issue.
4. The contributor communicates any hurdles via issue comments, and makes sure that there is a status comment posted before the repository team's check-in ceremony.
5. Once the contributor feels their work is complete, they:
   1. Stop the timer on the issue's work tracker.
   2. If a code contribution, create's a pull request on the repository that follows the repository's pull request template.
   3. Updates the issue's status to Pending Review.
6. The appropriate team will then peer review your work and leave comments about any items preventing your work from being marked as complete and updates the issue's status accordingly.
   • If the issue still needs more work to be brought over the finish line, steps 4 - 6 will be repeated until the peer review process is successful.
7. Once the contributor's work is approved:
   • If the work does not need to be merged into the repository, the issue's status can be updated to Complete and the issue can be closed.
   • If the work needs to be merged in to the repository, the issue's status is updated to Ready for Release.
8. When the repository has enough completed user stories that need to be merged in to make a new release, a release captain will run the appropriate release automation workflow.
9. Once the release is confirmed in production, the issue's status is changed to Complete and the issue is closed.