Non-Admin Staff Conduct - Revision history

Mrmanlikesbt at 05:18, 14 March 2026

2026-03-14T05:18:03Z

← Older revision		Revision as of 05:18, 14 March 2026
Line 130:		Line 130:

	{\| class="wikitable mw-collapsible"		{\| class="wikitable mw-collapsible"
	!~~PR Vote Procedure~~		!In-Game Perms
	\|-		\|-
	\|		\|

PowerfulBacon: /* Maintainer Rules */

2025-11-26T20:40:57Z

Maintainer Rules

← Older revision		Revision as of 20:40, 26 November 2025
Line 59:		Line 59:
	#Follow and enforce the [https://github.com/BeeStation/BeeStation-Hornet/blob/master/.github/CONTRIBUTING.md code contribution guidelines].		#Follow and enforce the [https://github.com/BeeStation/BeeStation-Hornet/blob/master/.github/CONTRIBUTING.md code contribution guidelines].
	#PRs may only be closed under the following conditions:		#PRs may only be closed under the following conditions:
	#*PRs may be given 'close keys' via the github label system. A PR may be closed once it has recieved 3 keys, including your own key. '''A reason must be included when applying a close key.'''		#*PRs may be given 'close keys' via the github label system. A PR may be closed once it has recieved 2 keys, including your own key. '''A reason must be included when applying a close key.'''
	#*A PR that has had no other maintainer activity for 2 weeks may be closed 24h after pinging the maintainer role and requesting reviews for said PR, as long as the opinions from maintainers who have provided input is unanimous.		#*A PR that has had no other maintainer activity for 2 weeks may be closed 24h after pinging the maintainer role and requesting reviews for said PR, as long as the opinions from maintainers who have provided input is unanimous.
	#*The head-developer may choose to close a PR for any reason, however this reason must be clearly stated in the PR.		#*The head-developer may choose to close a PR for any reason, however this reason must be clearly stated in the PR.

PowerfulBacon: /* Maintainer-Specific Conduct */

2025-10-11T09:19:29Z

Maintainer-Specific Conduct

← Older revision		Revision as of 09:19, 11 October 2025
Line 56:		Line 56:
	\|-		\|-
	\|		\|
	#Do not disclose any information from the ops channels (#server-ops ~~and~~ #downstream-ops) without permission from the ~~persons~~ who posted it.		#Do not disclose any information from the ops channels (#server-ops, #downstream-ops, and #maintainer-discussions) without permission from the person who posted it.
	#Follow and enforce the [https://github.com/BeeStation/BeeStation-Hornet/blob/master/.github/CONTRIBUTING.md code contribution guidelines].		#Follow and enforce the [https://github.com/BeeStation/BeeStation-Hornet/blob/master/.github/CONTRIBUTING.md code contribution guidelines].
	#PRs may only be closed under the following conditions:		#PRs may only be closed under the following conditions:

PowerfulBacon: /* Maintainer-Specific Conduct */

2025-10-11T09:18:56Z

Maintainer-Specific Conduct

← Older revision		Revision as of 09:18, 11 October 2025
Line 51:		Line 51:
	== Maintainer-Specific Conduct ==		== Maintainer-Specific Conduct ==
	=== Maintainer Rules ===		=== Maintainer Rules ===
	* Do not disclose any information from the ops channels (#server-ops and #downstream-ops) without permission from the persons who posted it.
	* Follow and enforce the [https://github.com/BeeStation/BeeStation-Hornet/blob/master/.github/CONTRIBUTING.md code contribution guidelines].		{\| class="wikitable mw-collapsible"
	*PRs may only be closed under the following conditions:		!Head-Developer Key Points
	**PRs may be given 'close keys' via the github label system. A PR may be closed once it has recieved 3 keys, including your own key. '''A reason must be included when applying a close key.'''		\|-
	**A PR that has had no other maintainer activity for 2 weeks may be closed 24h after pinging the maintainer role and requesting reviews for said PR, as long as the opinions from maintainers who have provided input is unanimous.		\|
	**The head-developer may choose to close a PR for any reason, however this reason must be clearly stated in the PR.		#Do not disclose any information from the ops channels (#server-ops and #downstream-ops) without permission from the persons who posted it.
	* Acting maliciously will result in demotion.		#Follow and enforce the [https://github.com/BeeStation/BeeStation-Hornet/blob/master/.github/CONTRIBUTING.md code contribution guidelines].
	**Do not use any granted privileges for reasons other than what they are intended for.		#PRs may only be closed under the following conditions:
	*Feedback must be constructive and maintainers should not talk about other members of the development community in a way that they do not want to be talked about, this applies to developers involved with other SS13 projects. To report an issue, contact the head-developer or host via discord DMs.		#*PRs may be given 'close keys' via the github label system. A PR may be closed once it has recieved 3 keys, including your own key. '''A reason must be included when applying a close key.'''
			#*A PR that has had no other maintainer activity for 2 weeks may be closed 24h after pinging the maintainer role and requesting reviews for said PR, as long as the opinions from maintainers who have provided input is unanimous.
			#*The head-developer may choose to close a PR for any reason, however this reason must be clearly stated in the PR.
			#*Draft PRs may be closed for any reason.
			#*PRs that have been reviewed, but no changes have been made, may be given the stale label and closed after notice.
			#Acting maliciously will result in demotion.
			#*Do not use any granted privileges for reasons other than what they are intended for.
			#Feedback must be constructive and maintainers should not talk about other members of the development community in a way that they do not want to be talked about, this applies to developers involved with other SS13 projects. To report an issue, contact the head-developer or host via discord DMs.
			\|}

	=== PR Merging ===		=== PR Merging ===

PowerfulBacon: /* Head-developer */

2025-10-11T09:17:04Z

Head-developer

← Older revision		Revision as of 09:17, 11 October 2025
Line 145:		Line 145:
	#*Ensure an appropriate design direction for the server, and push the server along that direction.		#*Ensure an appropriate design direction for the server, and push the server along that direction.
	#*Manage the development section of the Beestation organization (maintainers and contributors).		#*Manage the development section of the Beestation organization (maintainers and contributors).
			#*Collaborate with other Beestation heads to ensure an aligned vision at the top-level, and to push for changes that may be necessary in other areas as a result of a change in the codebase.
	#The head-developer has full discretionary authority over the code and design for the server.		#The head-developer has full discretionary authority over the code and design for the server.
	#The head-developer is expected to always maintain their knowledge about the current state of the server, including any issues, the opinions of players, and the best direction to move forward. They should keep up to date with all pull-requests opened and merged, should use polls to gather the opinions of players, and should use data metrics to understand trends of the server.		#The head-developer is expected to always maintain their knowledge about the current state of the server, including any issues, the opinions of players, and the best direction to move forward. They should keep up to date with all pull-requests opened and merged, should use polls to gather the opinions of players, and should use data metrics to understand trends of the server.
	~~#The head-developer is expected to review the design-documents and guide development of the server along that path.~~
	~~#The head-developer is expected to appoint and manage the maintainer team.~~
	#The head-developer is expected to collaborate with the other heads (server host and head administrators) to ensure that other aspects of server policy are in alignment with the game being presented to the players.
	~~#If the head-developer is unable to perform their duties, an acting head-developer should be appointed.~~
	~~#The acting head-developer may not make changes to the design direction of the server, but otherwise has the standard authority of the head-developer.~~
	#The head-developer may grant or remove the contributor discord role to any server-member.		#The head-developer may grant or remove the contributor discord role to any server-member.
	#The head-developer may, in correspondence with the host, demote maintainers.		#The head-developer may, in correspondence with the host, demote maintainers.
	#Head-developer is a high intensity role and comes with a significant burden and stress. ~~The~~ head-developer ~~should seek ways~~ to ~~improve this through distributing work or introducing new development roles that may assist them with~~ their ~~goals~~.		#Head-developer is a high intensity role and comes with a significant burden and stress.
			#If the head-developer is unable to perform their duties, an acting head-developer should be appointed.
	\|}		\|}

PowerfulBacon at 09:14, 11 October 2025

2025-10-11T09:14:23Z

@@ Line 94: / Line 94: @@
 |}
 === Maintainer Recruiting ===
 Maintainers have a lot of trust placed upon them, and as such it is difficult to appoint maintainers. New maintainers are selected by the current development team and there is no formal application process.
