As our team grow, it is important to recognize we have standards and practices that are in place to help alleviate the learning curve on the things we do on a day-to-day basis. Software developers that are with the company for more than one year should know these standards and have already adopted these standards in their daily workflows. If this is you, awesome! Keep doing the things you do.

However, If these standards are new to you, because you are new to the company or do not realize that they exist, please revisit the S&P repository for additional information. We encourage you to get familiar with these standards, understand why we have them and adopt them as your own personal development habits. For your convenience, here is a list of standards that Michael Chrisco (S&P lead), myself and your technical lead will be looking for to determine whether standards are being followed.

If you have any questions, comments or concerns, do not hesitate to reach out to one of us for additional context.

1. Github project boards need to be setup according to S&P guidelines
2. Assign @Shift3/pr-team to your pull requests, per our code review process
3. Assign pull requests to @Shift3/pr-team in addition to the developers on your project

Assigning a pull request to @shift3/pr-team will automatically assign three developers from the pull request team and assign them to perform a review.

This provides a quicker turnaround on your reviews and feedback from team members with different perspectives and skill levels.

1. Pull requests should not be more than 24 hours stale

It is the responsibility of the S&P lead and / or engineering manager to follow up with the developer or lead on a project to address stale pull requests.

In the event an assigned developer is uncomfortable or unable to provide constructive feedback, the developer should indicate so in the comment section and to ping the S&P lead and engineering manager for assistance. On such an event, the S&P lead or engineering manager should either resolve the pull request themselves or reassign it to an appropriate developer with the expertise to perform the review.

Pull request creators should be the champions of their own work and are encouraged to ping the #bwtc-code-review channel when their pull request is going stale.

In the case of an urgent pull request or a request that needs immediate attention, the pull request creator could also contact the assigned reviewers to expedite the process.

On rare occasions, when a pull request creator could not find a reviewer within the 24 hour window, the pull request creator should ping @here in #bwtc-code-review slack channel for assistance.

1. Format of GIT commit messages and title follow Karma Commit standards.

Example: fix(login-screen): logo should display correctly

1. Branch name includes developer initials, the issue number and a short description

Format: <initials>-<issue#>-<short-description>

Example: mac-999-fixes-deploys

For additional information, refer to the docs here.