Contributor Guide - Revision history

K5 at 02:26, 26 November 2024

2024-11-26T02:26:17Z

← Older revision		Revision as of 02:26, 26 November 2024
Line 1:		Line 1:
	{{SidebarStaff}}		{{SidebarStaff}}

	==~~<center>Contribution guidelines</center>~~==		== Rules ==
	~~<hr>~~
	~~<center>'''Hardline rules'''</center><hr>~~
	* PRs may be put forth are not necessarily supported by their creator. They may be made on behalf of others or even just on a notion. All are free to make Pull Requests for consideration and ultimate responsibility for the inclusion(or exclusion) on content falls squarely on the head of the Lead-Dev. No coder should be shouted at solely for a change they've requested.<br>		* PRs may be put forth are not necessarily supported by their creator. They may be made on behalf of others or even just on a notion. All are free to make Pull Requests for consideration and ultimate responsibility for the inclusion(or exclusion) on content falls squarely on the head of the Lead-Dev. No coder should be shouted at solely for a change they've requested.<br>
	*Players and admins shall not dictate to devs or contributors how they 'must' spend their time coding. While changes will invariably become necessary for any number of reasons(story arcs, balance, etc) these changes should either be requested, or directly given to the lead-dev to determine implementation. At the end of the day, all developers who work on this project do so of their own volition and in their free time. ~~<hr>~~		*Players and admins shall not dictate to devs or contributors how they 'must' spend their time coding. While changes will invariably become necessary for any number of reasons(story arcs, balance, etc) these changes should either be requested, or directly given to the lead-dev to determine implementation. At the end of the day, all developers who work on this project do so of their own volition and in their free time.

	==~~== <center>~~Guidelines~~</center> ==~~==		== Guidelines ==
	#All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns.		#All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns.
	# Content should be made with respect to the setting, atmosphere, balance and performance impact.		# Content should be made with respect to the setting, atmosphere, balance and performance impact.

K5 at 00:48, 26 November 2024

2024-11-26T00:48:53Z

← Older revision		Revision as of 00:48, 26 November 2024
Line 1:		Line 1:
			{{SidebarStaff}}

	==<center>Contribution guidelines</center>==		==<center>Contribution guidelines</center>==
	<hr>		<hr>

Cdb: /* Guidelines */

2024-05-23T13:00:57Z

Guidelines

← Older revision		Revision as of 13:00, 23 May 2024
Line 8:		Line 8:
	#All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns.		#All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns.
	# Content should be made with respect to the setting, atmosphere, balance and performance impact.		# Content should be made with respect to the setting, atmosphere, balance and performance impact.
	# Changelogs MUST be detailed. While this is down to your discretion as to how much or little is 'relevant' , the most ~~pertinant~~ details should be laid out in clear and easy to read. E.G a new gun should have its damage, penetration and accuracy detailed. By following this guideline we hope to ease the process of balancing new content without stimying its addition.		# Changelogs MUST be detailed. While this is down to your discretion as to how much or little is 'relevant' , the most pertinent details should be laid out in clear and easy to read. E.G a new gun should have its damage, penetration and accuracy detailed. By following this guideline we hope to ease the process of balancing new content without stimying its addition.
	# In the same way as the above, anything more than minor content should be thoroughly Q.A tested to ensure no bugs, erroneous behaviors, runtime, et cetera are going to cause immediate issue.		# In the same way as the above, anything more than minor content should be thoroughly Q.A tested to ensure no bugs, erroneous behaviors, runtime, et cetera are going to cause immediate issue.
	# PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.		# PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.
	# While there are bound to be PRs that are so minor as to not necessarily require testing, it is considered good practice to do so anyway. PRs should be tested to at least a basic level of completion and in the PR should have the following info; What this PR does, How I tested it, What the test result is.		# While there are bound to be PRs that are so minor as to not necessarily require testing, it is considered good practice to do so anyway. PRs should be tested to at least a basic level of completion and in the PR should have the following info; What this PR does, How I tested it, What the test result is.
	# PRs with lore implications will at times be subject to A. review by creative lead or headmins, and B. Reasonable explanation as to why/how this change took place. E.G; PR A intends to balance FBPs by restricting departmental types to their respective departments, PR creator may be expected to work with lore team to provide a plausible reason for why this change has taken place.		# PRs with lore implications will at times be subject to A. review by creative lead or headmins, and B. Reasonable explanation as to why/how this change took place. E.G; PR A intends to balance FBPs by restricting departmental types to their respective departments, PR creator may be expected to work with lore team to provide a plausible reason for why this change has taken place.
			# PR titles should be descriptive, no shit posts please.
			# Non-minor/non-bugfix PRs will generally be testmerges for anywhere from five days onward before being marked ready for full inclusion. Take this time to receive feedback and make any necessary changes. Any changes to and already test merged PR need to be communicated to the person who testmerged it.
			#concerns about a PR should generally be directed towards head admins for relaying to head devs/maintainers. This is per k5s preference.

