Getting Started

If you're interested making more than just casual merge requests on Sone's public projects, we ask you to complete a small contributor application on our website for us to get to know you a bit.

What is a contributor?

A contributor is essentially our definition of a worker. We use this word as a way to classify and log a person's contributions of labor to our projects and organize how we provide them resources.

Why do I have to apply?

While we do offer the ability to contribute casually to our open projects, we do require folk who would like to be more involved to apply so we can get to know them better, register them in our automation processes, and provision the items they would need to contribute more effectively.

Registered and approved contributors also have the ability to contribute to our projects in development that are yet to be openly released.

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

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.