mirror of
https://github.com/thelounge/thelounge
synced 2024-11-23 04:23:13 +00:00
92 lines
4.5 KiB
Markdown
92 lines
4.5 KiB
Markdown
## Contributing
|
||
|
||
Welcome to The Lounge, it's great to have you here! We thank you in advance for
|
||
your contributions.
|
||
|
||
### I have a question
|
||
|
||
Find us on #thelounge channel on Freenode. 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 and closed issues](https://github.com/thelounge/lounge/issues?q=is%3Aissue)
|
||
to see if this was not already 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*](https://github.com/thelounge/lounge/issues?q=is%3Aopen+is%3Aissue+label%3Abug+label%3A%22quick+and+easy%22)
|
||
or [*help
|
||
wanted*](https://github.com/thelounge/lounge/issues?q=is%3Aopen+is%3Aissue+label%3Abug+label%3A%22help+wanted%22).
|
||
|
||
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 :smile: (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](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History).
|
||
|
||
Please [rebase](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) 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](https://git-scm.com/book/ch5-2.html#Commit-Guidelines), 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](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
|
||
on how one should format their commit messages.
|
||
|
||
When you send a PR, expect two different reviews from the [project
|
||
maintainers](https://github.com/thelounge/lounge/blob/master/CONTRIBUTING.md#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 documentation that can be found
|
||
[in its own repository](https://github.com/thelounge/thelounge.github.io).
|
||
|
||
### Labels
|
||
|
||
When you open an [issue](https://github.com/thelounge/lounge/issues) or send us
|
||
a [PR](https://github.com/thelounge/lounge/pulls), 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 :+1: 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
|
||
|
||
- [Mattias Erming](https://github.com/erming) (`erming` on IRC)
|
||
- [Jocelyn Delalande](https://github.com/JocelynDelalande) (`JocelynD` on IRC)
|
||
- [Jérémie Astori](https://github.com/astorije) (`astorije` on IRC)
|
||
- [Paul Friederichsen](https://github.com/floogulinc) (`floogulinc` on IRC)
|