LillyTrilby: /* Guidelines */

2024-03-28T20:05:56Z

Guidelines

← Older revision		Revision as of 20:05, 28 March 2024
Line 12:		Line 12:
	# PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.		# PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.
	# While there are bound to be PRs that are so minor as to not necessarily require testing, it is considered good practice to do so anyway. PRs should be tested to at least a basic level of completion and in the PR should have the following info; What this PR does, How I tested it, What the test result is.		# While there are bound to be PRs that are so minor as to not necessarily require testing, it is considered good practice to do so anyway. PRs should be tested to at least a basic level of completion and in the PR should have the following info; What this PR does, How I tested it, What the test result is.
	# PRs with lore implications will at times be subject to A. review by creative lead~~(currently @REDALERT#5274 on discord)~~, and B. Reasonable explanation as to why/how this change took place. E.G; PR A intends to balance FBPs by restricting departmental types to their respective departments, PR creator may be expected to work with lore team to provide a plausible reason for why this change has taken place.		# PRs with lore implications will at times be subject to A. review by creative lead or headmins, and B. Reasonable explanation as to why/how this change took place. E.G; PR A intends to balance FBPs by restricting departmental types to their respective departments, PR creator may be expected to work with lore team to provide a plausible reason for why this change has taken place.

LillyTrilby at 21:51, 2 November 2022

2022-11-02T21:51:33Z

← Older revision		Revision as of 21:51, 2 November 2022
Line 12:		Line 12:
	# PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.		# PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.
	# While there are bound to be PRs that are so minor as to not necessarily require testing, it is considered good practice to do so anyway. PRs should be tested to at least a basic level of completion and in the PR should have the following info; What this PR does, How I tested it, What the test result is.		# While there are bound to be PRs that are so minor as to not necessarily require testing, it is considered good practice to do so anyway. PRs should be tested to at least a basic level of completion and in the PR should have the following info; What this PR does, How I tested it, What the test result is.
	# PRs with lore implications will at times be subject to A. review by creative lead(currently @~~PinkestKitten~~#~~8019~~ on discord), and B. Reasonable explanation as to why/how this change took place. E.G; PR A intends to balance FBPs by restricting departmental types to their respective departments, PR creator may be expected to work with lore team to provide a plausible reason for why this change has taken place.		# PRs with lore implications will at times be subject to A. review by creative lead(currently @REDALERT#5274 on discord), and B. Reasonable explanation as to why/how this change took place. E.G; PR A intends to balance FBPs by restricting departmental types to their respective departments, PR creator may be expected to work with lore team to provide a plausible reason for why this change has taken place.

Cdb: /* Contribution guidelines */

2022-08-24T22:07:59Z

Contribution guidelines

← Older revision		Revision as of 22:07, 24 August 2022
Line 12:		Line 12:
	# PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.		# PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.
	# While there are bound to be PRs that are so minor as to not necessarily require testing, it is considered good practice to do so anyway. PRs should be tested to at least a basic level of completion and in the PR should have the following info; What this PR does, How I tested it, What the test result is.		# While there are bound to be PRs that are so minor as to not necessarily require testing, it is considered good practice to do so anyway. PRs should be tested to at least a basic level of completion and in the PR should have the following info; What this PR does, How I tested it, What the test result is.
			# PRs with lore implications will at times be subject to A. review by creative lead(currently @PinkestKitten#8019 on discord), and B. Reasonable explanation as to why/how this change took place. E.G; PR A intends to balance FBPs by restricting departmental types to their respective departments, PR creator may be expected to work with lore team to provide a plausible reason for why this change has taken place.

Cdb: /* Contribution guidelines */

2022-08-10T16:19:48Z

Contribution guidelines

