-
Notifications
You must be signed in to change notification settings - Fork 199
NTstation13 Policy
The Mission of NT Station is to be an open codebase that is developed by, and for the players of /tg/station.
To ensure that everyone is on the right page in regards to how things are run, this document will serve to define everything about NT Station and how it works.
https://github.com/NTStation/NTstation13/wiki/Code-Standards
What is NT Station
What is . . .
The Project
Contributors
Maintainers
Players
The Forums
Artyom
#Nanobus
Making a Pull Request
Making a Poll
Changing the Policy
NT Station is a codebase that was made to be open to it’s players. It is currently being ran on the /tg/station server Artyom. Anyone can contribute to it at any time as long as it meets the code standards and community input is positive.
NT Station was originally created by PolymorphBlue, intended to be a ‘everyone has commit’ codebase. However, Poly left the project and it was picked up by Miggles and Danno to be what is now NT Station. The policies have changed to try to achieve a balance of quality control and openness, transparency, and freedom for players.
The current maintainers for NT Station are Miggles, and RemieRichards.
An open source fork for the game Space Station 13.
Designed to be ran to the benefit of Players,
Hosted on Github here..
Open to be modified, forked, changed, etc, by anyone.
Ran on the /tg/server Artyom.
Anyone who submits a Pull Request to the Project, or
Anyone who submits a Bug Report to the Project, or
Anyone who takes part in discussion on the game, in #Nanobus or on the Forums.
Equal to Players and Maintainers.
Able to have their code merged into the Project if,
- The code fails to compile,
- The code causes a Runtime error,
- The code introduces serious bugs, or other issues as defined in the Coding Standards document,
- The code fails to achieve a majority vote on the Forums (Note that a minor change does not require a poll)
Attempt to sneak in undocumented code to the detriment of the Project or the Players.
Cause drama, in #Nanobus, Ingame, the Forums, or anywhere else.
Mislead Players in order to further their goals.
Act in the best interests of the Players.
Create a Poll in the relevant forum when making a major, or controversial change.
The Poll should contain the following options: Approve, Require Revision, Reject, Abstain.
The Pull Request and the Poll should not try to mislead players, and should try to be as unbiased as possible.
Anyone who has the power to merge a Pull Request to the Project’s source code.
Equal to Contributors and Players.
Allowed to merge their own code,
- Exception: To fix/revert code that causes critical bugs (e.g. server crashing)
Allowed to veto a Pull Request if it meets the Coding Standards,
Anyone who plays on the /tg/ server Artyom,
The most important thing to the Project.
Equal to Contributors and Maintainers.
Able to contribute by making Pull Requests, Bug Reports, and such anytime.
Allowed to cause drama.
Make their voice heard by voting in Polls on the Forums and taking part in discussion.
Here
A place where Players can discuss the game.
Run by the same people that run NT Station.
A server that runs NT station code,hosted by scaredofshadows for the /tg/station community.
Run by the same people that run NT Station.
An IRC channel where Contributors and Players discuss various things about the game, and possibly other things.
A place you can ask for help in, talk about code, or just to talk to other people.
A place to incite drama.
This isn’t a tutorial on how to make a pull request. Rather, it’s about how the process works with NT’s policies. If you need help making a PR you can read this or ask in #Nanobus. Note that that wiki page was written for /tg/station / coderbus’s github page.
A simplified list of how it works can be seen like this,
- You code something and it works properly.
- You TEST YOUR CODE.
2.1 If your code produces a runtime, compile error, or introduces a serious bug, fix it then repeat 2.
3 You put up a Pull Request
4 (if it’s a major/controversial change) You put up a Poll
4.1 If the Poll passes, continue to 5.
4.2 If it fails, revise and try again. - A maintainer will check to see if the code is good and it meets standards.
5.1 If it doesn’t, you will be told what’s wrong and be asked to fix it.
5.2 If it does pass, continue to 6. - It gets in!
For changes which require feedback, the public will vote on it with a poll. In addition, feedback from forum posts, github comments, and discussion in #Nanobus will also be considered. Maintainers are not allowed to deny a pull request that passes code standards and community input. They ARE allowed to vote in polls.
A waiting period of 4 days is required for all changes that require feedback. Bugfixes, changelogs, and minor changes may be pulled earlier than 4 days.
When your Pull Request is making a major change, or if the change may be controversial, a Poll is required to be made here on the Forums.. The Poll must be clear and not misleading.
The Poll should have the following options,
- Approve
- Require Revision
- Reject
- Abstain
The Poll must run for four days minimum.
If a poll ends indecisively, either with a perfect tie or an outcome close to a tie, feedback is not decisive enough to decide, and the maintainers have not come to a decision whether to pull it or not, the pull will be closed until a later date, at which point it can be repolled.
The time for this is not set in stone, but generally before repolling, the contributor should take into account the feedback which led to it being closed; both that of the people in favor of the change and the ones opposing it, and why.
Polls that are deemed very controversial will also require an in-game poll and much deliberation from contributors and the community before being accepted.
Note that you are unable to make an in-game poll, as none of the Project Personnel can, only the server host can, so we need to ask them to make one (meaning it might take a bit).
Even if your pull request does not require a poll or feedback thread, it would be polite of you to make one anyways. This is just a suggestion, however.
If you, or anyone else wishes to add a change to the policy, this is how you do it.
Write up a draft with that you want changed, on a document, forum post, or whatever is most convenient for you and can be shared with other people easily.
(Recommended) Share your draft with other people and gather opinions, revise as needed, etc.
When you feel it’s ready to be presented, make a forum poll. This is mostly like a normal poll for making a PR, however, the main differences are,
- The poll must run for at least two weeks, and
- The poll must end with a supermajority voting for it (as in, you need 66% of all votes, excluding Abstain, to be Approve)
- After the poll passes, all the maintainers will have a vote between each other. A majority of maintainers must agree. The vote must be transparent, and it’s highly recommended for the maintainer to explain their stance for approving/rejecting.
- The policy is changed.
Note that very minor edits like spelling/grammar correction and updating the maintainer list doesn’t require polling.