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.
- Over-commented code, a code should be explicit and readable by itself.
- You should not use magic strings.
- Skip Dead Code, Lava flow, Duplicate Code and Spaghetti Code.
- Avoid overly complex code (over engineering) for future developments that may never happen - Poltergeist.
- 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
- Be benevolent!
- 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
- Keep a humble attitude (“I think you should…” rather than “what the fuck is this?” Even if you mean it very strongly).
- Not everyone has the same level of understanding on your team (some have an appetite for the backend, others the frontend, etc.). It is up to you to share your knowledge in order to move forward together.
- 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.
- If you are having difficulty communicating with one or more members of your team, do not hesitate to let your manager know. The idea is to act as early as possible to avoid unnecessary conflicts.
- 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. Put yourself from the user's point of view by asking yourself what may be the best solution for them!
- You’re not alone in the dark, your teams are present for support!