← Older revision		Revision as of 16:19, 10 August 2022
Line 4:		Line 4:
	* PRs may be put forth are not necessarily supported by their creator. They may be made on behalf of others or even just on a notion. All are free to make Pull Requests for consideration and ultimate responsibility for the inclusion(or exclusion) on content falls squarely on the head of the Lead-Dev. No coder should be shouted at solely for a change they've requested.<br>		* PRs may be put forth are not necessarily supported by their creator. They may be made on behalf of others or even just on a notion. All are free to make Pull Requests for consideration and ultimate responsibility for the inclusion(or exclusion) on content falls squarely on the head of the Lead-Dev. No coder should be shouted at solely for a change they've requested.<br>
	*Players and admins shall not dictate to devs or contributors how they 'must' spend their time coding. While changes will invariably become necessary for any number of reasons(story arcs, balance, etc) these changes should either be requested, or directly given to the lead-dev to determine implementation. At the end of the day, all developers who work on this project do so of their own volition and in their free time. <hr>		*Players and admins shall not dictate to devs or contributors how they 'must' spend their time coding. While changes will invariably become necessary for any number of reasons(story arcs, balance, etc) these changes should either be requested, or directly given to the lead-dev to determine implementation. At the end of the day, all developers who work on this project do so of their own volition and in their free time. <hr>

	==== <center>Guidelines</center> ====		==== <center>Guidelines</center> ====
	#~~Guideline -~~ All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns.		#All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns.
	#~~Guideline -~~ Content should be made with respect to the setting, atmosphere, balance and performance impact.		# Content should be made with respect to the setting, atmosphere, balance and performance impact.
	#~~Guideline -~~ Changelogs MUST be detailed. While this is down to your discretion as to how much or little is 'relevant' , the most pertinant details should be laid out in clear and easy to read. E.G a new gun should have its damage, penetration and accuracy detailed. By following this guideline we hope to ease the process of balancing new content without stimying its addition.		# Changelogs MUST be detailed. While this is down to your discretion as to how much or little is 'relevant' , the most pertinant details should be laid out in clear and easy to read. E.G a new gun should have its damage, penetration and accuracy detailed. By following this guideline we hope to ease the process of balancing new content without stimying its addition.
	#~~Guideline -~~In the same way as the above, anything more than minor content should be thoroughly Q.A tested to ensure no bugs, erroneous behaviors, runtime, et cetera are going to cause immediate issue.		# In the same way as the above, anything more than minor content should be thoroughly Q.A tested to ensure no bugs, erroneous behaviors, runtime, et cetera are going to cause immediate issue.
	#~~Guideline -~~ PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.		# PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.
			# While there are bound to be PRs that are so minor as to not necessarily require testing, it is considered good practice to do so anyway. PRs should be tested to at least a basic level of completion and in the PR should have the following info; What this PR does, How I tested it, What the test result is.

Cdb: /* Contribution guidelines */

2022-05-16T02:47:15Z

Contribution guidelines

