Skip to content
This repository has been archived by the owner on Dec 16, 2022. It is now read-only.

Latest commit

 

History

History
93 lines (75 loc) · 4.56 KB

CONTRIBUTING.md

File metadata and controls

93 lines (75 loc) · 4.56 KB
Raw

Contributing

Welcome to the Shout community, it's great to have you here! We thank you in advance for your contributions.

I have a question

Find us on the #shout-irc channel. You might not get an answer right away, but this channel is filled with nice people who will be happy to help you.

I want to report a bug

First of all, look at the open issues and closed issues to see if this was not alredy discussed before.

I want to contribute to the code

A good starting point if you want to help us but do not have a clear idea of what you can do specifically is to look at the open issues labeled as quick and easy or help wanted.

When you submit some code, make sure it respects the overall coding style that is currently in place. If you do not, our reviewers will surely let you know you should 😄 (that is, until an automated checker takes over the yelling).

Also, make sure that your PRs do not contain unnecessary commits. If you think some of your commits should be merged into a single one, feel free to squash them.

Please rebase outdated PRs on master to help with the reviews (rebasing is preferred over merging to keep a clean history in a branch/PR).

Additionally, give extra care to your commit messages, as they will help us review your PRs as well as help other contributors in the future, when exploring the history. The general rules are to use the imperative present tense, to start with a single concise line, followed by a blank line and a more detailed explanation when necessary. Tim Pope wrote an excellent article on how one should format their commit messages.

When you send a PR, expect two different reviews from the project maintainers. If necessary, they will make comments and ask for changes. When everything looks good to them, they will both express their consent by commenting your PR with a :+1:. Typically, the first reviewer will give a thorough report and exchange with you, give his :+1:, then ask the second reviewer to confirm the changes. When this happens (when you get your second required :+1:), then your PR can be merged.

Please document any relevant changes in the shout documentation that can be found in its own repository.

Labels

When you open an issue or send us a PR, it will most likely be given one or several labels. Here is what they mean:

  • bug: Issues that report and PRs that solve any defects that cause unexpected behaviors.
  • documentation: Tickets that mention a lack of documentation, suggest their improvement, or PRs that address these.
  • duplicate: Tickets already solved in the past or already open. Such tickets should always link to the previous one on the subject.
  • enhancement: Tickets that describe a desired feature or PRs that add them to the project.
  • help wanted: Tickets that we would like the community to help us with, by either answering questions or send us PRs.
  • priority: Tickets that the core team deemed critical and PRs that the core team should look at before others.
  • question: Tickets that are actually support cases.
  • quick and easy: Tickets that should be fairly simple to implement, even for developers not yet involved in the project.
  • second review needed: A first reviewer gave his 👍 but now expects a second reviewer to step in before this PR can be merged.
  • security: Tickets that describe a security concern or PRs that must be reviewed with extra care regarding security.
  • wontfix: Tickets that, after discussion and explanation, will not be fixed or implemented.

### Project maintainers