Skip to content
CortexPE edited this page Jul 14, 2017 · 1 revision

Rules and Guidelines on Opening an Issue

This is to help the Developers figure out how to actually fix it and reduce Spam

  • Make sure that you are using the latest supported version before opening an issue.
  • Test it on a clean test server, WITHOUT PLUGINS, to see if the issue still occurs. If not then it may be a plugin issue. Please also indicate the result of such tests.
  • Search the issue tracker to check if anyone has already reported it, to avoid needlessly creating duplicate issues. Make sure you also check closed issues, as an issue you think is valid may already have been resolved.
  • If your issue is related to a plugin, do not report here, contact the plugin's original author instead.
  • Support requests are not bugs. Issues such as "How do I do this" are not bugs and will be closed. If you need help, please see here and do not misuse our issue tracker.
  • No generic titles such as "Question", "Help", "Crash Report" etc. A good issue report provides a quick summary in the title. If you just got a crash report but you don't understand it, please look for a line starting with Message. It summarizes the bug.
  • Information must be provided in the issue body, not in the title. No tags like [BUG] are allowed in the title, including [SOLVED] for solved issues.
  • To express appreciation, objection, confusion or other supported reactions on pull requests, issues or comments on them, use GitHub reactions rather than posting an individual comment with an emoji only. This helps keeping the issue/pull request conversation clean and readable.

The Drill

Rules on Opening a Pull Request (Contribution Rules)

So that, Code Style will still be the same, and to Keep Stability

  • DO NOT use the GitHub Web Editor.
  • Copy-pasted code should be Explained briefly on the PR Description. Otherwise, The PR will be closed.
  • Just like the last rule, Make sure you can explain your changes. If you can't provide a good explanation of changes, your PR may be rejected.
  • DO NOT create a pull request with commits that exist in another pull request.
  • Observe proper code formatting.
  • Use TABS and NOT SPACES.
  • Code and comments should be written in English.
  • Use descriptive commit titles.
  • Only one change per commit.
  • It is inadvisable to create pull requests with large commits. (IT'LL BE HARD TO REVIEW)
  • You may be asked to rebase your pull request.

Code Syntax:

  • Opening braces MUST go on the same line, and MUST have spaces before.
  • else if MUST be written as elseif.
  • Code MUST use tabs for indenting.
  • Long arrays MAY be split across multiple lines, where each subsequent line is indented once.
  • Files MUST use only the <?php tag.
  • Files MUST NOT have an ending ?> tag.
  • Code MUST use namespaces.
  • Strings SHOULD use the double quote " except when the single quote is required.
  • All code SHOULD have parameter and type declarations where possible.
  • Strict types SHOULD be enabled on NEW files where it is sensible to do so.

Zoidberg

We're basically doing it PMMP Style here. 😉