Thank you for expressing interest in contributing to our CSS exercises! Please be sure to read this guide thoroughly before contributing, as it will lessen the chances of any issues arising during the process.
**Please do not open a pull request (PR) with your solutions to any exercises in this repo**. Your PR will be immediately closed without being merged. The exercises are for you to do and keep on your own local machine or your personal GitHub.
* [Being Assigned an Issue](#being-assigned-an-issue)
* [Creating an Issue](#creating-an-issue)
* [Setting Up Your Local Clone](#setting-up-your-local-clone)
* [Working on an Issue](#working-on-an-issue)
* [Opening a Pull Request](#opening-a-pull-request)
* [Further Help](#further-help)
## Label Meanings
The labels that get applied to issues and PRs have specific meanings and are broken into two categories: status and type. An issue/PR should only ever have one status label, but can have multiple type labels.
The complexity of a change can determine how exactly you should go about contributing. Generally, simpler or more minor changes can just have an issue made or a PR created rather than needing to bring it up on our Discord server. Things that are simple or more minor that you should feel free to just create an issue or PR can include:
* Typo or grammar fixes - "I noticed that this sentence in this lesson is using incorrect grammar."
* Simple syntax errors - "This line of code is missing a closing element tag."
* Clarifying questions - "This lesson says to use this syntax, but in a previous lesson we were told to use a different syntax. Which is correct?"
* Small-scale changes - "I think including instructions about X could help minimize confusion at this step."
On the other hand, if you have a more complex suggestion or notice a more urgent issue, going to our [`contribution-suggestions-bugs-disccusion` Discord channel](https://discordapp.com/channels/505093832157691914/540903304046182425) can be a great way to get more of a discussion or receive feedback. This channel can also be used to share a link to an issue or PR you have created and to ask for feedback **if** you haven't seen any activity on the actual issue/PR for a while; just keep in mind that maintainers have busy lives and may not get to things immediately.
While you should also feel free to just create an issue for more complex or urgent changes rather than bring it up on our Discord, generally you should avoid spending the time to create a PR for such changes. Depending what the PR entails, it may not be something we're looking to implement at this time or is not how we wish to go about things, and we don't want all of that time and work going to waste. Changes that may be more complex or urgent can include:
* A complete rewrite of a lesson
* Adding a completely new lesson
* HTML in lessons is not displaying properly
* A new feature for the website
Regardless of the complexity of a change, when you wish to make a contribution you should follow any further instructions in this guide.
1) Find an issue that is not currently assigned to anyone.
* A couple of good places to start are ["help wanted" issues](https://github.com/TheOdinProject/css-exercises/labels/Status%3A%20Help%20Wanted) or ["good first issue" issues](https://github.com/TheOdinProject/css-exercises/labels/Type%3A%20Good%20First%20Issue)
If you would like to make a small change (fixing a typo, updating a link, etc.) that is not part of an existing issue, you are welcome to make the change and submit a PR without creating an official issue.
If you do not wish to make a small change yourself and instead want to create an issue for it, or if you would like to propose a more significant change:
2. If the issue doesn't already exist, create a new one and **read the issue template in its entirety and fill out all applicable sections**.
* The title of the issue should be in `file/exercise/folder: brief description of issue` format. This makes it easier for anyone to quickly see what an issue is for, reducing the possibility of a duplicate issue from being made.
* If you would like to be assigned the issue you are creating, complete the applicable checkbox in the issue template. Note that this does not guarantee that you will be assigned the issue, but rather it lets maintainers know that you are interested.
1. Fork this repo to your own GitHub account. If you don't know how to do so, follow the GitHub documentation on how to [fork a repo](https://docs.github.com/en/get-started/quickstart/fork-a-repo).
3. Sync your work with the upstream remote every so often. Follow the [ongoing workflow](https://www.theodinproject.com/paths/full-stack-ruby-on-rails/courses/ruby-programming/lessons/using-git-in-the-real-world#ongoing-workflow) section in our Using Git in the Real World lesson.
5. Preview your proposed changes by locally opening any applicable HTML files (or using VS Code's Live Server extension). If the preview matches the existing "Desired Outcome" image(s) for the exercise, continue to open a pull request. Otherwise, update any images in your local clone and commit + push those changes before opening a pull request.
1. After pushing your changes, go to your forked repo on GitHub and click the "Compare & pull request" button. If you have multiples of this button, be sure you click the one for the correct branch.
2.**Read the PR template in its entirety before filling it out and submitting a PR**. Not filling out the template correctly will delay a PR getting merged.
* If a checkbox is not required and is not applicable to your PR, do not complete it. If your PR isn't related to an open issue, for example, you shouldn't complete the checkbox for linking an issue.
* The title of the PR should be in `file/exercise/folder: brief description of change` format, e.g. `01 flex center: add hint for XYZ`. This makes it easier for anyone to quickly see what a PR is for, reducing the possibility of a duplicate PR from being made.
* Be sure you describe the change(s) you are proposing in more detail in Step 1 of the PR template. If the PR is not related to an open issue, you should also include why your proposed changes are beneficial or what problem(s) it solves. This gives maintainers the information to consider when deciding whether a PR should be merged.
* If the PR is related to an open issue, be sure to link that issue in Step 2 of the PR template. This can be done either by replacing the `XXXXX` with the issue number, e.g. `Closes #2013`, or if the issue is in another TOP repo replacing the `#XXXXX` with the URL of the issue, e.g. `Closes https://github.com/TheOdinProject/curriculum/issues/XXXXX`. This streamlines the issue closing process, as an issue that is linked to a PR will be closed when that PR gets merged.
3. At this point a maintainer will either leave general comments, request changes, or approve and merge your PR.
* It is important to respond to any comments or requested changes in a timely manner, otherwise your PR may be closed without being merged due to inactivity.
* After pushing any requested changes to the branch you opened the PR with, be sure to re-request a review from the maintainer that requested those changes at the top of the right sidebar:
![Reviewers section of GitHub's sidebar](https://user-images.githubusercontent.com/70952936/150647064-4fdd59d1-82a4-4f18-894d-0e43a5ee0ffb.jpg)
Please let us know if you require any further help with any of the steps in this guide in our Discord's [contribution-suggestions channel](https://discordapp.com/channels/505093832157691914/540903304046182425).