Browse Source

Improve commit message example in CONTRIBUTING.md (#10357)

tags/8.3.0.alpha1
Aleksi Hietanen 6 years ago
parent
commit
7db9fd3666
1 changed files with 13 additions and 3 deletions
  1. 13
    3
      CONTRIBUTING.md

+ 13
- 3
CONTRIBUTING.md View File



# Example of a good commit message # Example of a good commit message


Create a Valo icon font for icons used in Valo (#18472)
Create a Valo icon font for icons used in Valo


Valo uses only a handful of icons from Font Awesome. This change introduces a separate icon font for valo (9KB instead of 80KB) and decouples Valo from Font Awesome to enable updating Font Awesome without taking Valo into account. Valo uses only a handful of icons from Font Awesome. This change introduces a separate icon font for valo (9KB instead of 80KB) and decouples Valo from Font Awesome to enable updating Font Awesome without taking Valo into account.




For backwards compatibility, Font Awesome is loaded by default For backwards compatibility, Font Awesome is loaded by default


Closes #123456

## Example breakdown ## Example breakdown


Start with a good Commit message in imperative form. Reference a ticket number if applicable:
Start with a good Commit message in imperative form.


Create a Valo icon font for icons used in Valo (#18472)
Create a Valo icon font for icons used in Valo


### Describe the problem: ### Describe the problem:




For backwards compatibility, Font Awesome is loaded by default For backwards compatibility, Font Awesome is loaded by default


### Reference an Issue:

If applicable, reference an open issue that your pull request resolves as described in [this article](https://help.github.com/articles/closing-issues-using-keywords/). In the example given above this corresponds to the line

Closes #123456

where `123456` is the hypothetical issue number.

# Include a test # Include a test


Ideally, we would like all patches to include automated tests. Unit tests are preferred. If there’s a change to UI Code, we would prefer a TestBench test. If that’s not possible (you as a contributor lack a TestBench license), we can make do with a Test UI class that contains a test case as well a clear instructions for how to perform the test. This also goes for features that are hard to test automatically. Ideally, we would like all patches to include automated tests. Unit tests are preferred. If there’s a change to UI Code, we would prefer a TestBench test. If that’s not possible (you as a contributor lack a TestBench license), we can make do with a Test UI class that contains a test case as well a clear instructions for how to perform the test. This also goes for features that are hard to test automatically.

Loading…
Cancel
Save