|
| 1 | +# Contributing to Devo |
| 2 | + |
| 3 | +There are many ways to contribute to Devo. Here are some of them: |
| 4 | + |
| 5 | + |
| 6 | +1. [Report bugs](#reporting-bugs) or request features in the [issue tracker](issues). |
| 7 | +2. [Submit patches](#submit-patch) for bug fixes and/or new features. |
| 8 | + |
| 9 | +## Reporting bugs |
| 10 | + |
| 11 | +``` |
| 12 | +Please report security issues only to [email protected]. |
| 13 | +This is a private email only open to Devo developers. |
| 14 | +``` |
| 15 | + |
| 16 | +Well-written bug reports are very helpful, keep in mind this guideline when |
| 17 | +reporting a new bug. |
| 18 | + |
| 19 | +* Check the open issues to see if it has already been reported. |
| 20 | +* Write complete, reproducible, specific bug reports: the smaller the test case, |
| 21 | + better. |
| 22 | +* Includes the output of the library with all the error information |
| 23 | + |
| 24 | + |
| 25 | +## Submit patch |
| 26 | +To be able to make a fork and the corresponding MR you have to accept Devo's CLA |
| 27 | +The process to modify one package or script is the next: |
| 28 | + |
| 29 | +1. Create your fork from release-next |
| 30 | +2. Add to the `CHANGELOG.md`, in |
| 31 | +[`Unreleased`](#How_can_I_minimize_the_effort_required?) the tasks |
| 32 | +that you are going to take or are carrying out to be able to review at a quick |
| 33 | +glance the objective of the branch. |
| 34 | +3. Make your awesome code |
| 35 | +4. Never forget to **change the changelog**. |
| 36 | +4.1 [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) |
| 37 | +5. Create a Pull Request to release-next. |
| 38 | + |
| 39 | + |
| 40 | +## Keep a CHANGELOG |
| 41 | +##### What’s a change log? |
| 42 | +A change log is a file which contains a curated, chronologically ordered list of |
| 43 | +notable changes for each version of a project. |
| 44 | + |
| 45 | +##### What’s the point of a change log? |
| 46 | +To make it easier for users and contributors to see precisely what notable |
| 47 | +changes have been made between each release (or version) of the project. |
| 48 | + |
| 49 | +##### Why should I care? |
| 50 | +Because software tools are for people. If you don’t care, why are you |
| 51 | +contributing? Right, Logtrust pay you for it, but surely, there must be a kernel |
| 52 | + (ha!) of care somewhere in that lovely little brain of yours. |
| 53 | + |
| 54 | +##### What makes a good change log? |
| 55 | +A good change log sticks to these principles: |
| 56 | + |
| 57 | +* It’s made for humans, not machines, so legibility is crucial. |
| 58 | +* Easy to link to any section (hence Markdown over plain text). |
| 59 | +* One sub-section per version. |
| 60 | +* List releases in reverse-chronological order (newest on top). |
| 61 | +* Write all dates in `YYYY-MM-DD` format. (Example: `2012-06-02` |
| 62 | +for `June 2nd, 2012`.) It’s international, sensible, and language-independent. |
| 63 | +* Explicitly mention whether the project follows Semantic Versioning. |
| 64 | +* Each version should: |
| 65 | + * List its release date in the above format. |
| 66 | + * Group changes to describe their impact on the project, as follows: |
| 67 | + * `Added` for new features. |
| 68 | + * `Changed` for changes in existing functionality. |
| 69 | + * `Deprecated` for once-stable features removed in upcoming releases. |
| 70 | + * `Removed` for deprecated features removed in this release. |
| 71 | + * `Fixed` for any bug fixes. |
| 72 | + * `Security` to invite users to upgrade in case of vulnerabilities. |
| 73 | + |
| 74 | +##### How can I minimize the effort required? |
| 75 | + |
| 76 | +Always have an `Unreleased` section at the top for keeping track of any changes. |
| 77 | + |
| 78 | +This serves two purposes: |
| 79 | +* People can see what changes they might expect in upcoming releases |
| 80 | +* At release time, you just have to change "Unreleased" to the version number and add a new "Unreleased" header at the top. |
| 81 | + |
| 82 | +**Feel free for update and improve this document content or format.**<br/> |
0 commit comments