Skip to content

Latest commit

 

History

History
40 lines (30 loc) · 2.99 KB

CONTRIBUTING.md

File metadata and controls

40 lines (30 loc) · 2.99 KB

Contributing

If you have something you want to add or remove, please use the following agreed upon process.

Initial Proposal Creation

  • Proposals are made by creating a GitHub issue or pull request (PR).
  • Issues containing the proposal are tagged with the area(s) under which they fall using GitHub labels.
  • The proposal is an appropriate granularity requirement to capture existing consensus.
  • The proposal is of the form When , we [MUST|SHOULD] .
  • Proposals are to be scoped to whether it applies universally, or can be decided on by individual project teams.
  • The body of the issue must describe the rationale for why the entry is needed
    • What is the danger if there isn't a best practice?
    • How do people most effectively follow it?
  • When appropriate, a proposal should include links to repositories, code or other similar DLSS reference examples of the practice's use.

Gaining Consensus

  • Consensus is gauged by people commenting with 👍 and 👎 (GitHub Emoji Cheatsheet)
  • 👎 must be described concretely as to why there is disagreement with that specific proposal
  • After one week, if there are less than four +1s or more than one -1, and no ongoing clarification discussion, the proposal is set aside for in person discussion.
  • Every second week we have a 1 hour long meeting for discussing the proposals that have been set aside. Proposals get no more than 15 minutes discussion time.

Accepting a Proposal

  • If at the end of the week or in person discussion there is four or more +1s and one or fewer -1, then the proposal is accepted.
  • After a proposal is accepted the proposer writes it up in markdown and submits a PR to the playbook, tagging the issue (if it’s not already a pull request).
  • PRs must not introduce new decisions beyond what was discussed in the issue. If further proposals are needed to flesh out the PR's content, they must be submitted using the method above.
  • Consensus review and accept the PR or work with the proposer to fix any issues. Fourth person to come along and 👍 ships it.
  • Otherwise if the proposal is not accepted it gets tagged "defer" as a note that consensus could not be reached and closed.
  • Deferred proposals should have consensus building around them before being reintroduced.

Editing, Organizing, and other contributions

Pull requests that enhance, clarify, or reorganize our playbook without changing the spirit of our documented practices should be merged with minimal process overhead. If there are 4 or more +1s and no -1s, then the pull request should be merged.

Guiding Principles

  • Don’t be a jerk 😃

Getting Feedback

Since these are our guides, we want everyone at DLSS to see them. We leave all PRs open for at least a week to get feedback from everyone.