@mozaic-ds/postcss-media-queries-packer-on-demand

# Contributing Guide We're glad you're thinking about contributing to our projet, you rock ❤️! This project is made possible by an incredible community that finds issues and creates pull requests. ## Code of Conduct Our Team is committed to building a safe, welcoming, harassment-free culture for everyone. This is why our project adheres to the [Contributor Covenant](https://www.contributor-covenant.org/) code of conduct. By participating, you are expected to [uphold this code](https://github.com/adeo/postcss-media-queries-packer-on-demand/blob/main/CODE_OF_CONDUCT.md). Please report unacceptable behavior to designsystem@adeo.com. ## Be part of something bigger! When it comes to **Open Source**, there are different ways you can contribute, all of which are valuable. We welcome any type of contribution, **not only code**. So you can help with: **Writing** - Write and improve the project's documentation - Write tutorials for the project - Create examples showing how the project is used **Organizing** - Ask clarifying questions on recently opened issues to move the discussion forward - Link to duplicate issues, and suggest new issue labels, to keep things organized - Go through open issues and suggest closing old ones **Code** - Find an open issue to tackle - Ask if you can help write a new feature - Review code on other people's submissions - Automate project setup - Improve tooling and testing **Helping others** - Answer questions for people on open issues - Help moderate the discussion boards or conversation channels - Offer to mentor another contributor - Join the Slack community to interact with and help Grommet users. Here's a few guidelines that should help you as you prepare your contribution. ## Contribution process Our contribution process can be summarized as follows: ```mermaid flowchart TD A((I have a need: fix or new feature)) A --> B{An issue already exists?} B --> |YES| I I([The issue corresponds to my needs or I complete it]) I --> D B --> |NO| C C([I create an issue]) C --> D D{I can contribute?} D --> |YES| E D --> |NO| J E([I clone the repository and create a Pull Request associated to the issue.]) E --> F F([My Pull Request is ready and I assign it to reviewers]) F --> G G{The proofreading is OK and the PR is validated?} G --> |YES| H G --> |NO| K H([The PR is merged and will be released soon based on the release cycle.]) H J([I wait for the issue to be traited and delivered according to project team availability.]) K([I make the requested changes]) K --> F click B "https://github.com/adeo/postcss-media-queries-packer-on-demand/issues" _blank click C "https://github.com/adeo/postcss-media-queries-packer-on-demand/issues/new/choose" _blank click H "https://github.com/adeo/postcss-media-queries-packer-on-demand/blob/main/RELEASING.md" _blank ``` You can now discover the details of each of these steps below. ## 1. Find or create an issue ### Find an issue The first step for any contribution is to check that **an issue**, directly related to your contribution, hasn't been already [opened or solved](https://github.com/adeo/postcss-media-queries-packer-on-demand/issues?q=is%3Aissue). We use [GitHub Issues](https://docs.github.com/en/issues) to track work and log bugs. So, if you've noticed a bug or have any need, search [the issue tracker](https://github.com/adeo/postcss-media-queries-packer-on-demand/issues) to see if someone else in the community has already created one. In your search, you may find yourself in one of the following situations: <details> <summary>You found an issue and it's still open?</summary> <div class="content"> You can then assign it to yourself for processing. (You can also add comments to complete or expand it). </div> </details> <details> <summary>You found a closed issue about a bug, but it's still here?</summary> <div class="content"> Please open a new issue mentioning the closed one with all details: how to reproduce it, screenshots and videos if you can. </div> </details> <details> <summary>You didn't find any corresponding issue?</summary> <div class="content"> Go ahead and open a new issue! Collect and describe as much relevant information as possible. (See the <a href="#create-an-issue">"Create an issue"</a> section below). </div> </details> ### Create an issue If there are no bugs or issues matching your need in the current issue tracker, you can [create a new issue](https://github.com/adeo/postcss-media-queries-packer-on-demand/issues/new/choose), taking care to use the right issue template. Explain the problem and include additional details to help maintainers reproduce the problem: - **Use a clear and descriptive title** for the issue which explains the problem as accurate as possible. For instance: - **not helpful:** "Issue with tags" - **much better:** "[Autocomplete]: Clear taglist don't work when combined with v-model" - **Describe the exact steps which reproduce the problem in as many details as possible.** - **Provide specific examples to demonstrate the steps.** Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples. Please consider also using [Stackblitz](https://stackblitz.com/), [CodeSandbox](https://codesandbox.io/) or [Codepen](http://codepen.io/) to provide a testable code example. - **Describe the behavior you observed after following the steps** and point out what exactly is the problem with that behavior. - **Explain which behavior you expected to see instead and why.** - **Include screenshots and animated GIFs** which show you following the described steps and clearly demonstrate the problem. > [!NOTE] > We review issues on **a bi-weekly basis** _(sometimes more frequently)_. > When we require more information from you, we'll ask. > In order to keep the issue queue clean, we ask that you respond **within one week** or we'll close the issue pending your response. > [!CAUTION] > We do our best to respond to issues within a few days. > Please keep in mind that [the Core Team](https://github.com/orgs/adeo/teams/adeo-design-system) is small and that we are not always able to respond immediately, so please be patient. If you don't get a response immediately, it doesn't mean that we are ignoring you or that we don't care about your issue or PR. We will get back to you as soon as we can. ## 2. Submitting your contribution (Pull Requests) At this point, you're ready to make your changes! :rocket: We're excited to learn from you. :grinning: **All submissions should come in the form of [Pull Requests](https://docs.github.com/en/pull-requests).** Here are a few tips to help you create a good pull request that will have the best chances of being accepted: - Do not create a pull request that is not related to an issue. - For significant changes, it is recommended that [you ask first](https://adeo-tech-community.slack.com/archives/CKQJZL7C4) before start coding, otherwise you risk spending a lot of time working on something that the Core Team might not want to merge into the project. - Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests. - Follow the same coding style with regards to spaces, semicolons, variable naming etc. - Document your code. - Add/update [stories](https://github.com/adeo/postcss-media-queries-packer-on-demand/tree/main/stories) in Storybook for your changes. - Write a [good commit message](#commit-convention). - Make sure linting and tests pass. - [Reference the related issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) in the pull request description. - Add a clear description covering your changes. With all this in mind, you can now follow the usual git workflow for submitting a pull request: 1. Clone this repository. 2. Configure and install the dependencies: `npm install` 3. Create a new branch from main: `git checkout -b your-branch-name` 4. Make your changes and commit them. 5. Test your changes 6. Push your branch, open a pull request and add a comment describing your proposed changes. 7. Wait for CI steps to finish. - :heavy_check_mark: If the steps pass, you should see a status check telling you. - :x: If the tests fail, review the logs and address any issues. - :x: If the builds fail for any other reason (as they occasionally do), they may need to be manually restarted. 8. Pat yourself on the back and wait. :clap: :tada: Congratulations! You've done your part like a boss! Now you just need to wait reviews from the core team, your pull request will either be merged, request changes or closed with an explanation. > [!TIP] > Working on your very first Pull Request? You can learn how from this video series: [How to contribute to an open source project on Github](https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github). > Feel free to ask for help, everyone is a beginner at first. ## 3. Review phase You've done a great job and you've got a sense of achievement! :sunglasses: But there's one question on your mind: **what's the next step?** Well, remember that all submissions require review, please be patient, the ball is now in the proofreaders' court. The team will review your pull request and do one of the following: - Request changes to it. _(most common)_. - Merge it. - Close it with an explanation. > [!NOTE] > We review **pull requests** on **a bi-weekly basis** _(sometimes more frequently)_. > When we require more information from you, we'll ask. > In order to keep the pull request queue clean, we ask that you respond **within two weeks** or we'll close the pull request pending your response. ## 4. Release See RELEASING.md for our release process. ## Styleguides ### HTML [Adhere to the Code Guide.](https://codeguide.co/#html) - Use the [B.E.M methodology](https://getbem.com/) to write all the class attributes - Use tags and elements appropriate for an HTML5 doctype (e.g., self-closing tags). - Use [WAI-ARIA](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA) attributes in documentation examples to promote accessibility. ### CSS [Adhere to the Code Guide.](https://codeguide.co/#css) - Use the [B.E.M methodology](https://getbem.com/) to write all the CSS selectors ### Commit convention Commit messages should follow the [Angular's commit convention](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular#angular-convention) so that changelogs can be automatically generated. Commit messages will be automatically validated upon commit.  ### Git branches naming convention You are free to name your branches as you see fit. However, if you lack inspiration, we suggest you follow the following convention: `type/[issue-number]-[subject]` where: - `type`: corresponds to the type of your contribution _(equivalent to the `type` in the [Angular's commit convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type))_ - `issue-number`: the number of your issue preceded by the word `issue`. _(This is because each PR must be linked to an issue)_ - `subject`: The subject or element to which your contribution relates For example: ```bash git checkout -b fix/issue-007-autocomplete ```