← Older revision		Revision as of 02:47, 16 May 2022
Line 1:		Line 1:
	==<center>Contribution guidelines</center>==		==<center>Contribution guidelines</center>==
	<hr>		<hr>
	<center>'''Hardline ~~rule~~'''</center><hr> PRs may be put forth are not necessarily supported by their creator. They may be made on behalf of others or even just on a notion. All are free to make Pull Requests for consideration and ultimate responsibility for the inclusion(or exclusion) on content falls squarely on the head of the Lead-Dev. No coder should be shouted at solely for a change they've requested. <hr>		<center>'''Hardline rules'''</center><hr>
			* PRs may be put forth are not necessarily supported by their creator. They may be made on behalf of others or even just on a notion. All are free to make Pull Requests for consideration and ultimate responsibility for the inclusion(or exclusion) on content falls squarely on the head of the Lead-Dev. No coder should be shouted at solely for a change they've requested.<br>
			*Players and admins shall not dictate to devs or contributors how they 'must' spend their time coding. While changes will invariably become necessary for any number of reasons(story arcs, balance, etc) these changes should either be requested, or directly given to the lead-dev to determine implementation. At the end of the day, all developers who work on this project do so of their own volition and in their free time. <hr>
	==== <center>Guidelines</center> ====		==== <center>Guidelines</center> ====
	#Guideline - All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns.		#Guideline - All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns.

SneakyFoxOfDas: Adds a -

2022-05-14T21:56:25Z

Adds a -

← Older revision		Revision as of 21:56, 14 May 2022
Line 3:		Line 3:
	<center>'''Hardline rule'''</center><hr> PRs may be put forth are not necessarily supported by their creator. They may be made on behalf of others or even just on a notion. All are free to make Pull Requests for consideration and ultimate responsibility for the inclusion(or exclusion) on content falls squarely on the head of the Lead-Dev. No coder should be shouted at solely for a change they've requested. <hr>		<center>'''Hardline rule'''</center><hr> PRs may be put forth are not necessarily supported by their creator. They may be made on behalf of others or even just on a notion. All are free to make Pull Requests for consideration and ultimate responsibility for the inclusion(or exclusion) on content falls squarely on the head of the Lead-Dev. No coder should be shouted at solely for a change they've requested. <hr>
	==== <center>Guidelines</center> ====		==== <center>Guidelines</center> ====
	#Guideline All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns.		#Guideline - All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns.
	#Guideline - Content should be made with respect to the setting, atmosphere, balance and performance impact.		#Guideline - Content should be made with respect to the setting, atmosphere, balance and performance impact.
	#Guideline - Changelogs MUST be detailed. While this is down to your discretion as to how much or little is 'relevant' , the most pertinant details should be laid out in clear and easy to read. E.G a new gun should have its damage, penetration and accuracy detailed. By following this guideline we hope to ease the process of balancing new content without stimying its addition.		#Guideline - Changelogs MUST be detailed. While this is down to your discretion as to how much or little is 'relevant' , the most pertinant details should be laid out in clear and easy to read. E.G a new gun should have its damage, penetration and accuracy detailed. By following this guideline we hope to ease the process of balancing new content without stimying its addition.
	#Guideline -In the same way as the above, anything more than minor content should be thoroughly Q.A tested to ensure no bugs, erroneous behaviors, runtime, et cetera are going to cause immediate issue.		#Guideline -In the same way as the above, anything more than minor content should be thoroughly Q.A tested to ensure no bugs, erroneous behaviors, runtime, et cetera are going to cause immediate issue.
	#Guideline - PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.		#Guideline - PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.

Cdb: /* Guidelines */

2022-05-14T21:53:43Z

Guidelines

← Older revision		Revision as of 21:53, 14 May 2022
Line 3:		Line 3:
	<center>'''Hardline rule'''</center><hr> PRs may be put forth are not necessarily supported by their creator. They may be made on behalf of others or even just on a notion. All are free to make Pull Requests for consideration and ultimate responsibility for the inclusion(or exclusion) on content falls squarely on the head of the Lead-Dev. No coder should be shouted at solely for a change they've requested. <hr>		<center>'''Hardline rule'''</center><hr> PRs may be put forth are not necessarily supported by their creator. They may be made on behalf of others or even just on a notion. All are free to make Pull Requests for consideration and ultimate responsibility for the inclusion(or exclusion) on content falls squarely on the head of the Lead-Dev. No coder should be shouted at solely for a change they've requested. <hr>
	==== <center>Guidelines</center> ====		==== <center>Guidelines</center> ====
	# - All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns.		#Guideline All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns.
	#Guideline - Content should be made with respect to the setting, atmosphere, balance and performance impact.		#Guideline - Content should be made with respect to the setting, atmosphere, balance and performance impact.
	#Guideline - Changelogs MUST be detailed. While this is down to your discretion as to how much or little is 'relevant' , the most pertinant details should be laid out in clear and easy to read. E.G a new gun should have its damage, penetration and accuracy detailed. By following this guideline we hope to ease the process of balancing new content without stimying its addition.		#Guideline - Changelogs MUST be detailed. While this is down to your discretion as to how much or little is 'relevant' , the most pertinant details should be laid out in clear and easy to read. E.G a new gun should have its damage, penetration and accuracy detailed. By following this guideline we hope to ease the process of balancing new content without stimying its addition.
	#Guideline -In the same way as the above, anything more than minor content should be thoroughly Q.A tested to ensure no bugs, erroneous behaviors, runtime, et cetera are going to cause immediate issue.		#Guideline -In the same way as the above, anything more than minor content should be thoroughly Q.A tested to ensure no bugs, erroneous behaviors, runtime, et cetera are going to cause immediate issue.
	#Guideline - PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.		#Guideline - PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.