Skip to content

Latest commit

 

History

History
54 lines (39 loc) · 2.98 KB

CONTRIBUTING.md

File metadata and controls

54 lines (39 loc) · 2.98 KB

Contributing to codetyper

When contributing to codetyper, make sure that the changes you wish to make are in line with the project direction. If you are not sure about this, come to the Discord channel so we can discuss it.

The general rule is that everyone is welcome to work on the project. :=)

Communication

The main communication channel is the Discord server: https://discord.gg/kalle

Issue policy

  • One issue per bug.
  • Issues should be discussed on Discord. Summaries can be added to the GitHub issue.
  • Irrelevant commentary will be removed. If you agree with something use emoji reactions. If you disagree, discuss the issue on Discord first.

Human language policy

  • The accepted languages are British English and American English.
  • Use proper spelling, grammar, and punctuation.
  • Write in an authoritative and technical tone.

Code submission policy

Nobody is perfect, and sometimes we mess things up. That said, here are some good dos & dont's to try and stick to:

Do:

  • Code formatting should be consistent with the rest of the project.
  • Choose expressive variable, function and class names. Make it as obvious as possible what the code is doing.
  • Split your changes into separate, atomic commits (i.e. A commit per feature or fix, where the build, tests and the system are all functioning).
  • The first line of the commit message is the subject line, and should have the format "Category: Brief description of what's being changed". The "category" can be a subdirectory, but also something like "POSIX compliance" or "ClassName". Whatever seems logical.
  • Write your commit messages in proper English, with care and punctuation.
  • Squash your commits when making revisions after a patch review.
  • Check the spelling of your code, comments and commit messages.

Don't:

  • Submit code that's incompatible with the project licence (GPL-3.0)
  • Touch anything outside the stated scope of the PR.
  • Iterate excessively on your design across multiple commits.
  • Use weasel-words like "refactor" or "fix" to avoid explaining what's being changed.
  • Include commented-out code.
  • Attempt large architectural changes until you are familiar with the system and have worked on it for a while.

Pull Request Q&A

If my PR isn't getting attention, how long should I wait before pinging one of the project reviewers?

Ping them right away if it's something urgent! If it's less urgent, advertise your PR on Discord and ask if someone could review it.

Who are the project reviewers?

The project reviewer at this time is @ChristofferHolmesland

Is Discord the place to ask for review help, or is Github preferred?

It's definitely better to ask on Discord. Due to the volume of GitHub notifications, many of us turn them off and rely on Discord for learning about review requests.

CONTRIBUTING.md file

This file is heavily inspired by the SerenityOS CONTRIBUTING.md file, which can be found here: https://github.com/SerenityOS/serenity/blob/master/CONTRIBUTING.md.