- Fork the repository on GitHub
- Create a topic branch from where you want to base your work.
- This is usually the master branch.
- Only target release branches if you are certain your fix must be on that branch.
- To quickly create a topic branch based on master;
git checkout -b fix/tickectId_my_contribution master
.
- Make commits of logical units.
- Check for unnecessary whitespace with
git diff --check
before committing. - Configure your IDE using our codestyle conventions.
- Make sure your commit messages are in the proper format.
- Make sure you have added the necessary tests for your changes.
- Run all the tests to assure nothing else was accidentally broken.
- Sign the Contributor License Agreement.
- Push your changes to a topic branch in your fork of the repository.
- Submit a pull request to the repository in the Bonitasoft organization.
- The dev team looks at Pull Requests on a regular basis.
Labels
are used to track the lifecycle of the pull request:- Review needed
- Rebase needed
- Review done
- TR (Technical requirement)
- WIP (Work in progress)
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Only the footer is optional.
All the lines of the commit message cannot be longer than 100 characters, 60 for the first line! This allows the message to be easier to read on GitHub as well as in various git tools.
Must be one of the following:
- feat: A new feature
- fix: A bug fix
- defect: A fix done on a non-released feature
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing tests or correcting existing tests
- chore: Changes that affect the build system, CI configuration or external dependencies
- revert: If the commit reverts a previous commit, it should begin with
revert:
, followed by the header of the reverted commit. In the body it should say:This reverts commit <hash>.
, where the hash is the SHA of the commit being reverted.
The scope is the functional element impacted by the commit. For example ProcessDiagram
, Assets
, etc.
The subject contains succinct description of the change:
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize first letter
- no dot (.) at the end
Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
The footer should contain any information about Breaking Changes and is also the place to reference GitHub/JIRA issues that this commit closes.
Breaking Changes should start with the word BREAKING CHANGE:
with a space or two newlines. The rest of the commit message is then used for this.
fix(tasklist): display dates with proper locale setting
Set moment.js local globally in an angular run block instead of in each filters using moment.
Closes [BBPMC-418](https://bonita.atlassian.net/browse/BBPMC-418)
feat(tasklist): add details panel size handlers
Do some awesome things like:
* Cool thing done
* Another cool thing
Closes [BS-14965](https://bonitasoft.atlassian.net/browse/BS-14965)
At the time of writting, github does not bring any facility to express reader feeling in PR review comment. It might be useful to use the following convention to ease communication in PR reviews (you can find a list of available emoji in this emoji-cheat-sheet).
- ℹ️ (
:information_source:
) for an optional feedback, an information to be added by the reviewer - ❓ (
:question:
) for a question ⚠️ (:warning:
) for an attention point, might be changed- ❌ (
:x:
) for something wrong, must be changed