jasder
/
school-of-sre
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
school-of-sre/courses/CONTRIBUTING.md

3.6 KiB
Raw Blame History

We realise that the initial content we created is just a starting point and our hope is that the community can help in the journey refining and extending the contents.

Reporting issues

We use GitHub issues to track bug reports, feature requests, and submitting pull requests.

If you find a bug:

  1. Use the GitHub issue search to check if the issue has already been reported.

  2. Check if the issue has been fixed. Try to reproduce it using the latest master or development branch in the repository.

  3. Isolate the problem before opening an issue.

Contributing content

As a contributor, you represent that the content you submit is not plagiarised. By submitting the content, you (and, if applicable, your employer) are licensing the submitted content to LinkedIn and the open source community subject to the Creative Commons Attribution 4.0 International Public License.

Ensure that you adhere to the following guidelines:

  • Should be about principles and concepts that can be applied in any company or individual project. Do not focus on particular tools or tech stack(which usually change over time).
  • Adhere to the Code of Conduct.
  • Should be relevant to the roles and responsibilities of an SRE.
  • Should be locally tested and well formatted.
  • It is good practice to open an issue first and discuss your changes before submitting a pull request. This way, you can incorporate ideas from others before you even start.

Building and testing locally

Run the following commands from the root of the repo to build and view the site locally before opening a PR.

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
mkdocs build
mkdocs serve

Submitting a Pull Request (PR)

Before you submit your Pull Request (PR), consider the following guidelines:

Commit Message Format

Please follow the Conventional Commits specification for the commit message format. In summary, each commit message consists of a header, a body and a footer, separated by a single blank line.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Any line of the commit message cannot be longer than 88 characters! This allows the message to be easier to read on GitHub as well as in various Git tools.

Type

Must be one of the following (based on the Angular convention):

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (whitespace, formatting, missing semicolons, etc.)
  • build: Changes that affect the build system or external dependencies

A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g.,

feat(parser): add ability to parse arrays

Description

Each commit must contain a succinct description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • don't capitalize the first letter
  • no dot(.) at the end

Body

Just as in the description, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.