feature proposal section changes

src/SUMMARY.md

@@ -34,9 +34,9 @@ General Development
   - [Writing Guidebook Entries](en/general-development/tips/writing-guidebook-entries.md)
   - [Config File Reference](en/general-development/tips/config-file-reference.md)
   - [YAML Crash Course](en/general-development/tips/yaml-crash-course.md)
-  - [Feature Proposals](en/general-development/tips/proposal-guidelines.md)
-  - [Expected Team Decorum & Usage](en/general-development/tips/decorum.md)
-  - [Fundamental Design Principles](en/general-development/tips/design-principles.md)
+- [Feature Proposals](en/general-development/feature-proposals.md)
+  - [Expected Team Decorum & Usage](en/general-development/feature-proposals/expected-feature-proposal-decorum.md)
+  - [Fundamental Design Principles](en/general-development/feature-proposals/ss14-fundamental-design-principles.md)
 
 
 SS14 By Example

src/en/general-development/codebase-info/pull-request-guidelines.md

@@ -13,7 +13,7 @@ Following these guidelines will make contributing much easier, and will help you
 - If you move a file to a different folder and/or namespace, put that in its own commit when possible to make it easier to tell what got changed in a file and what was just moved.
 - Please have some familiarity with [C# conventions](https://docs.microsoft.com/en-us/dotnet/csharp/) (if working with C#) and [our own conventions](./conventions.md). Try to read how other parts of the codebase are formatted for a general idea.
 - Try to split your PR into smaller ones where it makes sense to do so. This makes it significantly easier to read and can lead to faster reviews. It's also usually easier for you, and means you will receive earlier feedback and can avoid spending time making changes that have to be reworked.
-- Large new features and comprehensive reworks to existing large features (ie antags or anything that could be considered a subdepartment unto itself), should first be [proposed and accepted in abstract](../tips/proposal-guidelines.md) before you start working on actually implementing it.
+- Large new features and comprehensive reworks to existing large features (ie antags or anything that could be considered a subdepartment unto itself), should first be [proposed and accepted in abstract](../feature-proposals.md) before you start working on actually implementing it.
 - Avoid force-pushing to your branch. This makes all reviews show as 'outdated', even if they have not been addressed yet, which makes it much harder for us.
 - When you're addressing reviews, click 'Resolve conversation' on GitHub once your revised code has been pushed.
 - If you have questions about reviews that were submitted on your PR (or code questions in general, of course), feel free to ask for clarification on GitHub or Discord in #howdoicode.

src/en/general-development/tips/proposal-guidelines.md → src/en/general-development/feature-proposals.md

@@ -1,10 +1,10 @@
-# So you want to X where X is large
+# Feature Proposals
 
 If you are considering adding or reworking some major component of the game it's recommended that you submit a proposal before you actually start coding whatever it is you want to do. Pinning down exactly how your feature should work to mesh well with the rest of the game will save you a lot of headaches rewriting your PR for the ~~1st2nd4th~~ 7th time before it gets merged.
 
 ## How do I make a proposal?
 
-Just follow [our guide](../../meta/guide-to-editing-docs.md) on editing any part of this site and PR your proposal as a page under the "Design Proposals" section found in the sidebar between "Space Station 14" and "Server Hosting".
+Just follow [our guide](../meta/guide-to-editing-docs.md) on editing any part of this site and PR your proposal as a page under the "Design Proposals" section found in the sidebar between "Space Station 14" and "Server Hosting".
 
 Proposals that get approved by a maintainer will be merged to this site, which is basically the green light for you or someone else to go ahead and implement it.
 
@@ -40,7 +40,7 @@ A good rule of thumb if the new feature or rework you have in mind would require
 No idea! What design proposals do or do not get in is determined by maintainer approval like normal PRs. If you can get at least one maint to decide that it sounds like a good idea then there's a good chance that it will get accepted. Pretty much any idea is going to need at least some critiquing before it gets merged so don't get discouraged!
 
 ``` admonish tip "Design Principles"
-If you want to improve your chances, it's recommended that you read the [SS14 Fundamental Design Principles](./design-principles.md) document to get a high-level overview before you start writing, as it'll provide context for why things are the way they are.
+If you want to improve your chances, it's recommended that you read the [SS14 Fundamental Design Principles](./feature-proposals/ss14-fundamental-design-principles.md) document to get a high-level overview before you start writing, as it'll provide context for why things are the way they are.
 
-PR'd design documents should also follow the [Decorum Guidelines](./decorum.md).
+PR'd design documents should also follow the [Decorum Guidelines](./feature-proposals/expected-feature-proposal-decorum.md).
 ```

src/en/general-development/tips/decorum.md → src/en/general-development/feature-proposals/expected-feature-proposal-decorum.md

@@ -1,14 +1,15 @@
-Expected Team Decorum & Usage
-=============================
+# Expected Feature Proposal Decorum
+
+{{#template ../../templates/wip.md}}
 
 - No half-baked stuff or scratchbooks or anything like that. Only fully-formed documents.
 - If you’re the main author of something, put your name in the title in brackets. Otherwise, note all of the authors and designers in italics under the main header. The primary designers take priority over the author of a document.
-- Documents should note if a maintainer has approved it or not in the title in brackets along with the name if one exists. i.e. [mirrorcult, Approved] or [mirrorcult, Unapproved]
 - Not everything here is gospel, or going to be implemented into SS14. If a document is authored by a maintainer or signed off by one, it can be treated as a source of truth.
 
-Any documents posted:
+Any documents proposed:
 
-- Should conform to the basic [SS14 Game Design Principles](./design-principles.md) as well as this document obviously.
+- Should conform to the basic [SS14 Game Design Principles](./ss14-fundamental-design-principles.md) as well as this document obviously.
 - Should contain sufficient justification for their existence,
-- Can be removed by consensus or at admin discretion.
+- Can be closed or drafted at maintainer discretion,
 - Are a reflection of SS14 to others that may be interested in how the game is designed. Take note of that.
+p

src/en/general-development/tips/design-principles.md → src/en/general-development/feature-proposals/ss14-fundamental-design-principles.md

@@ -1,5 +1,7 @@
 # SS14 Fundamental Design Principles
 
+{{#template ../../templates/wip.md}}
+
 The purpose of this document is to outline the basics of how Space Station 14 upstream design is approached, taking into consideration its status as a greenfield project and taking care to build a foundation for the future fork ecosystem.
 
 ## Social Gameplay
@@ -14,20 +16,8 @@ Parts of a whole gameplay loop or mechanic may be achievable by a single player.
 
 An addendum to this principle is that, if a mechanic involves perceived NPCs or AI mobs, you should always try to find ways to put real humans in their place. For example, offering ghost roles to hostile mobs, or crafting an economy system that is player-motivated rather than externally-motivated.
 
-Negative examples of this principle in Space Station 13:
-
-- Lavaland mining
-- Virology
-
-Positive examples of this principle in Space Station 14:
-
-- Diseases
-- Salvage
-
 ## Intuitive Simulation
 
-Space Station 13/14
-
 ## Discoverable Interactions
 
 ## Systems-based Design