Adds a badge showing the number of people helping this repo on CodeTriage. [![Open Source Helpers](https://www.codetriage.com/awesomewm/awesome/badges/users.svg)](https://www.codetriage.com/awesomewm/awesome) ## What is CodeTriage? CodeTriage is an Open Source app that is designed to make contributing to Open Source projects easier. It works by sending subscribers a few open issues in their inbox. If subscribers get busy, there is an algorithm that backs off issue load so they do not get overwhelmed [Read more about the CodeTriage project](https://www.codetriage.com/what). ## Why am I getting this PR? Your project was picked by the human, @schneems. They selected it from the projects submitted to https://www.codetriage.com and hand edited the PR. How did your project get added to [CodeTriage](https://www.codetriage.com/what)? Roughly over 1 year ago, [cameronjacobson](https://github.com/cameronjacobson) added this project to CodeTriage in order to start contributing. Since then, 8 people have subscribed to help this repo. ## What does adding a badge accomplish? Adding a badge invites people to help contribute to your project. It also lets developers know that others are invested in the longterm success and maintainability of the project. You can see an example of a CodeTriage badge on these popular OSS READMEs: - [![Email clients like GMAIL do not render SVG images](https://www.codetriage.com/rails/rails/badges/users.svg)](https://www.codetriage.com/rails/rails) https://github.com/rails/rails - [![Email clients like GMAIL do not render SVG images](https://www.codetriage.com/crystal-lang/crystal/badges/users.svg)](https://www.codetriage.com/crystal-lang/crystal) https://github.com/crystal-lang/crystal ## Have a question or comment? While I am a bot, this PR was manually reviewed and monitored by a human - @schneems. My job is writing commit messages and handling PR logistics. If you have any questions, you can reply back to this PR and they will be answered by @schneems. If you do not want a badge right now, no worries, close the PR, you will not hear from me again. Thanks for making your project Open Source! Any feedback is greatly appreciated.
3.9 KiB
Contributing
Bugs
Please look at Github Issues.
Triage Issues
You can triage issues which may include reproducing bug reports or asking for vital information, such as version numbers or reproduction instructions. If you would like to start triaging issues, one easy way to get started is to subscribe to AwesomeWM on CodeTriage.
Style
If you intend to patch and contribute to Awesome, please respect the following guidelines.
Imitate the existing code style. For concrete rules:
-
Use 4 spaces indentation, do not use tabulator characters;
-
Place braces alone on new lines, and do not place braces for single line statement where it is not needed, i.e.:
if(foo) x = 1; if(foo) { x = 1; bar(); }
-
Do not put a space after if, for, while or function call statements;
-
The preferred maximum line length is 80 characters;
-
Use
/* */
for comments; -
Use the API: there is a list of
a_*()
functions you should use instead of the standard libc ones. There is also a common API for linked lists, tabulars, etc.; -
Be clear in what you do;
-
Prefix your function names with the module they are enhancing, i.e. if you add a function to manipulate a tag, prefix it with
tag_
; -
Write documentation for any new functions, options, whatever.
A vim modeline is set in each file to respect this.
Documentation of Lua files
For documentation purposes LDoc---see here for its documentation---is used. Comments that shall be parsed by LDoc have the following format:
--- summary.
-- Description; this can extend over
-- several lines
-----------------
-- This will also do.
--[[--
Summary. A description
...;
]]
You can use the full power of Markdown with the extensions of Discount for markup in the comments.
Every module and class should have a short description at its beginning which
should include @author author
, @copyright year author
and
@module module-name
or @classmod class-name
.
Parameters of functions should be documented using
@tparam <type> <parmname> <description>
, and return values via
@treturn <type> <description>
.
For a more comprehensive description of the available tags see the LDoc documentation.
In addition to the regular tags provided by LDoc there are also some aliases
for typed parameters defined in docs/config.ld
, e.g. @client
for
@tparam client.object
, @tag
for @tparam tag
and @tab
for
@tparam table
).
Patches
If you plan to submit patches, you should follow the following guidelines.
Commits
- make commits of logical units;
- do not modify piece of code not related to your commit;
- do not try to fix style of code you are not writing, it's just adding noise for no gain;
- check for unnecessary whitespace with
git diff --check
before committing; - do not check in commented out code or unneeded files;
- provide a meaningful commit message;
- the first line of the commit message should be a short; description and should skip the full stop;
- if you want your work included, add a
Signed-off-by: Your Name <you@example.com>
line to the commit message (or just use the option-s
when committing); - make sure that you have tests for the bug you are fixing;
- if possible, add a unit test to the test suite under spec/.
Patches
Submitting patches via pull requests on the Github project is the preferred method.
Pull request
- create a pull request