You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We appreciate your interest in contributing to this docs! Your contributions are very valuable to us, and we want to ensure that the process is easy and productive for everyone involved.
4
+
5
+
Please take a moment to read the guidelines below before contributing to the project.
6
+
7
+
## Project Description
8
+
9
+
This project contains the official documentations for all projects both open source and commercial by The Sailscasts Company.
10
+
11
+
## Contribution Workflow
12
+
13
+
When contributing to this project, we adhere to the [Gitflow branching model](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow).
14
+
15
+
In this workflow, we use the develop branch as the central branch for active development. Therefore, we request that all Pull Requests be targeted towards the develop branch instead of the main branch. This approach ensures the stability of our main branch while allowing continuous development on the develop branch.
16
+
17
+
## Before Contributing
18
+
19
+
Before diving into the contribution process and setting up your environment, it is essential to select an issue you would like to work on.
20
+
21
+
#### Here's a simple guide to follow:
22
+
23
+
1. Search through the list of [open issues](https://github.com/sailscastshq/docs.sailscasts.com/issues).
24
+
2. Find the issue you want to work on.
25
+
26
+
⚠️**Note:** If you notice a bug or you want to add a feature to the project, create a new issue using this [guide](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue)
27
+
28
+
3. Check to confirm if someone else has already worked on and made a pull request on said issue. To properly confirm, look out for a "pull request icon" on the issue. If there is none, you are good to go! If someone else has worked on the issue, kindly find a new issue to fix.
29
+
30
+
## Getting Started
31
+
32
+
#### To ensure a seamless contribution and review process, please follow these guidelines:
33
+
34
+
1. Open your preferred text editor.
35
+
2. Fork and clone the repository into your own github account.
36
+
[Here is a guide](https://docs.github.com/en/get-started/quickstart/fork-a-repo).
37
+
38
+
⚠️**Note:** If you cloned the repository a while back, we recommend fetching the latest changes from the upstream repository.
39
+
40
+
You can do this by using Github Desktop or running the following commands:
41
+
42
+
```
43
+
git checkout develop
44
+
```
45
+
46
+
```
47
+
git pull upstream develop
48
+
```
49
+
50
+
3. Create a new branch in your forked repository
51
+
52
+
```
53
+
git checkout -b <my-branch> develop
54
+
```
55
+
56
+
⚠️**Note:** For clarity, please name `<my-branch>` as "update-xxx" or "fix-xxx". For instance, you can use names like "update-readme" or "fix-typo-on-contribution-md" as examples.
57
+
58
+
4. In your text editor, Select the file related to the issue you want to fix, and make your changes.
59
+
60
+
⚠️**Note:** To contribute to a documentation, you would need to have Markdown knowledge. Visit [here](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax) to read about GitHub Markdown and [here](https://www.markdowntutorial.com/) to practice.
61
+
62
+
5. Commit your changes with a descriptive commit message [using conventional commits](https://www.conventionalcommits.org/en/v1.0.0/).
63
+
64
+
#### We highly encourage the use of conventional commits. Here are some examples:
65
+
66
+
-**feat:** Use this when introducing a new feature.
67
+
-**fix:** Use this when resolving any issues in the codebase.
68
+
-**chore:** Use this when adding new links/resources or making minor changes.
69
+
(e.g, `chore: Add database credentials`)
70
+
- Please ensure that your **commit messages are concise and clear**.
71
+
- Write commit messages in the **present tense**, as they reflect the current state of the codebase after the changes have been applied.
72
+
<br/>
73
+
74
+
6. Push your branch to GitHub
75
+
76
+
```
77
+
git push origin <my-branch>
78
+
```
79
+
80
+
7.[Open a Pull Request](https://help.github.com/articles/using-pull-requests/) with a clear title and description matching the issue you fixed.
81
+
82
+
⚠️**Note:** To ensure a smoother review process, kindly use the following format for the Pull Request title:`[chore]`, `[feat]`, or `[fix]`, followed by a descriptive title.
83
+
84
+
For instace, a feat-related change could have a title like `[feat] setup pasword reset`. This helps us categorize and understand the nature of the changes made in each PR.
85
+
86
+
- Link the issue you have resolved in the Pull Request Template using the following syntax:
87
+
- If your Pull Request fixes issue #25, add `Fixes #25` to the description.
88
+
- If your Pull Request addresses multiple issues, list them using the same syntax (`Fixes #23, Fixes #15`) however, we'll advise you create seperate PRs for each.
89
+
<br/>
90
+
This helps us track and automatically close the relevant issue when your Pull Request is merged.
91
+
92
+
## Contribution Etiquettes
93
+
94
+
- When you pick an issue to fix, we recommended that you review the comment thread first to check if someone is already working on it. In case no one has claimed it yet, kindly leave a comment stating your intention to work on it. This way, others will be aware, and we can avoid accidental duplication of effort.
95
+
96
+
- If someone has shown interest in fixing an issue but doesn't follow up for a specific period, let's say 2-3 weeks, it's permissible to pick up the same issue later. However, please ensure that you leave a comment to inform others of your intention before proceeding.
97
+
98
+
#### Thank you for reading the guide. We look forward to merging your contributions.
0 commit comments