Skip to content

Latest commit

 

History

History
71 lines (59 loc) · 3.91 KB

CONTRIBUTING.md

File metadata and controls

71 lines (59 loc) · 3.91 KB
Raw

Inspired by dwyl's contribution workflow.

Contribution guidelines

Before starting work

  1. Search this repo's issues to see if an issue exists for the problem you are solving.
  2. If the issue does not exist, create it. Include a descriptive body.
  3. If your new issue relates to any others, reference those issues in the body. This enables others to follow the history of the topic.
  4. Assign the appropriate label.
  5. Indicate on the issue that you would like to take it on. Assign one of the reviewers above if you need a response.
  6. Once you are sure of what you need to do and that it is needed, assign yourself to the issue.
  7. Clone, and create a new branch for your work

Labels

week-<name-here> - if your new issue relates to a specific week of the course (e.g. week-toolkit) bug - something in this repo is broken (e.g. a link) discuss - you'd like the community's input before you start any work question - you're not actually sure whether this is an issue or not and would like confirmation help wanted - you would like some help in completing work on this issue

Starting work

Commits

The commit history of each file should tell a story

Multiline messages

You will want to space your commit messages over more than one line. Commit without the -m to bring up a text editor in which to write the commit message.

You may want to configure git to use your preferred text editor, if you do not like the default. ie. Set atom to be default commit message editor.

The message should have the following format:

short description under 50 chars.
[newline]
more detailed description (may be bullet points)
[newline]
related #[issue number]

or

short description under 50 chars.
[newline]
related #[issue number]

Pull Requests

Once you have finished your work, push up your branch and make a pull request. Remember, a pull request should be as small as possible. This makes the review process quick and easy.

Make sure your PR has the following

  1. A descriptive title - distinct from others and therefore searchable
  2. A body with details of everything in the pull.
  3. Reference to any/all related issues in description.
  4. Assignees - add all the maintainers of master-reference to every PR
  5. Reviewers
    • add anyone other than the maintainers, who you think should be aware of you contents of your PR e.g. anyone else who has collaborated with you on this issue / anyone mentioned in the file you are uploading / mentors delivering this material in another campus
    • if your PR requires a review from a particular person / people before it is ready to be merged, specify this within the body of your PR

Instructions for maintainers

Once a pull request has been approved by two maintainers it can be merged. In time critical situations, one approval may suffice, as long a the pull request is small and is not suggesting any major change.

Thank you!

P.S. please star this repo.