Skip to content

Latest commit

 

History

History
28 lines (17 loc) · 2.19 KB

CONTRIBUTING.md

File metadata and controls

28 lines (17 loc) · 2.19 KB

Welcome to the Engineering Framework contributors guide

Thank you for your interest in improving the framework.

In this guide you will get an overview of the contribution workflow from opening an issue, creating a PR, reviewing, and merging the PR.

The framework is concerned with engineering best practice at NHSD, however, operational matters (e.g. structure of teams, roles and responsibilities, etc.) are out of scope. Please consider this when adding new content, and if in doubt, any of the code owners will be more than happy to discuss.

If you're new to Github and/or Markdown, Github's own contributor's guide provides good signposting on these topics.

Using issues

If you have a change (or a new page) to raise, please create an issue first, and reference it in your commits. Before raising a new issue, have a look through the existing ones in case it's already been raised (Framework owners will strive to keep the list small enough).

Pull requests and merging

You can't push to the main branch. Therefore, for all changes you will need to create a new branch, and then a pull request to merge said branch into main. The framework owners will be nominated as reviewers of your PR by default, but feel free to add other people as well if you think they will have valuable input.

When committing your changes, please reference the issue they're resolving, so it will be closed automatically (e.g. Closes #123).

Contributing guidelines and etiquette

  • Preview your Markdown code to make sure the format is not broken.
  • Check grammar, spelling and punctuation, no one wants to look pedantic by requesting changes due to typos or inconsistent grammar/syntax, but it's only fair to keep this tidy.
  • The framework is open to the world. This has a few implications:
    • Nothing in it should be confidential, private to NHSD or include any personal data.
    • All links in framework pages should be public.
  • Use inclusive language: avoid terms which cause hurt and offence, including if they have historically been considered industry-standard terms.