# CONTRIBUTING - [Getting Started](#getting-started) - [TL;DR](#tldr) - [Get in touch](#get-in-touch) - [Code of Conduct](#code-of-conduct) - [Before you start](#before-you-start) - [Open An Issue](#open-an-issue) - [Bug reports](#bug-reports) - [Missing components](#missing-components) - [Help wanted](#help-wanted) - [Request for improvement](#request-for-improvement) - [Ready for PR](#ready-for-pr) - [Create a new Component](#create-a-new-component) - [Open A PR](#open-a-pr) - [Releasing and versioning](#releasing-and-versioning) - [Labels](#labels) ## Getting Started Telia Finland's react component library is under very active development by the core Design System team. Our long term goal is to foster an environment for the product teams to take ownership and contribute to the component library as their own. We're not quite there yet, but we hope that this document gives you a more transparent view of the contribution process in general. If you have any questions, please feel free to [get in touch with the Design Team](#get-in-touch). Before starting to contribute, read [README.md][9]. It tackles many technical questions and prerequisites for getting you started with contributing to the react component library. ## TL;DR - Core Design System team works with product teams - Product teams collaborate and communicate using different channels (GitHub/Slack/JIRA) - Core team defines the quality standards, guidelines, and other best practices - Product teams are the main contributors - Core Design System team make sure that contributed work meets [the Design System standards][11] ## Get in touch To help shape this library, start a discussion. If you want to add to the library or have a question – get in touch! The easiest way to reach us is through the [#design-system Slack channel][12]. We follow all conversations in our Slack channel. We try to respond quickly, but sometimes it might take several hours for us to respond, so please have patience. You can also open an issue here on GitHub, as that's a perfect way for all of us to have an open discourse. ## Code of Conduct Before starting to contribute, read [our code of conduct][10]. ## Before you start When you discover that a component or a feature is needed, consider if other product teams can re-use that as well. If so, it is a perfect fit for the Design System component library. If you're fixing a bug, it's a good idea to open an issue or let us know in the [Slack channel][12]. Simple bug fixes usually are accepted without much due process. It's always a good practice to involve the Design System team to avoid any overlapping work. Collaboration from the get-go helps with getting early feedback and faster iterations on your work. ## Open An Issue 1. [Missing components](#missing-components) 2. [Help wanted](#help-wanted) 3. [Request for comments/improvement](#request-for-comments-improvement) 4. [Ready for PR](#ready-for-pr) Open an issue whenever you have questions, suggestions, or if you want to give general feedback. We go through every issue and comment. Here are the most common issues: ### Bug reports Create an issue for a bug you find, labeled `bug`. Include steps to reproduce the issue and screenshots in your bug reports whenever possible. ### Missing components We're seeking components to support different needs. Create an issue for every missing component, labeled `new component`. Just comment on the issue you'd like to take. We create a ticket for it, and after that, you can start working on it. ### Help wanted Any other issues that are labeled `help wanted`; this means someone has questions, the contributor should join and start a discussion. ### Request for improvement To help shape this library, start a discussion. If you have ideas for improving existing components, create issues labeled `request-for-improvement`. We are happy to give and receive comments. ### Ready for PR If you find an issue with label `Ready for PR`, you can start to work on it. ## Create a new Component We've gathered the most up to date information on creating a new component in the [README.md][9] ## Open A PR After talking with the Design System team, you're now at a phase where you're ready to make your minimal functional Pull Request. The Design System reviews all Pull Requests following [the Code Review Checklist][11]. As a rule of thumb, smaller pull requests are more comfortable to review and fix, and faster to get approved. Use the [Pull Request template][13] when submitting your work. If the Design System team has opened a [JIRA ticket][5], please include Jira ticket number in the title, for example: ``` TDS-1337 My Pull request ``` Include screenshots in your pull request whenever possible. Use labels according to [Labels](#labels) We have created a [Code Review Checklist][11] for you to see so you can make sure your code is compliant with the Design System coding standards. ## Releasing and versioning The component library uses [Semantic versioning](https://semver.org/). Releasing is done almost exclusively by the Design System. Our [README.md][9] has outlined the process thoroughly. ## Labels | Label name | Description | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | `missing-component` | If you need some component but not exist in component library | | `ready-for-pr` | It is ready for PR, and there should be a ticket for it | | `request-for-improvement` | Propose for changes, looking for comments | | `bug` | Confirmed bugs or reports that are very likely to be bugs. | | `help-wanted` | When you would appreciate help from the community in resolving these issues. | | `wontfix` | The core team has decided not to fix these issues for now, either because they're working as intended or for some other reason. | | `invalid` | Issues which aren't valid (e.g. user errors). | | `breaking-changes` | If the PR is about to make breaking changes | | `work-in-progress` | Pull requests which are still being worked on, more changes will follow. | | `needs-code-review` | Pull requests which need code review, and approval from maintainers. | | `needs-design-review` | Pull requests which need design review. | | `requires-changes` | Pull requests which need to be updated based on review comments and then reviewed again. | [1]: https://nodejs.org/en/download/ [2]: https://github.com/prettier/prettier [3]: https://github.com/telia-company/telia-react-component-library [4]: https://docs.npmjs.com/downloading-and-installing-node-js-and-npm [5]: https://devopsjira.verso.sonera.fi/secure/RapidBoard.jspa?rapidView=549 [6]: http://agiledata.org/essays/tdd.html [7]: https://docs.cucumber.io/gherkin/reference/ [8]: http://usejsdoc.org/ [9]: https://github.com/telia-company/telia-react-component-library [10]: https://github.com/telia-company/telia-react-component-library/CODE_OF_CONDUCT.md [11]: https://github.com/telia-company/telia-react-component-library/CODE_REVIEW_CHECKLIST.md [12]: https://teliafin.slack.com/archives/CF8073KQA [13]: https://github.com/telia-company/telia-react-component-library/PULL_REQUEST_TEMPLATE.md