|
1 | 1 | # Contributing
|
2 |
| -We're glad you want to help us out and make this panel the best that it can be! We have a few simple things to follow |
3 |
| -when making changes to files and adding new features. |
4 |
| - |
5 |
| -### Development Environment |
6 |
| -Please check the [`pterodactyl/development`](https://github.com/pterodactyl/development) repository for a Vagrant & |
7 |
| -Docker setup that should run on most macOS and Linux distributions. In the event that your platform is not supported |
8 |
| -you're welcome to open a PR, or just take a look at our setup scripts to see what you'll need to successfully develop |
9 |
| -with Pterodactyl. |
10 |
| - |
11 |
| -#### Building Assets |
12 |
| -Please see [`BUILDING.md`](https://github.com/pterodactyl/panel/blob/develop/BUILDING.md) for details on how to actually |
13 |
| -build and run the development server. |
14 |
| - |
15 |
| -### Project Branches |
16 |
| -This section mainly applies to those with read/write access to our repositories, but can be helpful for others. |
17 |
| - |
18 |
| -The `develop` branch should always be in a runnable state, and not contain any major breaking features. For the most |
19 |
| -part, this means you will need to create `feature/` branches in order to add new functionality or change how things |
20 |
| -work. When making a feature branch, if it is referencing something in the issue tracker, please title the branch |
21 |
| -`feature/PTDL-###` where `###` is the issue number. |
22 |
| - |
23 |
| -All new code should contain tests to ensure their functionality is not unintentionally changed down the road. This |
24 |
| -is especially important for any API actions or authentication based controls. |
25 |
| - |
26 |
| -### The CHANGELOG |
27 |
| -You should not make any changes to the `CHANGELOG.md` file during your code updates. This is updated by the maintainers |
28 |
| -at the time of deployment to include the relevant changes that were made. |
29 |
| - |
30 |
| -### Code Guidelines |
31 |
| -We are a `PSR-4` and `PSR-0` compliant project, so please follow those guidelines at a minimum. In addition we run |
32 |
| -`php-cs-fixer` on all PRs and releases to enforce a consistent code style. The following command executed on your machine |
33 |
| -should show any areas where the code style does not line up correctly. |
34 |
| - |
35 |
| -``` |
36 |
| -vendor/bin/php-cs-fixer fix --dry-run --diff --diff-format=udiff --config .php_cs.dist |
37 |
| -``` |
| 2 | +Pterodactyl does not accept Pull Requests (PRs) _for new functionality_ from users that are not currently part of the |
| 3 | +core project team. It has become overwhelming to try and give the proper time and attention that such complicated PRs |
| 4 | +tend to require — and deserve. As a result, it is in the project's best interest to limit the scope of work on |
| 5 | +new functionality to work done within the core project team. |
| 6 | + |
| 7 | +PRs that address existing _bugs_ with a corresponding issue opened in our issue tracker will continue to be accepted |
| 8 | +and reviewed. Their scope is often signficantly more targeted, and simply improving upon existing and well defined |
| 9 | +logic. |
38 | 10 |
|
39 | 11 | ### Responsible Disclosure
|
40 | 12 | This is a fairly in-depth project and makes use of a lot of parts. We strive to keep everything as secure as possible
|
|
0 commit comments