Rules & Conventions
You're contributor, here are the guidelines we would must follow:
- We've very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history. But also, we use the git commit messages to generate change log. We use Conventional Commits guideline. It's better to create branches and commit messages in English and make them understandable
- I.N.V.E.S.T.(Independent, Negotiable, Valuable, Estimatable, Small, Testable) ! Each Stories are a widely accepted set of criteria, or checklist, to assess the quality. If stories fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite.
- DRY ! It's better whenever possible, re-using as much code as possible rather than duplicating similar code in multiple places. This reduces errors, keeps your code clean and enforces the principle of writing code once and then reusing it. It is also easier and more efficient to update code in one place than to update multiple parts of the same code. Thus making your code more modular and robust.
- Yours PRs doesn’t follow up for more than two days, our team should still leave a comment or reviews
- We can refactor, when we've develop User Stories or Engineer Stories
- Name a function meaningfully, to specify the requirements of its argument, and clearly state the relationship between the arguments and the result
- When in doubt, keep your PRs small. To give a PR the best chance of getting accepted, don't bundle more than one feature or bug fix per pull request. It's always best to create two smaller PRs than one big one
- When adding new features or modifying existing, attempt to include tests to confirm the new behaviour - atomic commit.
- We recommend running lints and tests in local to make sure you don’t introduce any regressions as you work on your change - even if they are executed in the Gitlab CI pipeline - atomic commit.
- The team must produce User Stories that represent the user needs to be implemented using Ubiquitous Language
- You must follow the coding style of the existing files and our conventional programming. We uses eslint and prettier
- We are using Jira and GitLab Issues for our bugs. We keep a close eye on this and try to make it clear when we have an internal fix in progress. Before filing a new task, try to make sure your problem doesn’t already exist.
- We follow the Contributor Covenant, welcoming all people to contribute, and pledging in return to value them as whole human beings and to foster an atmosphere of kindness, cooperation, and understanding
- Share & curiosity are the keys to your successes and our business. It's important to be curious !
- Being part of a community that is realistic, helpful, loving, realistic, encouraging and curious
- We an agile development team and the working agreement is about creating a team culture; a mutual commitment and reason for individuals to work together to reach a common goal, for a common purpose
- A perfect product doesn't exist otherwise we should ask ourselves questions ! And we aren't perfect !
- It's important to challenge the POs - as well as the other people around you
- You’re not alone in the dark, your teams are present for support !