Mirrors/dolibarr
1
0
Fork 0
mirror of https://github.com/Dolibarr/dolibarr.git synced 2025-02-20 13:46:52 +01:00
Code Issues Packages Projects Releases Wiki Activity

Add QUAL and PERF as possible key for commit description

Browse Source
This commit is contained in:
Laurent Destailleur 2023-09-12 17:46:13 +02:00
parent b98921fc80
commit 1667a5a740
1 changed files with 6 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
.github/CONTRIBUTING.md vendored
View File

@ -67,9 +67,12 @@ where
In uppercase if you want to have the log comment appears into the generated ChangeLog file.
The keyword can be ommitted if your commit does not fit in any of the following categories:
- Fix/FIX: for a bug fix
- New/NEW: for an unreferenced new feature (Opening a feature request and using close is prefered)
- Close/CLOSE: for closing a referenced feature request
- Perf/PERF: for performance enhancement
- Qual/QUAL: for quality code enhancement or re-engeneering
#### Issuenum
If your commit fixes a referenced bug or feature request.
@ -96,10 +99,10 @@ Try to keep lines under 120 characters.
<pre>
FIX|Fix #456 Short description (where #456 is number of bug fix, if it exists. In upper case to appear into ChangeLog)
or
NEW|New Short description (In upper case to appear into ChangeLog, use this if you add a feature not tracked, otherwise use CLOSE #456)
or
CLOSE|Close #456 Short description (where #456 is number of feature request, if it exists. In upper case to appear into ChangeLog)
or
NEW|New|QUAL|Qual|PERF|Perf Short description (In upper case to appear into ChangeLog, use this if you add a feature not tracked, otherwise use CLOSE #456)
or
Short description (when the commit is not introducing feature nor closing a bug)
Long description (Can span accross multiple lines).
@ -119,7 +122,7 @@ Also, some code changes need a prior approbation:
* if you want to include a new external library (into htdocs/includes directory), please ask before to the core project manager (mention @dolibarr-jedi in your issue) to see if such a library can be accepted.
* if you add a new tables or fields, you MUST first submit a standalone PR with the data structure changes you plan to add/modify (and only data structure changes). Start development only once this data structure has been accepted.
* if you add new tables or fields, you MUST first submit a standalone PR with the data structure changes you plan to add/modify (and only data structure changes). Start development only once this data structure has been accepted.
Once a PR has been submitted, you may need to wait for its integration. It is common that the project leader let the PR open for a long delay to allow every developer discuss about the PR (A label is added in such a case).