|
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