Skip to content

Latest commit

 

History

History
53 lines (38 loc) · 2.39 KB

CONTRIBUTING.md

File metadata and controls

53 lines (38 loc) · 2.39 KB

Contributing to events-distributor

Collaboration

  • PRs require at least one reviewer approval (at least one should be on the "Core Contributors" list below).
    • See "Code Reviewing" section for more details.
  • PRs should be merged after receiving approval. Remember to remove the branch when you do this!
  • Responsibility of merging a PR ultimately rests with the submitter- if you've received at least 1 approval you may go ahead and merge yourself unless you have been been told to hold off for other reasons.
  • PRs will not be approved if they do not have 100% unit tests included.

Core Contributors & Engineering Management

  • Raúl Rodríguez Proenza (Core Maintainer)

SLAs

  • Core business hours: 10am to 4pm EST
  • Contributor:
    • The initial review should happen within 2 business days after assigned PR's reviewers. However, in many cases you'll see a response within 24 hours.
    • If changes are requested you may escalate the review if you haven't received confirmation of your changes within 4 core business hours.
    • Escalation response time from "Core Maintainer" is 4 hours.

Escalation Rules

  • Contributor:
    • If your PR isn't in a "changes requested" or "approved" state after the time specified in "SLAs" you may contact the "Core Maintainer" listed above to escalate the review.
    • If you don't receive a response from the "Core Maintainer" within the timeframe specified in "SLAs" you may contact the "Engineering Manager."

How to Submit PRs

  • At first, the PR should be reviewed by the contributor's team.
  • When the contributor's team is happy with the contribution, the PR's reviewer section should be populated adding the core contributor in order no notify them about such PR creation.

How to Review PRs

  • REQUIRED: Message the contributor directly to say that you've reviewed the PR. This helps to reduce turnaround time on PRs. Do not rely on the notification features in github- not everyone is using them.

Other Guidelines

The following are guidelines- they aren't required, but they should help make the code reviewing process go more smoothly.

  • Favor many smaller PRs instead of one big PR.
  • Create an Issue for each PR.
  • Close PR's issue after merged its corresponding PR.