|
1 | 1 | How to Contribute |
2 | 2 | ================================================== |
3 | 3 |
|
4 | | -Do you want to contribute to the Hestia Control Panel project? The easiest way to get started is to [submit an issue report](https://github.com/hestiacp/hestia/issues) if you come across a bug or issue. If you're a developer, please feel free to submit a patch/pull request with a fix. |
| 4 | +Do you want to contribute to the Hestia Control Panel project? The easiest way to get started is to [submit an issue report](https://github.com/hestiacp/hestia/issues) if you come across a bug or issue. If you are a developer, please feel free to submit your code via pull request for review. |
5 | 5 |
|
6 | | -**We appreciate all contributions to our project; it is with the help of the open-source community that we are able to build a product that meets users needs.** |
| 6 | +**We appreciate and welcome all contributions to our project; it is with the help of the open-source community that we are able to build a product that meets our users needs.** |
7 | 7 |
|
8 | 8 | Code Contributions & Pull Requests - Guidelines |
9 | 9 | ----------------------- |
10 | 10 |
|
11 | 11 | **All pull requests must include:** |
12 | | -1. A brief but descriptive title, such as **Fixed typo in php.ini** or **Updated rebuild_mail_conf function in rebuild.sh**. |
| 12 | +1. A brief but descriptive title, such as **Fixed syntax error in php.ini** or **Updated rebuild_mail_conf function in rebuild.sh**. |
13 | 13 | 2. A detailed description of the changes that you've made. |
14 | 14 | 1. Example: "Apache subdomain configuration was incorrect, modified variables in templates to point to the correct files." |
15 | 15 | 3. Only commits which are related to the pull request or issue itself. |
16 | 16 |
|
17 | 17 | ### Code formatting and comments: |
18 | | -We ask that you try to follow existing naming schemes and coding conventions as much as possible, and that you please add brief but descriptive comments in your source code to aid other developers in debugging and understanding your code in the future. |
| 18 | +We ask that you please try to follow existing naming schemes and coding conventions as much as possible, and that you add brief but descriptive comments in your source code to aid other developers in debugging and understanding your code in the future. |
19 | 19 |
|
20 | 20 | ### Squashing commits for smaller changes: |
21 | | -When submitting a pull request with multiple smaller commits which are related to the same issue (or file), we ask that you please **squash your commits** in order to keep the project's commit history clean and easy to follow for other developers. |
22 | | - |
| 21 | +When submitting a pull request with multiple smaller commits which are related to the same issue (or file), we ask that you please **squash your commits** in order to keep the project's commit history clean and easy to follow for other developers. For example, if you are submitting a fix for two files which contain the same code change, merge those changes into one commit before submitting your request. |
23 | 22 |
|
24 | 23 | ### Working with branches: |
25 | | -Development for this project takes place in branches to effectively develop, manage, and test manage new features and code changes, ensuring that that each release meets high quality standards. Our primary branches are as follows: |
| 24 | +Development for this project takes place in branches to effectively develop, manage, and test new features and code changes, helping to ensure that each release meets high quality standards. Our primary branches are as follows: |
26 | 25 |
|
27 | 26 | * **master**: Active development code for the the next version of Hestia Control Panel. |
28 | | -* **prerelease**: The next release of Hestia Control Panel which is undergoing testing and quality refinement. |
29 | 27 | * **release**: The latest stable release code - installation packages generally align with this branch. |
30 | 28 |
|
31 | | -We ask that you create a new branch for your work based on **master** or **prerelease**, depending on the code you are contributing. By doing this, you can submit a pull request with only the necessary commits. Please follow the below naming conventions for your work and submit a pull request when it has been completed. Once reviewed and approved, our development team will merge your code into the primary development branch. |
| 29 | +We ask that you create a new branch for your work based on **master**, this will allow you to submit only the necessary commits/changes that you've made. We generally adhere to the below naming convention for internal branches; you're welcome to use your own naming conventions so long as your commits follow the guidelines mentioned above. |
32 | 30 |
|
33 | | -* **feature/area/name-of-feature**: New features |
34 | | -* **hotfix/000**: Critical security or bug fixes |
35 | | -* **bugfix/000**: Non-critical bug fixes |
| 31 | +* **feature-name**: New features |
| 32 | +* **bugfix-000**: Bug fixes |
36 | 33 |
|
37 | | -**Note**: Replace **area** with Web, DNS, Mail, etc. Replace **000** with the GitHub Issue ID if available, or use a short but descriptive name. |
| 34 | +**Note**: Replace **000** with the GitHub Issue ID if available, or use a short but descriptive name. |
38 | 35 |
|
39 | 36 | ### Feature freeze: |
40 | | -The general flow of our development process is that new features or work begin in a new branch derived from **master**. Once the work has been completed and reviewed, it is then submitted via Pull Request for further review and inclusion into the main code base. Once a release has reached a point where slated new features have been incorporated and the build has gone through testing and validation, it will then enter a "feature freeze" state where only fixes to the existing functionality will be merged for inclusion and be pushed to the **prerelease** branch. Once any remaining known issues have been resolved and the build is considered stable, the code is then pushed to **release** and the cycle starts all over again. |
41 | | - |
42 | | -**master** -> **prerelease** -> **release** |
| 37 | +Once development has reached a point where all planned new features have been incorporated, the **master** branch will then enter a "feature freeze" period where only fixes to the existing functionality will be added or merged for inclusion. Once any known issues have been resolved and the build has passed internal validation and testing procedures, it will then be pushed to **release** and tagged with it's respective version number and made available through our APT repositories. |
43 | 38 |
|
44 | 39 | **Please ensure that all pull requests meet the guidelines listed above; those that do not will be rejected and sent back for review.** |
45 | 40 |
|
|
0 commit comments