Merge pull request #117 from thatblindgeye/thatblindgeye-patch-2

Templates/guides: Create and update files
This commit is contained in:
Eric Olkowski 2022-02-02 17:55:20 -05:00 committed by GitHub
commit 8742c44381
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 218 additions and 41 deletions

38
.github/ISSUE_TEMPLATE/bug_report.md vendored Normal file
View File

@ -0,0 +1,38 @@
---
name: Bug Report
about: Create a report to help us improve
title: ''
labels: 'Status: Needs Review, Type: Bug'
assignees: ''
---
<!-- Thank you for taking the time to submit a bug report to The Odin Project. In order to get issues closed in a reasonable amount of time, you must include a baseline of information about the bug in question. Please read this template in its entirety before filling it out to ensure that it is filled out correctly. -->
<!-- Complete the following REQUIRED checkboxes by replacing the whitespace between the square brackets with an 'x', e.g. [x]. -->
- [ ] I have thoroughly read and understand [The Odin Project Contributing Guide](https://github.com/thatblindgeye/css-exercises/blob/main/CONTRIBUTING.md)
- [ ] The title of this issue is similar to the `file, exercise/lesson, or folder: brief description of bug` format, e.g. `01 flex center: solution files do not match desired outcome`
<!-- The following checkbox is OPTIONAL. Completing it does not guarantee you will be assigned this issue, but rather lets us know you are interested in working on it. -->
- [ ] If approved, I would like to be assigned this issue to work on it
**1. Description of the Bug**
<!-- A clear and concise description of what the bug is. Include any screenshots that may help show the bug in action. -->
**2. How To Reproduce**
<!-- What steps one might need to take in order to reproduce this bug. -->
**3. Expected Behavior**
<!-- A brief description of what you expected to happen. -->
**4. Desktop/Device:**
- Device: <!-- [e.g. iPhone6] -->
- OS: <!-- [e.g. iOS] -->
- Browser: <!-- [e.g. chrome, safari] -->
- Version: <!-- [e.g. 22] -->
**5. Additional Information**
<!-- Any additional information about the bug. -->

View File

@ -0,0 +1,24 @@
---
name: Feature Request
about: Suggest a new feature for this project
title: ''
labels: 'Status: Needs Review, Type: Enhancement'
assignees: ''
---
<!-- Thank you for taking the time to submit a new feature request to The Odin Project. In order to get issues closed in a reasonable amount of time, you must include a baseline of information about the feature you are proposing. Please read this template in its entirety before filling it out to ensure that it is filled out correctly. -->
<!-- Complete the following REQUIRED checkboxes by replacing the whitespace between the square brackets with an 'x', e.g. [x]. -->
- [ ] I have thoroughly read and understand [The Odin Project Contributing Guide](https://github.com/thatblindgeye/css-exercises/blob/main/CONTRIBUTING.md)
- [ ] The title of this issue is similar to the `file, exercise/lesson, or folder: brief description of request` format, e.g. `01 flex center: add hint for XYZ`
<!-- The following checkbox is OPTIONAL. Completing it does not guarantee you will be assigned this issue, but rather lets us know you are interested in working on it. -->
- [ ] If approved, I would like to be assigned this issue to work on it
**1. Description of the Feature Request**
<!-- A clear and concise description of what the feature is. Also include how it would be useful/beneficial or what problem(s) it would solve. -->
**2. Additional Information**
<!-- Any additional information or screenshots about the feature request. -->

View File

@ -1,10 +1,10 @@
<!-- Thank you for taking the time to contribute to The Odin Project. In order to get pull requests (PRs) closed in a reasonable amount of time, you must include a baseline of information about the changes you are proposing. Please read this template in its entirety before filling it out to ensure that it is filled out correctly. -->
<!-- Complete the following REQUIRED checkboxes by replacing the whitespace between the square brackets with an 'x', e.g. [x]. -->
- [ ] I have thoroughly read and understand the [CSS Exercises Contributing Guide](https://github.com/TheOdinProject/css-exercises/blob/main/CONTRIBUTING.md)
- [ ] I have thoroughly read and understand [The Odin Project Contributing Guide](https://github.com/TheOdinProject/css-exercises/blob/main/CONTRIBUTING.md)
- [ ] The title of this PR is similar to the `file, exercise/lesson, or folder: brief description of changes` format e.g. `01 flex center: add hint for XYZ`
<!-- Complete the following checkboxes only if they are applicable to your PR. You can complete these later if they are not currently applicable. -->
<!-- Complete the following checkboxes ONLY IF they are applicable to your PR. You can complete these later if they are not currently applicable. -->
- [ ] If one exists, I have linked a related open issue to this PR in Step 2 below
- [ ] If changes were requested, I have made them and re-requested a review from the maintainer (top of the right sidebar)

View File

@ -1,56 +1,153 @@
# CSS Exercises Contributing Guide
# The Odin Project Contributing Guide
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.
Thank you for expressing interest in contributing to The Odin Project (TOP)! Whether you are a first time contributor or you have made several contributions to our repos, 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.
**Please do not open an issue or pull request (PR) with your solutions to any exercise repo**. Your PR will be immediately closed without being merged. The exercise repos are for you to do and keep any work on your own local machine or your personal GitHub.
## Table of Contents
* [Curriculum Structure](#curriculum-structure)
* [Label Meanings](#label-meanings)
* [How to Contribute](#how-to-contribute)
* [Repo Specific Instructions](#repo-specific-instructions)
* [Check Before Doing Anything](#check-before-doing-anything)
* [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)
## Curriculum Structure
Between our website, repos, and Discord server, you're bound to see certain terms being used in regards to the curriculum structure. It can be important to keep these terms in mind when referring or contributing to certain parts of our curriculum, both for consistency and to make sure everyone understands what you mean.
* **Path**: The broadest level of the curriculum structure. When you first start TOP, you will be on the Foundations path. Upon completion of Foundations, you choose one of two different Full Stack paths to continue down.
* **Course**: A path is made up of different courses. A course splits a path into more distinct topics, and each course has its own completion percentage. When asked what course you're on, you might say "I'm on the Getting Hired course!"
* **Section**: A course is made up of different sections. A section splits a course into even more distinct topics. When asked what section you're on, you might say "I just started the Basic Ruby section!"
* **Lesson**: Finally, a section is made up of different lessons. This is the most specific level of the curriculum structure. This is the exact thing you're currently on. When asked what lesson you're on, you might say "I'm reading through the Webpack lesson!"
## Label Meanings
The labels that get applied to issues and PRs in our repos 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 following isn't a complete list, but rather a list of the labels that are more universal across all of our repos.
### Status Labels
* **Abandoned**: This issue/PR has been abandoned, and no further work or review should be done
* **Accepted**: This PR has been accepted and merged
* **Awaiting** Changes: Waiting for requested changes to be made
* **Awaiting** Response: Waiting for a response from the contributor
* **Completed**: This issue has been completed and a PR has been made
* **Discussion**: This issue/PR is actively being discussed
* **Do Not Merge**: This PR should not be merged until further notice
* **Do Not Review**: This issue/PR should not be reviewed until further notice
* **Help Wanted**: This issue can be assigned to other contributors
* **In Progress**: This issue/PR is actively being worked on
* **Invalid**: The template or another item in the issue/PR is invalid or not relevant
* **Investigating**: Something is being looked into by a maintainer, but the issue/PR is not being actively reviewed
* **Needs Review**: This issue/PR needs a review from one or more maintainers
* **On Hold**: There is a temporary hold on any continued work or review
* **Stale**: This issue/PR has been inactive for over 30 days and may be closed if inactivity continues
* **Under Review**: This issue/PR is actively being reviewed by at least one maintainer
### Type Labels
* **Accessibility**: Involves an accessibility feature or requires review for accessibility
* **Bug**: Something isn't working as intended
* **Chore**: Involves changes to the build process or internal tooling
* **Documentation**: Involves an update to the documentation
* **Duplicate**: This issue/PR already exists and should not be worked on or reviewed
* **Enhancement**: Involves a new feature or enhancement request
* **Good First Issue**: Good for beginner contributors
* **Hacktoberfest**: This issue/PR is a good Hacktoberfest participation
* **Maintainer Only**: This issue is available only to maintainers
## How to Contribute
The complexity of a change can determine how exactly you should go about contributing. Generally, simpler changes can just have an issue made or a PR created rather than needing to bring it up on our Discord server. Simple changes that you should feel free to just create an issue or PR for 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?"
* Other small-scale changes - "I think including an instruction about X could help minimize confusion at this step."
If you have a more complex suggestion or notice a more urgent issue, going to our [contribution-suggestions-bugs-discussions Discord channel](https://discordapp.com/channels/505093832157691914/540903304046182425) can be a great way to start a discussion or receive feedback. This channel can also be used to share a link to an issue or PR you have created if you haven't seen any activity on the actual issue/PR for a while, or to have a more real-time discussion. Just keep in mind that maintainers have busy lives - many with day jobs - and may not get to items on our repos immediately.
While you can also just create an issue on a repo for more complex or urgent changes rather than bring it up on our Discord, generally you should avoid doing work and opening 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 on one of TOP's repos you must follow any further instructions in this guide.
### Repo Specific Instructions
#### [TOP Curriculum Repo](https://github.com/TheOdinProject/curriculum)
When submitting a PR for a new lesson, or when you are making significant changes to an existing lesson, you must follow our [Layout Style Guide](https://github.com/TheOdinProject/curriculum/blob/main/LAYOUT_STYLE_GUIDE.md). This helps ensure the layout and formatting is consistent across all of our lessons.
If you're new to contributing to open-source, or if you just want to make a really quick PR, you can click the "Improve this lesson on GitHub" link found at the end of each lesson instead of going through the steps to fork + clone one of our repos.
#### [TOP Website Repo](https://github.com/TheOdinProject/theodinproject)
Before starting any work on our main website repo, you must read and follow the instructions found on [The Odin Project Wiki](https://github.com/TheOdinProject/theodinproject/wiki). These instructions will help you get the TOP app running locally, and help you with adding new paths, courses, sections, and lessons.
### Check Before Doing Anything
It's important that you look through any open issues or PRs in a repo before attempting to submit a new issue or work on a change, regardless of the complexity. This will help avoid any duplicates from being made, as well as prevent more than one person working on the same thing at the same time.
If your proposal already exists in an open issue or PR, but you feel therer are details missing, comment on the issue/PR to let those involved know of those missing details.
### Being Assigned an Issue
If you would like to work on an existing issue in the repo:
If you would like to work on an existing issue in a repo:
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/Help%20Wanted) or ["good first issue" issues](https://github.com/TheOdinProject/css-exercises/labels/good%20first%20issue)
1) Find an issue that is not currently assigned to anyone.
* A couple of good places to start are issues with the `Status: Help Wanted` or `Type: Good First Issue` labels. You can filter the issues list to only show ones with these (or any) specific labels to make them easier to find.
* You can also filter out any issues with the `Status: In Progress` label, so that you only see issues that haven't been assigned to anyone.
2) Ask to be assigned the issue by a maintainer
2) Ask to be assigned the issue by a maintainer.
* **If you are not a maintainer, do not give others permission to work on an issue**
3) **Wait to be assigned the issue before starting any work**
3) **Wait to be assigned the issue before starting any work**.
4) After being assigned, address each item listed in the acceptance criteria
* If there are no acceptance criteria stated in the issue, ask the maintainer that assigned you the issue if any exist
If you would like to propose 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 an official issue.
4) After being assigned, address each item listed in the acceptance criteria, if any exist.
* If an issue doesn't have any acceptance criteria, feel free to go about resolving the issue however you wish. You can also ask the maintainer that assigned you the issue if there are any specific acceptance criteria.
### Creating an Issue
If you would like to propose a more significant change:
1. If you would like to make a simple change that is not part of an existing issue, you are welcome to skip the next step and just submit a PR with your proposed change(s).
1. Go through the open issues and make sure an issue doesn't already exist
* If the issue already exists, but there are details you feel are missing, leave a comment on the already opened issue
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**
2. Create a new issue and **read the issue template in its entirety and fill out all applicable sections**. If you aren't sure how to create an issue, you can read the GitHub documentation on [creating an issue from a repository](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue#creating-an-issue-from-a-repository).
* The title of the issue should follow a format similar to `file, exercise/lesson, or folder: brief description of issue`. 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.
### Setting Up Your Local Clone
Before you begin working on anything, be sure you follow these steps in order to set up a clone on your local machine:
Before you begin working on anything, make sure you follow these steps in order to set up a clone on your local machine:
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)
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).
2. Clone this repo to your local machine with one of the commands below. Be sure the `<your username>` text is replaced with your actual GitHub username, and the `<repo name>` with the actual repo name. You can also read the GitHub documentaiton on [cloning a repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository).
2. Clone this repo to your local machine with one of the following commands, replacing the `<your username>` text with your actual GitHub username:
```bash
# If you have SSH set up with Git
git clone git@github.com:<your username>/css-exercises.git
# Otherwise for HTTPS
git clone https://github.com/<your username>/css-exercises.git
# If you have SSH set up with Git:
git clone git@github.com:<your username>/<repo name>.git
# Otherwise for HTTPS:
git clone https://github.com/<your username>/<repo name>.git
# An example:
git clone git@github.com:Odinson/css-exercises.git
```
3. `cd` into the directory of your local clone, then set the upstream remote so you can keep your local clone synced with TOP's original repo:
3. `cd` into the directory of your local clone, then set the upstream remote so you can keep your local clone synced with TOP's original repo. The `<repo name>` below should be the same as the one you used when creating your local clone in the previous step.
```bash
# If you have SSH set up with Git
git remote add upstream git@github.com:TheOdinProject/css-exercises.git
# Otherwise for HTTPS
# If you have SSH set up with Git:
git remote add upstream git@github.com:TheOdinProject/<repo name>.git
# Otherwise for HTTPS:
git remote add upstream https://github.com/TheOdinProject/<repo name>.git
# An example:
git remote add upstream https://github.com/TheOdinProject/css-exercises.git
```
@ -58,40 +155,58 @@ Before you begin working on anything, be sure you follow these steps in order to
Once you have the repo forked and cloned, and the upstream remote has been set, you can begin working on your issue:
1. Create a new branch, replacing the `<your branch name>` with an actual branch name, e.g. "flex_exercises":
1. Create a new branch, replacing the `<your branch name>` with an actual branch name:
```bash
git checkout -b <your branch name>
# An example:
git checkout -b flex_exercises
```
2. Add commits as you work on your issue, replacing the `<your commit message>` text with your actual commit message:
```bash
git commit -m "<your commit message>"
# An example:
git commit -m "Update solution files"
```
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.
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) instructions in our Using Git in the Real World lesson.
4. Push your branch to your forked repo, replacing the `<your branch name>` with the branch you've been working on locally:
```bash
$ git push origin <your branch name>
git push origin <your branch name>
# An example:
git push origin flex_exercises
```
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.
### Opening a Pull Request
1. After pushing your changes, go to your forked repo on GitHub and click the "Compare & pull request" button
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.
* If you don't see this button, you can click the branch dropdown menu and then select the branch you just pushed from your local clone:
![GitHub branch dropdown menu](https://user-images.githubusercontent.com/70952936/150646139-bc080c64-db57-4776-8db1-6525b7b47be2.jpg)
* Once you have switched to the correct branch on GitHub, click the "Contribute" dropdown and then click the "Open pull request" button
* Once you have switched to the correct branch on GitHub, click the "Contribute" dropdown and then click the "Open pull request" button.
2. **Read the PR template in its entirety and fill out all applicable sections** before submitting your PR
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 follow the format described in the PR template, which is usually some variation of `file, exercise/lesson, or folder: brief description of changes`. 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
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)
## Need Further Help?
Please let us know if you require any help doing any of the steps in this guide in our Discord's [contribution-suggestions channel](https://discordapp.com/channels/505093832157691914/540903304046182425).
## Further Help
Please let us know if you require any further help with any of the steps in this guide in our [contribution-suggestions-bugs-discussions Discord channel](https://discordapp.com/channels/505093832157691914/540903304046182425).