|
| 1 | +# Contributing to K-MUG website |
| 2 | + |
| 3 | +Looking to contribute something to K-MUG website? **Here's how you can help.** |
| 4 | + |
| 5 | +Please take a moment to review this document in order to make the contribution |
| 6 | +process easy and effective for everyone involved. |
| 7 | + |
| 8 | +Following these guidelines helps to communicate that you respect the time of |
| 9 | +the developers managing and developing this open source project. In return, |
| 10 | +they should reciprocate that respect in addressing your issue or assessing |
| 11 | +patches and features. |
| 12 | + |
| 13 | + |
| 14 | +## Using the issue tracker |
| 15 | + |
| 16 | +The [issue tracker](https://github.com/k-mug/k-mug.github.io/issues) is |
| 17 | +the preferred channel for [bug reports](#bug-reports), [features requests](#feature-requests) |
| 18 | +and [submitting pull requests](#pull-requests), but please respect the following |
| 19 | +restrictions: |
| 20 | + |
| 21 | +* Please **do not** use the issue tracker for personal support requests. Use K-MUG slack |
| 22 | + ([`#dev`](https://k-mug.slack.com/messages/dev/) channel) |
| 23 | + is a better place to get help. |
| 24 | + |
| 25 | +* Please **do not** derail or troll issues. Keep the discussion on topic and |
| 26 | + respect the opinions of others. |
| 27 | + |
| 28 | +* Please **do not** open issues or pull requests which *belongs to* the third party |
| 29 | + components. We believe you can approach their respective projects. |
| 30 | + |
| 31 | + |
| 32 | +## Bug reports |
| 33 | + |
| 34 | +A bug is a _demonstrable problem_ that is caused by the code in the repository. |
| 35 | +Good bug reports are extremely helpful, so thanks! |
| 36 | + |
| 37 | +Guidelines for bug reports: |
| 38 | + |
| 39 | +1.**Use the GitHub issue search**— check if the issue has already been |
| 40 | + reported. |
| 41 | + |
| 42 | +2.**Check if the issue has been fixed**— try to reproduce it using the |
| 43 | + latest `master` or development branch in the repository. |
| 44 | + |
| 45 | +3.**Isolate the problem**— ideally create an |
| 46 | +[SSCCE](http://www.sscce.org/) and a live example. |
| 47 | + Uploading the project on cloud storage (OneDrive, DropBox, et el.) |
| 48 | + or creating a sample GitHub repository is also helpful. |
| 49 | + |
| 50 | + |
| 51 | +A good bug report shouldn't leave others needing to chase you up for more |
| 52 | +information. Please try to be as detailed as possible in your report. What is |
| 53 | +your environment? What steps will reproduce the issue? What browser(s) and OS |
| 54 | +experience the problem? Do other browsers show the bug differently? What |
| 55 | +would you expect to be the outcome? All these details will help people to fix |
| 56 | +any potential bugs. |
| 57 | + |
| 58 | +Example: |
| 59 | + |
| 60 | +> Short and descriptive example bug report title |
| 61 | +> |
| 62 | +> A summary of the issue and browser, OS environments in which it occurs. If suitable, include the steps |
| 63 | +> required to reproduce the bug. |
| 64 | +> |
| 65 | +> 1. This is the first step |
| 66 | +> 2. This is the second step |
| 67 | +> 3. Further steps, etc. |
| 68 | +> |
| 69 | +> `<url>` - a link to the project/file uploaded on cloud storage or other publicly accessible medium. |
| 70 | +> |
| 71 | +> Any other information you want to share that is relevant to the issue being |
| 72 | +> reported. This might include the lines of code that you have identified as |
| 73 | +> causing the bug, and potential solutions (and your opinions on their |
| 74 | +> merits). |
| 75 | +
|
| 76 | + |
| 77 | +## Feature requests |
| 78 | + |
| 79 | +Feature requests are welcome. But take a moment to find out whether your idea |
| 80 | +fits with the scope and aims of the project. It's up to *you* to make a strong |
| 81 | +case to convince the project's developers of the merits of this feature. Please |
| 82 | +provide as much detail and context as possible. |
| 83 | + |
| 84 | + |
| 85 | +## Pull requests |
| 86 | + |
| 87 | +Good pull requests�patches, improvements, new features�are a fantastic |
| 88 | +help. They should remain focused in scope and avoid containing unrelated |
| 89 | +commits. |
| 90 | + |
| 91 | +**Please ask first** before embarking on any significant pull request (e.g. |
| 92 | +implementing features, refactoring code, porting to a different language), |
| 93 | +otherwise you risk spending a lot of time working on something that the |
| 94 | +project's developers might not want to merge into the project. |
| 95 | + |
| 96 | +Please adhere to the [coding guidelines](#code-guidelines) used throughout the |
| 97 | +project (indentation, accurate comments, etc.) and any other requirements |
| 98 | +(such as test coverage). |
| 99 | + |
| 100 | +Adhering to the following process is the best way to get your work |
| 101 | +included in the project: |
| 102 | + |
| 103 | +1.[Fork](http://help.github.com/fork-a-repo/) the project, clone your fork, |
| 104 | + and configure the remotes: |
| 105 | + |
| 106 | +```bash |
| 107 | +# Clone your fork of the repo into the current directory |
| 108 | + git clone https://github.com/<your-username>/k-mug.github.io.git |
| 109 | +# Navigate to the newly cloned directory |
| 110 | +cd k-mug.github.io |
| 111 | +# Assign the original repo to a remote called "kmug" (or "upstream") |
| 112 | + git remote add kmug https://github.com/k-mug/k-mug.github.io.git |
| 113 | +``` |
| 114 | + |
| 115 | +2. If you cloned a while ago, get the latest changes from upstream: |
| 116 | + |
| 117 | +```bash |
| 118 | + git checkout master |
| 119 | + git pull kmug master |
| 120 | +``` |
| 121 | + |
| 122 | +3. Create a new topic branch (off the main project development branch) to |
| 123 | + contain your feature, change, or fix: |
| 124 | + |
| 125 | +```bash |
| 126 | + git checkout -b <topic-branch-name> |
| 127 | +``` |
| 128 | + |
| 129 | +4. Commit your changes in logical chunks. Please adhere to these [git commit |
| 130 | + message guidelines](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) |
| 131 | + or your code is unlikely be merged into the main project. Use Git's |
| 132 | +[interactive rebase](https://help.github.com/articles/interactive-rebase) |
| 133 | + feature to tidy up your commits before making them public. Also, prepend name of the feature |
| 134 | + to the commit message. For instance: "SCSS: Fixes compiler results for IFileListener.\nFixes `#123`" |
| 135 | + |
| 136 | +5. Locally merge (or rebase) the upstream development branch into your topic branch: |
| 137 | + |
| 138 | +```bash |
| 139 | + git pull [--rebase] kmug master |
| 140 | +``` |
| 141 | + |
| 142 | +6. Push your topic branch up to your fork: |
| 143 | + |
| 144 | +```bash |
| 145 | + git push origin <topic-branch-name> |
| 146 | +``` |
| 147 | + |
| 148 | +7.[Open a Pull Request](https://help.github.com/articles/using-pull-requests/) |
| 149 | + with a clear title and description against the `master` branch. |
| 150 | + |
| 151 | + |
| 152 | +## Code guidelines |
| 153 | + |
| 154 | +- Always use proper indentation. |
| 155 | +- <MoretocomeasandwhenIhitonsomehottopic> |
0 commit comments