Code of conduct

[YonatanKra]

1. Bugs must be added to JIRA
   1. Exact description of the issue, including:
      1. root cause
      2. retrace information
      3. links to other Jira tickets and PRs
      4. complete documentation of the resolution process (using comments).
2. Branch naming conventions: VIV-<issue_number>/<type>/<description>
   2. type: feature, bug etc.
   3. Scope: predefined scopes only
   4. PRs should only contain scope related changes (maybe this belongs elsewhere in the doc?)
3. Design document -
   5. The design document will be added as a github discussion. Example
   6. A design document will be written per new component or big feature
   7. The design document will focus on API and user stories
   8. Design meetings:
   5. Each design document will be shared with the group at least 24 hours before the meeting
   6. In the dedicated meeting, we will brainstorm over it (cons/pros of suggested APIs)
4. Components maturity - we’ve decided that every component in the master branch will be production ready. For this, we will follow the below guidelines:
   9. Communicate new components/features that are likely to change to the users. This will be done in the storybook via a tag.
   10. Everything that goes into master is production ready. Production ready means:
   7. Has a design document
   8. The API is fully tested
   9. Tests not broken
   11. Preliminary collaboration:
   10. Early POC collaboration will be done via the StoryBook generated for a PR/Draft
   12. Legacy: Tasks should be added to JIRA to remove existing non-ready packages or make them production ready
5. Testing:
   13. Hard stop on coverage regression
   14. All components should be production ready - e.g. cover the main business use cases in tests
6. Code standards - The Vivid team is obligated for the following coding standards. In general code should strive to preserve uniformity across the repo (or even in all repos in Vivid’s disposal - we all own all)
   15. Typescript - all code should be written in typescript
   16. Linting according to the rules in the repository - link to repo lint rules
   17. SCSS for styling - styles will
   18. Code readability is a must especially in OSS model that encourages unknown contributions and maintenance:
   11. If two reviewers claim non readability - the suggestions should be accepted
   19. Use internal tooling where applicable

[yinonov]

were u looking for this?