If we speak about something, we should all share a common understanding of the terms we use. If in doubt, we'll enlist the help of dictionaries and semantic studies for clear and effective communication.
We don't aim to discuss every little thing over and over again. Instead, we suggest, define and use conventions.
We also don't strive to define or make precise every single term we need for our daily work, but assume a shared common-sense understanding throughout. Only when we run into misunderstandings that affect our work, we may take time to spell out in detail what caused the misunderstanding and hampers our work.
In that context, we document everything that is relevant for other developers.
Given multiple conflicting opinions, we make decisions purely based on democratic principles, i.e. the opinion that gets approved by the majority wins. We write down such decisions, so that we won't lose time over the same topic in the future. Once a decision is approved, personal opinions are ignored.
We make sure that our code respects Prettier, ESlint, StyleLint and EditorConfig settings. We can challenge those settings, but won't add our own code style if it goes against those settings.
You are allowed to breake those rules if the ESLint gets unnecessarily complex or if you cannot do it otherwise.
Respect our best practices
We love to give and receive feedbacks on our pull requests (short: PRs). Every feedback is per se legitimate.
If we comment on a pull request, we always provide an explanation for our feedback. If possible, we also provide links to reference material. A great way to comment would be also adding a helpful code snippet. As a general rule, always give as much help as possible, with the goal being to enable the original PR creator to continue his/her work.
In a PR we avoid to change established conventions. We will challenge those in a separate meeting.
A PR should be merged as soon as possible; it should not be a place for comprehensive conversation. If a conversation gets too intense, we will finish it bilaterally and offline. After agreement is reached, we write it down and reference it in the PR.
We always respects each other's opinion, as every opinion is valid. The better idea always wins, whether it comes from an apprentice or from a CTO. If a clash of opinions arises, we discuss it in a constructive way.
We assume that a PR creator already knows standard HTML, CSS and JS. We therefore won't explain such basics in a PR, but are very happy to help verbally and bilaterally those new future frontend heroes who might struggle in such areas. Everyone of us started from the beginning at some point, and helping someone is a honor for us.
An example of what a constructive conversation should (not) look like:
- DON'T SAY: This is wrong, here is the link to the spec!
- DO SAY: I'd like to refer to our coding style defined in our style document XXX; here, this code snippet xxxx would be more correct because of...
We aim to be as efficient as possible. On a PR review, we try to explain before referring to specs as we assume everyone have read the specs but maybe not understood it. We use links to specs as a nice add-on to the explanation, not as a minimum viable argument. Of course, if an explanation requires lots of text and time, just referring to a spec might be ok. As a rule of thumb, always choose the review strategy that solves the PR creator's issue as soon as possible, as our goal is to merge a PR as quickly as possible. In a review context, we also assume that everyone is willing to learn. Elements of teaching as part of a review are very welcome, but are based on individual good will rather than being obligatory.
We will always make a PR, unless there is no chance for errors. Code changes and documentation changes always require a PR, for example, since the PR owner may make mistakes in program code changes or introduce grammatical errors.
We are free to create issues on GitHub labeled with feature-request whenever we want, but we won't start working on them before the team approves them with democratic majority (50% + 1 vote). With creating a feature request we also add it to the Github project board. Ideally, we discuss such a feature request in an after-daily meeting, where we decide if it makes sense or not to implement it. Once the team approves, we label the issue Accepted and also add it to the Accepted column in our project board. Only feature requests labeled as "Accepted" may be implemented. Issues that are in progress have to be moved to the In progress column of the project board.
Issues which are about differences in functionality compared to documentation and/or expected behaviour of components will receive the bug label. Issues labeled as "bug" always have higher priority. Once one of the core developers is able to reproduce the issue, it will receive the label Accepted. Only bugs labeled as "Accepted" may be fixed.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at luca.mele@axa-winterthur.ch. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate, given the circumstances. The project team is obliged to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.