Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
78 lines (47 loc) · 5.79 KB

CONTRIBUTING.md

File metadata and controls

78 lines (47 loc) · 5.79 KB
Raw

Welcome

Welcome to the VATSIM UK Core repository. VATSIM UK has a dedicated team who are members of the VATSIM UK staff team who are ultimately responsible for the upkeep and development of VATSIM UK systems. The team maintains a backlog of work outside of this repository, but issues of which open-source contributions are welcomed will be added under 'Issues' in this repository.

If you don't see any interesting issues open but still want to contribute, please reach out.

Some issues simply can't be delegated to outside contributors as they may require elevated access.

Contributor license agreement

By submitting code as an individual you agree that VATSIM UK can use your amendments, fixes, patches, changes, modifications, submissions and creations in the production of the UK Core and that the ownership of your submissions transfers to VATSIM UK in their entirety. More info on the licensing can be found in LICENSE

Contributing to the codebase

If you're just getting started with GitHub (and project contributions) then we suggest you take a look at issues marked with both the "up-for-grabs" and/or "good-first-issue" labels. These issues will be of reasonable size and challenge while not being as overly complex as others and a good introduction for anyone who wants to start contributing to the project.

If you're comfortable with contributing to Open Source projects on GitHub please ensure you read our expectations for issue tracking, feature proposals and merge requests.

Running Core locally

To run core locally, please read our setup guide

Issue Tracking

If you require support with the Core Project, please read the support page. When submitting an issue, there are a few guidelines we'd ask you to respect to make it easier to manage (and for others to understand):

  • Search the issue tracker before you submit your issue - it may already be present.
  • When opening an issue, a template is provided for you. Please provide as much information as requested to ensure others are able to act upon the requests or bug report.
  • Please ensure you add screenshots or documentation references for bugs/changes so we can quickly ascertain if the request is suitable.

If you can't assign yourself to an issue please comment on the issue to let people know you're taking it on.

Pull Requests

We welcome pull requests with fixes and improvements to the Core project. The features we really would like public support on are marked with "up-for-grabs" or "good first issue" but other improvements are also welcome - please ensure you read over the pull workflow below.

If you wish to add a new feature or you spot a bug that you wish to fix, please open an issue for it first on the UK Core issue tracker.

The workflow for submitting a new pull request is designed to be simple, but also to ensure consistency from all contributors:

  • Fork the project into your personal space on GitHub.com.
  • Create a new branch (with the name issue-[issue_number], replacing [issue_number] with the issue number you're resolving), e.g. issue-1234.
  • Commit your changes.
  • When writing commit messages, consider closing your issues via the commit message (by including "fix #22" or "fixes #22", for example).
  • The issues will be referenced in the first instance and then closed once the MR is accepted.
  • Push the commit(s) to your fork.
  • Submit a pull request (PR) to the main branch.
  • The PR title should describe the change that has been made.
  • The PR description should confirm what changes have been made and how you know they're correct (with references).
  • Please include any relevant screenshots to prove the changes work
  • Ensure you link any relevant issues in the merge request (you can type hash and the issue ID, e.g. #275). Comment on those issues linking back to the PR (you can reference PRs in the same way as issues, using the format #pr-id).
  • Be prepared to answer any questions about your PR when it is reviewed for acceptance.

Please keep your changes in a single PR as small as possible (relating to one issue) as this makes it easier to review and accept. Large PRs with a small error will prevent the entire PR from being accepted.

Marking PR dependencies

If your PR depends on another open PR being merged first, include a line in your PR description such as Depends on #123 or Blocked by #123. A "Check Dependencies" status check will flag the PR until the dependency is resolved.

Automatic PR labeling

An automated workflow classifies internal pull requests and applies labels to help reviewers:

  • type:* - the primary intent of the PR (feature, fix, chore, docs, refactor, test)
  • needs-* - potential gaps flagged for reviewer attention (tests, copy, docs, migration)

Labels update on each push. They are advisory only and do not block merging. If a label is incorrect, you can remove it manually - the workflow will not re-apply it unless the diff changes.

Expectations

As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting merge requests or patches, and other activities.

We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or favourite aircraft.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, issues and other contributions that are not aligned to this Code of Conduct.

This Code of Conduct applies both within this project space and public spaces when an individual is representing the project or its community.