|
| 1 | +# CONTRIBUTION GUIDELINES |
| 2 | + |
| 3 | +Welcome to DevCANS [Website repository](https://github.com/DevCANS/website/)! :smile: |
| 4 | + |
| 5 | +Before submitting pull requests, please make sure that you have **read all the guidelines**. If you have any doubts about this contribution guide, please open an issue and clearly state your concerns. |
| 6 | + |
| 7 | +## Contribute a new resource |
| 8 | + |
| 9 | +- First, have a look at open issues. They contain the list of resources we plan to add. Pick an unassigned issue. |
| 10 | +- You can also create a new issue for addition of new resource that is not in the list. |
| 11 | +- **Just make sure that you are assigned for the issue before starting** |
| 12 | +- Add the resource. |
| 13 | +- Send a PR. |
| 14 | +- While sending a PR make sure you follow one issue per PR rule. |
| 15 | + |
| 16 | +## Commit Guidelines |
| 17 | + |
| 18 | +- It is recommended to keep your changes grouped logically within individual commits. Maintainers find it easier to understand changes that are logically spilt across multiple commits. |
| 19 | + |
| 20 | + ```git |
| 21 | + git add file-name.md |
| 22 | +
|
| 23 | + git commit -m "Commit Message(Title)" -m "Commit Body(Describe changes in brief)" |
| 24 | + ``` |
| 25 | + |
| 26 | +### Commit Message |
| 27 | + |
| 28 | +Examples of commit messages with semantic prefixes: |
| 29 | + |
| 30 | + ```commit message |
| 31 | + [ADD] <file-name> |
| 32 | + [FIX] <file-name> |
| 33 | + [MODIFY] <file-name> |
| 34 | + [UPDATE] <file-name> |
| 35 | + [REFACTOR] <file-name> |
| 36 | +
|
| 37 | + [ADD] RESOURCES.md |
| 38 | + ``` |
| 39 | + |
| 40 | +Common prefixes and their usecases: |
| 41 | + |
| 42 | +- ADD: Add a new file |
| 43 | +- FIX: A bug fix in file |
| 44 | +- MODIFY: Change existing stuff/resource in the file |
| 45 | +- UPDATE: Add new stuff/resource to the file |
| 46 | +- REFACTOR: Restructure a file without changing external working |
| 47 | + |
| 48 | +### Commit Body |
| 49 | + |
| 50 | +Example: |
| 51 | + |
| 52 | +```Commit Body |
| 53 | +This adds charts.js which is used to render charts |
| 54 | +``` |
| 55 | + |
| 56 | +- **Maximum of 72 characters.** |
| 57 | + The recommendation is to add a line break at 72 characters, so that Git has |
| 58 | + plenty of room to indent text while still keeping everything under 80 |
| 59 | + characters overall. |
| 60 | +- Not mandatory - but helps explain what you’re doing. |
| 61 | +- First person should not be used here. |
| 62 | +- Keeping subject lines at this length ensures that they are readable, and explains the change in a concise way. |
| 63 | +- Should describe the change. |
| 64 | +- Should not include WIP prefix. |
| 65 | + |
| 66 | +## Pull Request Guidelines |
| 67 | + |
| 68 | +- Make sure your pull request is specific and focused. Instead of contributing "several resources" all at once contribute them all one by one separately (i.e. each pull request should comprise a resource along with its description). |
| 69 | +- A pull request message consists of 3 parts: |
| 70 | + - Title |
| 71 | + - Short Desciption |
| 72 | + - Issue reference |
| 73 | + |
| 74 | +### Title |
| 75 | + |
| 76 | +- For a single commit, the title is the subject line of the commit message. |
| 77 | +- Otherwise, the title should summarise the set of commits. |
| 78 | +- Mention the file or section in file being modified. |
| 79 | +- Not mandatory. |
| 80 | +- Common prefixes and their usecases: |
| 81 | + - ADD: Add a new file |
| 82 | + - FIX: A bug fix in file |
| 83 | + - MODIFY: Change existing stuff/resource in the file |
| 84 | + - UPDATE: Add new stuff/resource to the file |
| 85 | + - REFACTOR: Restructure a file without changing external working |
| 86 | + |
| 87 | +### Short Description |
| 88 | + |
| 89 | +- Must state the why and the how for the change. |
| 90 | +- Usually this is the body of your commit message. |
| 91 | +- Starts with a capital letter. |
| 92 | +- Written in imperative present tense (i.e. `Add something`, `not Adding something` or `Added something`). |
| 93 | +- Should describe all the changes in brief. |
| 94 | + |
| 95 | +### Issue reference |
| 96 | + |
| 97 | +Example: |
| 98 | + |
| 99 | +```markdown |
| 100 | +Closes https://github.com/DevCANS/website/issues/7 |
| 101 | +``` |
| 102 | + |
| 103 | +- Should use the `Fixes` keyword if your commit fixes a bug, or `Closes` if it |
| 104 | +adds a feature/enhancement. |
| 105 | +- In some situations, e.g. bugs overcome in documents, the difference between |
| 106 | +`Fixes` and `Closes` may be very small and subjective. If a specific issue may |
| 107 | +lead to an unintended behaviour from the user or from the program it should be |
| 108 | +considered a bug, and should be addresed with `Fixes`. If an issue is labelled |
| 109 | +with `bug` you should always use `Fixes`. For all other issues use `Closes`. |
| 110 | +- Should use full URL to the issue. |
| 111 | +- There should be a single space between the `Fixes` or `Closes` and the URL. |
| 112 | + |
| 113 | +> **Note:** |
| 114 | +> |
| 115 | +> - The issue reference will automatically add the link of the commit in the issue. |
| 116 | +> - It will also automatically close the issue when the commit is accepted into repository. |
| 117 | +
|
| 118 | +## New File Name guidelines |
| 119 | + |
| 120 | +- Filename should describe the content of the file. (e.g. : `db-config.php` which contains config. data for database) |
| 121 | +- Use lowercase words with ``"-"`` as separator |
| 122 | +- For instance |
| 123 | + |
| 124 | +```File Name |
| 125 | +compiler-installation-guidelines.MD is incorrect |
| 126 | +CompilerInstallationGuidelines.md is incorrect |
| 127 | +compilerInstallationGuidelines.md is incorrect |
| 128 | +compiler_installation_guidelines.md is incorrect |
| 129 | +compiler-installation-guidelines.md is correct |
| 130 | +``` |
| 131 | + |
| 132 | +## New Directory guidelines |
| 133 | + |
| 134 | +- Folder name should be in full lowercase. If the name has multiple words, separate them by dashes(-). (e.g. : `getting-started`) |
| 135 | +- We recommend adding files to existing directories as much as possible (Take a look at **[folder structure](FOLDER-STRUCTURE.md)**). |
| 136 | +- New folder should contain `README.md` with proper description of the folder. |
| 137 | +- Use lowercase words with ```"-"``` as separator (spaces or ```"_"``` not allowed) |
| 138 | +- For instance |
| 139 | + |
| 140 | +```Directory Name |
| 141 | +SomeNewCategory is incorrect |
| 142 | +someNewCategory is incorrect |
| 143 | +some_new_category is incorrect |
| 144 | +some-new-category is correct |
| 145 | +``` |
| 146 | + |
| 147 | +## Documentation |
| 148 | + |
| 149 | +- Make sure you describe the resource and how it can be used if not self explanatory. |
| 150 | +- If you have modified/added documentation, please ensure that your language is concise and contains no grammar errors. |
| 151 | +- Do not update `README.md` along with other changes, first create an issue and then link to that issue in your pull request to suggest specific changes required to `README.md` |
0 commit comments