-
Notifications
You must be signed in to change notification settings - Fork 0
/
CONTRIBUTING
45 lines (26 loc) · 3.06 KB
/
CONTRIBUTING
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# Getting Involved
Thank you for your interest in this project. We'd love to see your contributions. There are just few small guidelines you need to follow.
Please note we have a code of conduct, please follow it in all your interactions with the project.
## Opening an issue
If you've noticed a bug or you have a suggestion for a new feature, please go ahead and open an issue in this project. Please do include as much information as possible.
Please file issues before doing substantial work; this will ensure that others don't duplicate the work and that there's a chance to discuss any design issues.
## Making a code change
We're always open to pull requests, but these should be small and clearly described so that we can understand what you're trying to do.
When you're ready to start coding, fork the needed repository to your own GitHub account and make your changes in a new branch. Once you're happy, open a pull request and explain what the change is and why you think we should include it in our project.
## Code reviews
All submissions, including submissions by project members, require review. We use GitHub pull requests (PRs) for this purpose. Consult [GitHub Help](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) for more information on using pull requests.
Before a PR can be reviewed, ensure you have done the following, and fixed any issues that may arise:
- Ensure branch is up to date `git rebase main`
- Check formatting: `npm run lint`
- Run unit-tests: `npm run test`
Once a PR is opened, review is required by the Codeowners. It is also required that all status checks pass before a PR can be merged.
## Documentation
Our code is documented in-line with JSDoc according to the [Custom Elements Manifest](https://custom-elements-manifest.open-wc.org/analyzer/getting-started/#documenting-your-components).
All parameters, attributes and slots should be documented with brief descriptions and default values and classes should have thorough usage instructions.
Once code is written, all components should have a story written in Storybook. Single components can use autodocs to create their documentation, but for complex components we may need to create the markdown. We must run `npm run analyze` before writing stories, as this updates [custom-elements.json](./custom-elements.json) which storybook uses.
To create a story, first create a directory under `src/stories` for the component.
In storybook, always add the `title` parameter as this is used in documentation.
For single components, we should add `tags:['autodocs']` to storybook to generate the documentation.
For complex components, we should create a folder within `src/stories` for this component. In this directory, we create all stories needed and add the same `title` to all.
Then create a `Docs.mdx` file in this folder, alongside all the stories.
Within this we need to import the stories, and the blocks from storybook - see [Badges](./src/stories/Badges/Docs.mdx) for an example. We can then display the canvas, description and ArgTypes for all the components.