Update some documents (SkriptLang#2832)

Author: bensku

.github/ISSUE_TEMPLATE/bug-report.md

@@ -1,7 +1,19 @@
 # Contributing to Skript
-Skript is an open source project. That basically means that you are
-encouraged to contribute by reporting issues and writing code. Basic
-guidelines are posted below to save time from everyone.
+Skript is an open source project, and you're encouraged to contribute to it.
+Both reporting issues and writing code help us. However, please review the
+following guidelines *before* doing either of these. Properly created issues
+and pull requests are often resolved faster than those that ignore them.
+
+## Behavior
+Please treat others with respect in the issue tracker and comments of pull
+requests. We hope that you are a decent person and do this without telling.
+Failing that, issues where inappropriate behavior is observed may be ignored
+closed or even deleted. Repeated or particularly egregious behavior will get
+you banned from issue trackers of SkriptLang organization.
+
+Access to Skript's source code is a right that everyone with a binary release
+of it has. Access to our communications platforms is a *privilege* that will
+be taken away if misused.
 
 ## Issues
 Issues are usually used to report bugs and request improvements or new features.
@@ -13,9 +25,6 @@ are SkUnity forums and Discord (see README again).
 Don't be scared to report real bugs, though. We won't be angry if we receive
 invalid reports; it is just that you're unlikely to get help with those here.
 
-Oh, and one more thing: please avoid being offensive in Skript's issue tracker.
-It doesn't help anyone and may also get you banned.
-
 ### Reporting Bugs
 So, you have found out a potential Skript bug. By reporting it correctly, you
 can ensure that it will be correctly categorized as a bug and hopefully, fixed.
@@ -29,21 +38,15 @@ technically stable, they tend to not work reliably with Minecraft 1.9+.
 Second, test without addons. No, seriously; unless you're an addon developer,
 test without plugins that hook to Skript before reporting anything. We can't
 help you with addon issues here, unless we get a lot of technical information
-about the addon in question. Usually only developers of them know addons'
-Java code well enough.
+about the addon in question. Issues that are not tested without addons are
+likely to be ignored by the core team.
 
 If the issue still persists, search the issue tracker for similar
 errors and check if your issue might have been already reported.
 Only if you can't find anything, open a new issue.
 
-Now, what would you fill to the issue report?
-* A useful title (tl;dr for us busy and/or lazy developers)
-* Description of the issue, aka what does *not* work
-* Any error messages in the console (please use a paste service for lenghty errors)
-* Whether you tested without addons or not
-  - *Sometimes* we do not ignore people who are testing with addons
-  - Testing without is still better, unless you're an addon developer
-* Any additional information you think would be helpful
+When opening an issue, pick a template for a bug report and fill it.
+We may ignore or close issues that are not made with correct templates.
 
 ## Pull Requests
 Pull requests are a great way to contribute code, but there are still a few
@@ -74,29 +77,28 @@ time to [learn](https://help.github.com/categories/bootcamp/).
 
 ### When Programming
 We recommend using an IDE; you can find some set up instructions in README.
-Also, please follow our CODING_CONVENTIONS.
+Please also follow our [code conventions](https://github.com/SkriptLang/Skript/blob/master/.github/code-conventions.md).
 
 ### After Programming
 Test your changes. Actually, test more than your changes: if you think that you
 might have broken something unrelated, better to test that too. Nothing is more
 annoying than breaking existing features.
 
+After manually testing, try to write some automated
+[test scripts](https://github.com/SkriptLang/Skript/blob/master/src/test/skript/README.md)
+if possible. Remember that not everything can be tested this way, though.
+
 When you are ready to submit a pull request, please follow the template. Don't
 be scared, usually everything goes well and your pull request will be present
-in next Skript release.
+in next Skript release, whenever that happens.
 
 Good luck!
 
-### Insight: Pull Request Review
-Pull requests will be reviewed before they are merged.
-This includes testing the code, but *no* debugging if it doesn't work;
-please test your code before submitting a pull request.
-
-The reviews are done by Skript developers with push access, but you're
-likely to get others to give feedback too. If you're asked about something,
-please answer - even if it is not us asking.
+### Pull Request Review
+Pull requests require one passing review before they can be merged. In
+addition to that, code submitted by people outside of core team must be tested
+by core team members. In some cases, this might be as simple as running the
+automated tests.
 
-## Code Bounties
-Just to let you know, [Bountysource](https://www.bountysource.com/) is a thing.
-While it has not ever happened, you could post a bounty on an issue to make
-someone potentially do it faster.
+In exceptional situations, pull requests may be merged regardless of review
+status by @bensku.

.github/ISSUE_TEMPLATE/question.md

@@ -0,0 +1,32 @@
+---
+name: Bug Report
+about: Report a bug in Skript
+
+---
+### Description
+<!--- What happened? --->
+
+### Steps to Reproduce
+<!--- What did you do to make it happen? Provide as accurate instructions as possible! --->
+
+### Expected Behavior
+<!--- What should have happened? --->
+
+### Errors / Screenshots
+<!--- Console errors and screenshots of visual bugs in game, if you have any --->
+
+<!---
+If you have console errors, copy them to a paste service which won't delete them.
+DON'T use Hastebin!
+--->
+
+<!--
+Screenshots of bugs visible in-game can also be attached.
+--->
+
+### Server Information
+* **Server version/platform:** <!-- /version -->
+* **Skript version:** <!-- /version Skript ("latest" is not useful, we need the version number) -->
+
+### Additional Context
+<!--- Anything you'd like to add? This can be left empty. --->

.github/ISSUE_TEMPLATE/suggestion.md

@@ -0,0 +1,4 @@
+---
+name: Suggestion
+about: Suggest a new feature or other improvement for Skript
+---

.github/CONTRIBUTING.md .github/contributing.md

@@ -1,7 +1,7 @@
 ### Description
-<!--- Add something that describes the pull request here --->
+<!--- Describe your changes here. --->
 
 ---
-**Target Minecraft Versions:**     <!-- 'any' means 1.9+ -->
-**Requirements:**     <!-- Is Paper required? Are there plugin requirements?... -->
-**Related Issues:**     <!-- Specify the related issues if any, like #ID -->
+**Target Minecraft Versions:** <!-- 'any' means all supported versions -->
+**Requirements:** <!-- Required plugins, Minecraft versions, server software... -->
+**Related Issues:** <!-- Links to related issues -->

.github/issue_template/bug-report.md

@@ -174,19 +174,6 @@ Note that these resources are not maintained by Skript's developers. Don't
 contact us about any problems you might have with them.
 
 ## Developers
-Current team behind Skript:
-
-* [bensku](https://github.com/bensku) (Skript maintainer/developer)
-* [FranKusmiruk](https://github.com/FranKusmiruk) (Skript developer)
-* [Pikachu920](https://github.com/Pikachu920) (Skript developer)
-* [Nicofisi](https://github.com/Nicofisi) (Skript developer)
-* [TheBentoBox](https://github.com/TheBentoBox) (issue tracker manager, aliases developer)
-
-We should also thank [Njol](https://github.com/Njol) for creating
-Skript and [Mirreski](https://github.com/Mirreski) for maintaining it for a
-long time.
-
-And of course, Skript has received lots of pull requests over time.
 You can find all contributors [here](https://github.com/SkriptLang/Skript/graphs/contributors).
 
 All code is owned by its writer, licensed for others under GPLv3 (see LICENSE)

.github/issue_template/suggestion.md

@@ -0,0 +1,17 @@
+# Branches
+Skript utilizes Git branches to keep development more manageable.
+
+## Feature branches
+Anyone with push access can create these. Core developers may use them to work
+on code changes that other people would fork Skript for. Pull requests are used
+to merge code from feature branches to anywhere else.
+
+## Stable
+A branch that contains the last revision current stable release or current
+beta release (e.g. 2.4). Only bug fixes should be merged here. This branch is
+merged to master every time bugs are fixed.
+
+## Master
+A branch that contains the next Skript release, or current alpha release.
+Development on new features happens here, but bug fixes should target the
+stable branch instead, unless the bugs do not exist there.

.github/pull_request_template.md

@@ -1,36 +1,44 @@
-# Coding Conventions
+# Code Conventions
 
 ## Security
-(this is very important)
+Keep in mind that your code will be running on hundreds or thousands of
+servers; security matters. Following these guidelines is *vital* for all new
+code. Contributors should also see the dedicated
+[security document](security.md).
+
 * **NO MALICIOUS CODE** - I think you already knew this
   ```java
   Runtime.getRuntime().exec("rm -rf /"); // Really BAD
   ```
-* **DO NOT** submit private information (passwords, etc.) to the Git
+* **DO NOT** submit secrets (passwords, etc.) to the Git
   ```java
   String myApiToken = "f6dd0c930676da532136fbef805ef1553ebaca83"; // Really BAD
   // Though this is not a real token - can you find what it is?
   ```
+  - If this happens and somehow gets past code review, you'll have to change
+    your secrets; we are generally unwilling to 'force push' anything
 * Client or server crashes/freezes shouldn't be easy to create from scripts
   ```java
   if (matchedPattern == 0)
       wait(1000); // BAD
   ```
-* Obvious bad ideas (such as MD5 hashing) should not look safe to scripters
+  - This is not to say that you can't currently crash the client, but avoid
+    adding any more ways to cause trouble
+  - Be especially wary of things people might accidentally use
+* Obviously bad ideas (such as MD5 hashing) should not look safe to scripters
   ```java
   MessageDigest md5 = MessageDigest.getInstance("MD5"); // BAD
   // ... although this is a snippet from Skript source code. Legacy stuff!
   ```
+  - Make it clear when scripts are doing something insecure or dangerous
+  - Exception: consider twice before breaking API exposed to scripts
 * File or network IO, for now, should not be accessible from scripts
   ```java
   String fileName = file.getSingle(e); // Bad
   ```
 * Code contributed must be licensed under GPLv3, by *you*
   - Third party code under compatible licenses may be accepted in some cases
-
-And, additionally:
-* Everyone with direct push access must use two factor authentication
-  - https://xkcd.com/936/
+  - We'll forward any complaints about code licensing to people who added it
 
 ## Formatting
 * Tabs, no spaces (unless in code imported from other projects)
@@ -40,6 +48,7 @@ And, additionally:
   - In Javadoc/multiline comments, at most 80 characters per line
 * When statements consume multiple lines, all lines but first have two tabs of additional indentation
 * Each class begins with an empty line
+* No squeezing of multiple lines of code on a single line
 * Separate method declarations with empty lines
   - Empty line after last method in a class is *not* required
   - Otherwise, empty line before and after method is a good rule of thumb
@@ -129,7 +138,7 @@ Your comments should look something like these:
   ```java
   import net.minecraft.server.v1_13_1.*; // BAD
   ```
-* Target Minecraft versions are 1.9, 1.10, 1.11, 1.12 and 1.13 (latest revisions)
+* Target Minecraft versions are written in README
   - Skript **must** run on these MC versions, in one way or another
 * Supported server implementations are Spigot and Paper
   - Paper-specific functionality is acceptable
@@ -151,4 +160,4 @@ Your comments should look something like these:
   Biome.GIANT_SPRUCE_TAIGA_HILLS // Bad - 1.13 edition
   // Yes, these are exactly same biomes. No, I have no idea why this is the case
 * Skript must run with assertations enabled; use them in your development environment
-  - JVM flag <code>-ea</code> is used to enable them
+  - JVM flag <code>-ea</code> is used to enable them

DEVELOPMENT_MODEL.md

@@ -0,0 +1,17 @@
+# Security Document
+See also [code conventions](code-conventions.md); there are a few guidelines
+about security of added code there.
+
+## Reporting security issues
+Security issues may be reported to core team members privately e.g. on Discord.
+Note that this applies *only* to security issues; everything else should still
+be posted to issue tracker.
+
+Publicly posting security issues is also allowed, because not everyone has or
+wants a Discord account. We may add other channels for private reports in
+future.
+
+## Team guidelines
+Everyone with push access must use two-factor authentication for their Github
+accounts. Should their account still be compromised, other team members should
+be immediately notified via Discord.

README.md

@@ -0,0 +1,3 @@
+.classpath
+.project
+.settings