Skip to content

Latest commit

 

History

History
41 lines (31 loc) · 2.61 KB

CONTRIBUTING.md

File metadata and controls

41 lines (31 loc) · 2.61 KB
Raw

Contributing

Contributing to QPixel follows broadly the same process as any other Codidact project.

What needs doing?

  • We have a roadmap which lists tasks that we deem to be relatively urgent. This roadmap has different phases and each links to issues that should be worked on during a phase.
  • Most bugs and change requests are here on GitHub. Have a look at all open issues (additionally to the roadmap) to find something that needs doing.
  • Additional information may be found in the feature request and bug tags of Codidact.Meta

Once you've picked what you're going to work on, please leave a comment on the issue to indicate you're planning to work on it; this helps us reduce wasted effort. If there's not already an issue for the feature you want to work on, please create one. If you need time to work on an issue, that's absolutely fine, but please keep us updated with comments on the issue - if we don't hear from you for a few weeks, we may assume you've given up working on that issue and give it to someone else.

What's the workflow?

  • First, you need an issue to work under. Either pick an existing issue or create a new one, and leave a comment on it to indicate that you're working on it.
  • Second, you can make your changes. If you have write access to the repository, create a topic branch (please use the format art/40/add-bells-and-whistles, i.e. username/issue-number/brief-description) and make your changes there; if not, fork the repository and work in your fork.
  • Once you've made your changes, submit a pull request targeting the develop branch.

Keep in mind that status checks are required to pass and at least one approving review is required from the team before any pull request can be merged. If status checks don't pass, we won't be able to merge - there are no exceptions, so please fix the failures and commit again. You can always mark your pull request as a draft while you're still trying to make it work.

What standards are there?

We have a code style and standards document with information for each applicable language. Please make sure you follow these if possible; if there's a good reason why not, please document it in your code, add a linter exception, and let us know why in your pull request.

Be nice; be respectful when contributing

Always be constructive, especially when giving feedback. Always presume that others are acting with good intent.