Update guidelines

Update names section
Remove required documentation section (see https://github.com/HangarMC/Hangar/issues/631)
Update monetization section (still in contention)
Move offline-mode section to EULA section
Add Obfuscation section

frontend-new/src/pages/guidelines.vue

@@ -9,11 +9,8 @@ import Markdown from "~/components/Markdown.vue";
 const i18n = useI18n();
 const route = useRoute();
 
-// TODO Discuss and write proper guideliness, move to docs site
+// TODO Discuss and write proper guideliness, move to docs site, remove table
 const text = `
-Welcome to the Hanagr resource guidelines. This document provides an outline of our expectations for both project and
-file submissions.
-
 Remember that these are just guidelines and that the Hangar team may choose to allow or disallow an action that is not
 explicitly listed here at our own discretion.
 
@@ -22,81 +19,78 @@ Hangar. The same applies to (international) law.
 
 ## Project Name
 
-Your project's name should not include a tagline or other description. The name should be unique and original and must
-not have a name implying it is an official PaperMC project.
+Your project's name should not include a platform version, tagline or other description. The name should be unique and
+original and must not have a name implying it is an official PaperMC project. Large projects may receive a verified
+status, but this is decided on a case-by-case basis and will not be given on request.
 
-Examples of project names that are **not acceptable**:
+Examples of project names that are **not allowed**:
 
-- *Warps-On-Sale*
 - *Home--The-Best-Plugin-Out-There*
 - *PaperDocs*
+- *Chairs-1.19*
 
-Examples of names that are **acceptable**:
+Examples of names that are **allowed**:
 
-- *CoolWarps-Paper*
-- *Calendar-for-Sponge*
-
-## Main Documentation Page (Home)
-
-If your project sends information (for example a plugin list or player data) to you or another service and these metrics
-cannot be turned off, the information collected must be listed on the main page. This also applies to plugins
-downloading executable files (\`.jar\` files, \`.exe\` files, etc.).
-
-Examples of systems that require documentation if they do not have an opt-out:
-
-- Plugin auto-updaters
-- Statistics or usage information collection (metrics)
-- IRC/Discord/Telegram/WhatsApp bot or relay
-
-Examples of systems that do **not** require documentation:
-
-- Local databases or database connections specified by the end-user
-- Metrics with an option to disable them (like bStats)
-- File downloads that are very intentionally initiated by the user, for example via a command
+- *Warps-Reborn*
+- *Warps2*
+- *CoolWarps-Paper* (although per-platform releases can be done in a single project)
 
 ## Project Category
 
-The category you choose should be accurate. Your project should use the narrowest category possible rather than any
-category that slightly applies. If no category appears accurate, the Miscellaneous category should be used.
+The category you choose should be accurate. Your project should use the most fitting category rather than any category
+that only slightly applies. If no category appears accurate, the Miscellaneous category should be used.
 
 ## Monetization / Advertising
 
-Resources may not be sold, nor may additional features be unlockable with payment. Advertisements and other revenue
-generating links (e.g. adfly) are not permitted. You can, however, set donation links in the project's settings and use
-that as a basis for exclusively paid support, for example.
+Additional features or addons may not be hidden behind a paywall; this includes directly linking to off-site addons or "
+full" versions of a "lite" plugin version. Advertisements and other revenue generating links (e.g. adfly) are not
+permitted.
 
 All functionality present in your plugin should be usable without restriction and cannot require a license key to
 operate. Plugins may not be used to display advertisements.
 
-## Offline-mode Support
+On the resource page, you may link to the following:
 
-Projects that explicitly state they are designed for such uses are not allowed. Some projects, such as authentication
-systems, may have functionality that can be useful for servers regardless of the server’s use of Mojang authentication,
-but they may not promote this additional usage or be specifically designed for servers avoiding Mojang auth. Projects
-designed for proxies requiring online-mode=false are allowed, provided they are not written to facilitate circumvention
-of Minecraft account ownership.
+* Related resources, such as projects you took inspiration from, dependencies, and *free* versions of the same resource
+  on other websites
+* Related documents, such as documentation, tutorials, source code, and support Discords, including paid support
+* Donation links - you can also go to your project's donation settings to display them more prominently
+* Paid subscription services (such as Patreon) to receive early previews of upcoming, free releases
+
+
+## Obfuscation
+To circumvent license issues and the effort involved in reviewing obfuscated code, we do not allow submitted plugins to be obfuscated in any capacity.
 
 ## EULA
 
 We aim to comply with the [Minecraft EULA](https://account.mojang.com/documents/minecraft_eula). Any plugins, services,
 posts, and/or links suspected of violating the EULA may be removed at the discretion of the Hangar staff.
 
+### Offline-mode Support
+
+Projects that explicitly state they are designed for such uses are not allowed. Some projects, such as authentication
+systems, may have functionality that can be useful for servers regardless of the server's use of Mojang authentication,
+but they may not promote this additional usage or be specifically designed for servers avoiding Mojang auth. Projects
+designed for proxies requiring \`offline-mode=false\` are allowed, provided they are not written to facilitate
+circumvention of Minecraft account ownership.
+
 ## Forks of Exisiting Projects
 
-Forks are permitted, provided they meet all items in the below list. Staff have the final say in what constitutes an
-accepted fork. You must also follow the license of the parent project appropriately.
+You are not allowed to re-upload resources of other authors as-is. Forks are permitted as long as they meet the
+requirements as stated below. Staff have the final say in what constitutes an accepted fork. You must also follow the
+license of the parent project appropriately.
 
-Either:
+Your project must either:
 
 - Contain significant changes warranting the creation of a new project. This is to avoid "I changed the message colors
   in Plugin X and now I claim credit!", or
-- Continue a plugin that has been abandoned, with proof the author has not been answering messages or has stated the
+- Continue a plugin that has been abandoned, with the author no longer answering messages or having stated that the
   project will no longer be updated.
 
-Acknowledge or credit the past plugin and developers. Essentially, do not claim it is a new plugin and exclusively your
-creation.
+You have to acknowledge or credit the past plugin and developers. Essentially, do not claim it is a new plugin and
+exclusively your creation.
 
-## Privilege Granting and Malicious Actions
+## Malicious Code
 
 Plugins must not grant or revoke feature access to any particular user or group of users determined by the plugin
 developer. This includes the author granting themselves a special display name or letting themselves use a special