2.2 KB

Contribution Guide

First of all, thank for your contribution! I can't manage this whole thing alone, and I welcome pull requests. To make sure that we're all on the same page, here are some guidelines to follow for submitting pull requests for this list.

What would be great

Obviously, it's your choice what you want to contribute - or not contribute. However, if you're looking for something that would help awesome-c, check the current issues, especially those tagged with 'help wanted'. Pull requests addressing these are particularly great!

How to contribute

Now for the mechanics of the process, and some do's and don't's.

Ensure that everything you link to is free (as in freedom)

This is highly important - this list only contains freedom-respecting things! If you are sending a pull request linking to code, ensure it is licensed under a freedom-respecting license. This includes, but is not limited to:

If you're not sure, better to ask first. If it's not on the list above especially.

Indicate the license for anything you add clearly

Ensure that you label licenses correctly. awesome-c now uses SPDX license labels, so please use those. If the license is weird or not on the list, label it as clearly as possible. Also check if the license is in use already - if it is, don't create another link to it.

Sometimes, libraries or frameworks will contain documentation or code under different licenses to the library itself (such as tests or examples). There is no need to indicate their licenses in that case. However, if the program itself is what is being put on the list, obviously its license matters.

Maintain alphabetical order within sections

Pretty self-explanatory, really. Numbers are considered to be higher-ordered than anything else, and otherwise, lex order.

Give a clear commit message

The commit message should state clearly what you did (adding, removing, clarifying, etc.), with what (usually by giving the name of the entry), in the present continuous tense (i.e. 'adding' not 'added').