docs: make scope and naming of Pull Requests clearer (#35272)
Co-authored-by: Randell Dawson <5313213+RandellDawson@users.noreply.github.com> Co-authored-by: mrugesh mohapatra <1884376+raisedadead@users.noreply.github.com>
This commit is contained in:
committed by
mrugesh mohapatra
parent
078e51959a
commit
f0d907be66
44
docs/how-to-open-a-pull-request.md
Normal file
44
docs/how-to-open-a-pull-request.md
Normal file
@ -0,0 +1,44 @@
|
|||||||
|
# How to open a Pull Request
|
||||||
|
|
||||||
|
## How to prepare a good Pull Request title:
|
||||||
|
|
||||||
|
When opening a Pull Request(PR), use the following scope table to decide what to title your PR in the following format:
|
||||||
|
`fix/feat/chore/refactor/docs/perf (scope): PR Title`
|
||||||
|
|
||||||
|
An example is `fix(learn): Fixed tests for the do...while loop challenge`.
|
||||||
|
|
||||||
|
| Scope | Documentation |
|
||||||
|
|---|---|
|
||||||
|
| `learn`,`curriculum` | For Pull Requests making changes to the curriculum challenges. |
|
||||||
|
| `client` | For Pull Requests making changes to client platform logic or user interface |
|
||||||
|
| `guide` | For Pull Requests which make changes to the guide. |
|
||||||
|
| `docs` | For Pull Requests making changes to the project's documentation. |
|
||||||
|
|
||||||
|
## Proposing a Pull Request (PR)
|
||||||
|
|
||||||
|
1. Once the edits have been committed, you will be prompted to create a pull request on your fork's GitHub Page.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
2. By default, all pull requests should be against the freeCodeCamp main repo, `master` branch.
|
||||||
|
|
||||||
|
Make sure that your Base Fork is set to freeCodeCamp/freeCodeCamp when raising a Pull Request.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
3. Submit the pull request from your branch to freeCodeCamp's `master` branch.
|
||||||
|
|
||||||
|
4. In the body of your PR include a more detailed summary of the changes you made and why.
|
||||||
|
|
||||||
|
- You will be presented with a pull request template. This is a checklist that you should have followed before opening the pull request.
|
||||||
|
|
||||||
|
- Fill in the details as they seem fit you. This information will be reviewed and decide whether or not, your pull request is going to be accepted.
|
||||||
|
|
||||||
|
- If the PR is meant to fix an existing bug/issue then, at the end of
|
||||||
|
your PR's description, append the keyword `closes` and #xxxx (where xxxx
|
||||||
|
is the issue number). Example: `closes #1337`. This tells GitHub to
|
||||||
|
automatically close the existing issue, if the PR is accepted and merged.
|
||||||
|
|
||||||
|
5. Indicate if you have tested on a local copy of the site or not.
|
||||||
|
|
||||||
|
This is very important when you are making changes that are not just making edits to text content such as a Guide article verbiage. Examples of changes needing local testing would include JavaScript, CSS, or HTML which could change the functionality or layout of a page.
|
@ -422,32 +422,7 @@ Follow these steps:
|
|||||||
|
|
||||||
## Proposing a Pull Request (PR)
|
## Proposing a Pull Request (PR)
|
||||||
|
|
||||||
1. Once the edits have been committed, you will be prompted to create a pull request on your fork's GitHub Page.
|
After you've committed your changes, check here for [how to open a Pull Request](/docs/how-to-open-a-pull-request.md).
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
2. By default, all pull requests should be against the freeCodeCamp main repo, `master` branch.
|
|
||||||
|
|
||||||
Make sure that your Base Fork is set to freeCodeCamp/freeCodeCamp when raising a Pull Request.
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
3. Submit the pull request from your branch to freeCodeCamp's `master` branch.
|
|
||||||
|
|
||||||
4. In the body of your PR include a more detailed summary of the changes you made and why.
|
|
||||||
|
|
||||||
- You will be presented with a pull request template. This is a checklist that you should have followed before opening the pull request.
|
|
||||||
|
|
||||||
- Fill in the details as they seem fit you. This information will be reviewed and decide whether or not, your pull request is going to be accepted.
|
|
||||||
|
|
||||||
- If the PR is meant to fix an existing bug/issue then, at the end of
|
|
||||||
your PR's description, append the keyword `closes` and #xxxx (where xxxx
|
|
||||||
is the issue number). Example: `closes #1337`. This tells GitHub to
|
|
||||||
automatically close the existing issue, if the PR is accepted and merged.
|
|
||||||
|
|
||||||
5. Indicate if you have tested on a local copy of the site or not.
|
|
||||||
|
|
||||||
This is very important when you are making changes that are not copy editing markdown files. For example, changes to CSS or JavaScript code, etc.
|
|
||||||
|
|
||||||
## Getting Help
|
## Getting Help
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user