@@ Line 112: / Line 105: @@
 * Being a nice person to work around and communicate with.
 We understand that not everyone will be perfect in every regard and there are a lot of things that go into the discussions of recruiting new maintainers. We won't veto a maintainer simply because they haven't made any good balance PRs that align with the game, we value, and need, a wide range of skills across our maintainer team.
 === PR Vote Procedure ===
-* When subjecting a PR to a vote, apply the <code>Voting</code> label. Post a link to the PR in <code>#pr-player-input</code>. If the title does not provide all of the relevant info, include a short summary. If it's a sprite PR, include screenshots.
+{| class="wikitable mw-collapsible"
-* After 2-3 days check the status of the vote, remove the <code>Voting</code> label, and apply the relevant outcome label to the PR. If the vote is roughly split with no significant majority, use your discretion.
+!PR Vote Procedure
-* PR votes are non-binding, but you should typically get the headcoder to sign off on ignoring the outcome. The PR is liable to stir the hornet's nest and we want consensus that it's actually a good change.
+|-
-* The Headcoder reserves the right to ignore the voting procedures entirely.
 === In-Game perms ===
 * In game perms are primarilly for debugging purposes and should not be used to influence the rounds outside of testmerges.
 *Maintainers should be de-adminned while playing, unless there is a specific reason to be adminned.
@@ Line 130: / Line 132: @@
 *If you are deemed to be abusing the in-game maintainer perms, they may be temporarilly removed.
 *Maintainers should avoid interacting with players through the ticket system due to insufficient perms preventing them from being closed. '''Do not use Admin PM functionality.''' If you really, really need to talk to a player during a testmerge (due to a bug or other situation that needs explaining), use LOOC (Admins can talk in LOOC while ghosted) or ask another admin to help.
 === Head-developer ===
-* If the head-developer is temporarilly unable to perform their duties, then an acting head-developer may be appointed. The acting head-developer has all of the powers that a head-developer has for the rules stated above, but should avoid making changes to the established design directions.
-=== Demotion Procedure ===
+{| class="wikitable mw-collapsible"
-* The Headcoder will 'fire' you.
+!Head-Developer Key Points

PowerfulBacon: /* PR Merging */

2025-10-11T08:55:31Z

PR Merging

← Older revision		Revision as of 08:55, 11 October 2025
Line 61:		Line 61:
	*Feedback must be constructive and maintainers should not talk about other members of the development community in a way that they do not want to be talked about, this applies to developers involved with other SS13 projects. To report an issue, contact the head-developer or host via discord DMs.		*Feedback must be constructive and maintainers should not talk about other members of the development community in a way that they do not want to be talked about, this applies to developers involved with other SS13 projects. To report an issue, contact the head-developer or host via discord DMs.
	=== PR Merging ===		=== PR Merging ===
	* Non-critical PRs that have been open for less than 24h should not be merged. Critical PRs may be merged if they have approval from another maintainer, or should be testmerged as an alternative.
	**A critical PR is a major bug/exploit which is disrupting the game to a point where the server cannot operate. This could be an exploit which allows for the game to be rendered unplayable, or a bug that means the game cannot be played properly. Balance changes affecting a single role are not considered critical, even if it makes that role far more powerful than intended.
	**Temporary PRs which fix major issues should be testmerged. If the author is not available or willing to make the fixes required, the offending PR should be reverted.
	* All PRs should be considered as they are and will be treated as if they will have no more follow up PRs. If it does not provide a stable solution, it should not be merged.
	** If a PR has been merged and doesn't function as expected, the author will be notified and it will be reverted if the issues cannot be fixed within a few days.
	** Any other PRs that modify code added by a non-functioning PR should be frozen to allow for reversion.

	*Do not merge any pull request with config or SQL changes. Review and approve it then request a review from Crossed.		{\| class="wikitable mw-collapsible"
	*Do not merge any pull requests with the "Requires Approval" label. Review and approve it and then request a review from the Head Developer.		!Maintainer Conduct Key information
	*Do not self-merge a pull request, even if it has been approved by another maintainer.		\|-
	**If the merge queue fails for an unexpected reason unrelated to the PR, then you may re-queue it.		\|
	*Do not unilaterally merge pull-requests that you were ~~heavilly~~ involved in the development of.		#Pull-requests should not be merged within 24 hours of their opening, this it to give maintainers the opportunity to keep track of the codebase without requiring constant monitoring, unless they meet all of the following conditions:
	*Do not unilaterally merge balance changes or any changes which need a review of their design.		#*The pull-request has been approved by 2 or more maintainers (including the maintainer who presses the merge button), or the head-developer.
	*Do not unilaterally merge PRs that have had a key placed on them.		#*The pull-request is simple, has a small number of changes that can be manually checked for logical validity, and does not violate any programming norms which make it confusing or hard to verify the correctness of.
	**If a PR has a key on it, then there should be a discussion about the PR before merge. If an consensus is not reached then it is up to the head-developer to make the decision.		#*The pull-request is conclusive, and will not need further fixes or reversion. (Temporary fixes should be test-merged)
	*Changes that affect balance or add features should be given time and discussed with other maintainers and contributors for opinions.		#*The pull-request is not introducing any new features which were previously not present or accessible in the game.
	**If a significant amount of time passes (Minimum of 2-weeks) and there has been no discussion, ping maintainers for comment and indicate the action that you wish to perform (merge/close). If there are no responses within 24-hours, then you may perform that action unilaterally. All discussion points should be resolved first, do not merge the PR if the conversation does not reach a ~~conclussion~~.		#*The pull-request is not a quality of life change.
	**If there are no strong opinions, then the PR can be put to vote (See below).		#*The pull-request is not a balance change, excluding simple changes to numbers which were clearly not intended and are having a significant, negative impact on gameplay.
	*Any PRs that make substantial player-facing changes to the game should be signed off by the head-developer first. Any PRs which make substantial changes to the codebase which will affect how code is being written (changing a pre-existing coding convention) should also be signed off on first.		#*The pull-request is not a refactor, and does not significantly change the underlying logic in an unnecessary way.
	* Maintainers specific to a single area of the code (Maptainer, Spritetainer) should only testmerge/merge PRs in their area.		#Test-merges may be applied within 24 hours of a PR being opened.
			#Maintainers are permitted to test-merge their own PRs unless that PR interacts with the database or requires configuration changes (PRs which have optional configuration that is not required to be set may be test-merged by its author).
			# All PRs should be considered as they are and will be treated as if they will have no more follow up PRs. If it does not provide a stable solution, it should not be merged.
			#* If a PR has been merged and doesn't function as expected, the author will be notified and it will be reverted if the issues cannot be fixed within a few days.
			#* Any other PRs that modify code added by a non-functioning PR should be frozen to allow for reversion.
			#Do not merge any pull request with config or SQL changes. Review and approve it then request a review from Crossed.
			#Do not merge any pull requests with the "Requires Approval" label. Review and approve it and then request a review from the Head Developer.
			#Do not self-merge a pull request, even if it has been approved by another maintainer.
			#*If the merge queue fails for an unexpected reason unrelated to the PR, then you may re-queue it.
			#Do not unilaterally merge pull-requests that you were heavily involved in the development of.
			#Do not unilaterally merge balance changes or any changes which need a review of their design.
			#Do not unilaterally merge PRs that have had a key placed on them.
			#*If a PR has a key on it, then there should be a discussion about the PR before merge. If an consensus is not reached then it is up to the head-developer to make the decision.
			#Changes that affect balance or add features should be given time and discussed with other maintainers and contributors for opinions.
			#*If a significant amount of time passes (Minimum of 2-weeks) and there has been no discussion, ping maintainers for comment and indicate the action that you wish to perform (merge/close). If there are no responses within 24-hours, then you may perform that action unilaterally. All discussion points should be resolved first, do not merge the PR if the conversation does not reach a conclusion.
			#*If there are no strong opinions, then the PR can be put to vote (See below).
			#Any PRs that make substantial player-facing changes to the game should be signed off by the head-developer first. Any PRs which make substantial changes to the codebase which will affect how code is being written (changing a pre-existing coding convention) should also be signed off on first.
			#Maintainers specific to a single area of the code (Maptainer, Spritetainer) should only testmerge/merge PRs in their area.
			\|}

	=== Specific Policy/Processes ===		=== Specific Policy/Processes ===

PowerfulBacon: /* PR Merging */

2024-08-01T17:24:06Z

PR Merging

← Older revision		Revision as of 17:24, 1 August 2024
Line 76:		Line 76:
	*Do not unilaterally merge PRs that have had a key placed on them.		*Do not unilaterally merge PRs that have had a key placed on them.
	**If a PR has a key on it, then there should be a discussion about the PR before merge. If an consensus is not reached then it is up to the head-developer to make the decision.		**If a PR has a key on it, then there should be a discussion about the PR before merge. If an consensus is not reached then it is up to the head-developer to make the decision.
	*Changes that affect balance or add features should be given time and discussed with other maintainers and contributors for opinions. If there are no strong opinions, then the PR can be put to vote (See below).		*Changes that affect balance or add features should be given time and discussed with other maintainers and contributors for opinions.
			**If a significant amount of time passes (Minimum of 2-weeks) and there has been no discussion, ping maintainers for comment and indicate the action that you wish to perform (merge/close). If there are no responses within 24-hours, then you may perform that action unilaterally. All discussion points should be resolved first, do not merge the PR if the conversation does not reach a conclussion.
			**If there are no strong opinions, then the PR can be put to vote (See below).
	*Any PRs that make substantial player-facing changes to the game should be signed off by the head-developer first. Any PRs which make substantial changes to the codebase which will affect how code is being written (changing a pre-existing coding convention) should also be signed off on first.		*Any PRs that make substantial player-facing changes to the game should be signed off by the head-developer first. Any PRs which make substantial changes to the codebase which will affect how code is being written (changing a pre-existing coding convention) should also be signed off on first.
	* Maintainers specific to a single area of the code (Maptainer, Spritetainer) should only testmerge/merge PRs in their area.		* Maintainers specific to a single area of the code (Maptainer, Spritetainer) should only testmerge/merge PRs in their area.

PowerfulBacon: /* PR Merging */

2024-04-16T12:01:49Z

PR Merging

← Older revision		Revision as of 12:01, 16 April 2024
Line 66:		Line 66:
	* All PRs should be considered as they are and will be treated as if they will have no more follow up PRs. If it does not provide a stable solution, it should not be merged.		* All PRs should be considered as they are and will be treated as if they will have no more follow up PRs. If it does not provide a stable solution, it should not be merged.
	** If a PR has been merged and doesn't function as expected, the author will be notified and it will be reverted if the issues cannot be fixed within a few days.		** If a PR has been merged and doesn't function as expected, the author will be notified and it will be reverted if the issues cannot be fixed within a few days.
	** Any other PRs that modify a non-functioning PR should be frozen to allow for reversion.		** Any other PRs that modify code added by a non-functioning PR should be frozen to allow for reversion.

	*Do not merge any pull request with config or SQL changes. Review and approve it then request a review from Crossed.		*Do not merge any pull request with config or SQL changes. Review and approve it then request a review from Crossed.

PowerfulBacon: /* PR Merging */

2024-04-16T11:57:24Z

PR Merging

← Older revision		Revision as of 11:57, 16 April 2024
Line 64:		Line 64:
	**A critical PR is a major bug/exploit which is disrupting the game to a point where the server cannot operate. This could be an exploit which allows for the game to be rendered unplayable, or a bug that means the game cannot be played properly. Balance changes affecting a single role are not considered critical, even if it makes that role far more powerful than intended.		**A critical PR is a major bug/exploit which is disrupting the game to a point where the server cannot operate. This could be an exploit which allows for the game to be rendered unplayable, or a bug that means the game cannot be played properly. Balance changes affecting a single role are not considered critical, even if it makes that role far more powerful than intended.
	**Temporary PRs which fix major issues should be testmerged. If the author is not available or willing to make the fixes required, the offending PR should be reverted.		**Temporary PRs which fix major issues should be testmerged. If the author is not available or willing to make the fixes required, the offending PR should be reverted.
			* All PRs should be considered as they are and will be treated as if they will have no more follow up PRs. If it does not provide a stable solution, it should not be merged.
			** If a PR has been merged and doesn't function as expected, the author will be notified and it will be reverted if the issues cannot be fixed within a few days.
			** Any other PRs that modify a non-functioning PR should be frozen to allow for reversion.

	*Do not merge any pull request with config or SQL changes. Review and approve it then request a review from Crossed.		*Do not merge any pull request with config or SQL changes. Review and approve it then request a review from Crossed.
Line 76:		Line 79:
	*Any PRs that make substantial player-facing changes to the game should be signed off by the head-developer first. Any PRs which make substantial changes to the codebase which will affect how code is being written (changing a pre-existing coding convention) should also be signed off on first.		*Any PRs that make substantial player-facing changes to the game should be signed off by the head-developer first. Any PRs which make substantial changes to the codebase which will affect how code is being written (changing a pre-existing coding convention) should also be signed off on first.
	* Maintainers specific to a single area of the code (Maptainer, Spritetainer) should only testmerge/merge PRs in their area.		* Maintainers specific to a single area of the code (Maptainer, Spritetainer) should only testmerge/merge PRs in their area.

	=== Specific Policy/Processes ===		=== Specific Policy/Processes ===
	==== Large structural changes to the code ====		==== Large structural changes to the code ====