TRENCH WARS
PROPOSAL SYSTEM

Last updated 7/02/05

	Contents

I.	Overview of the Trench Wars Proposal System (TWPS)
II.	Purpose of TWPS
III.	Properties of a Proposal
a.	Overall properties
b.	Header
i.	Proposed by
ii.	Email
iii.	Submitted
iv.	Proposal category
1.	Legislative
2.	Executive
3.	Judicial
4.	Apolitical
v.	Class of proposal
1.	Reform
2.	Independent
c.	Overview
d.	Problem Statement
i.	Basic description
ii.	Explanation
iii.	Rectification
e.	Description
f.	Task List
i.	Task description
ii.	Contributor
iii.	Estimated Date of Completion (EDC)
g.	Required Resources
i.	Resource description
ii.	Estimated work in hours
h.	Co-signers
IV.	Proposal Submission Procedure
a.	Proposal creation
b.	Proposal submission
c.	Preliminary review
i.	Submitting to upper staff board
ii.	Categorization
1.	Pending review
2.	Improper formatting
3.	Lack of proper support
4.	Special restrictions
iii.	Submitting results
d.	Review
i.	Time allowed
ii.	Majority vote
iii.	Rules of classification
e.	Decision
i.	Accepted
ii.	Accepted in confidence
iii.	Rejected
1.	Infeasible
2.	Problem statement extremely subjective
3.	Fraud
4.	Special restrictions
5.	Other
iv.	Rejected for review
1.	Unclear
2.	Lack of convincing support (from staff / from players / from staff and players)
3.	Unreasonable request for resources
4.	Other
V.	Proposal Implementation
VI.	Appeals
VII.	Miscellaneous
a.	Special restrictions
i.	New Leagues
b.	Fraud
c.	Duties of Arbiter of Discourse

I.	Overview of the Trench Wars Proposal System (TWPS)

The Trench Wars Proposal System (abbreviated TWPS) allows anyone to make a proposal for changes in the Trench Wars zone that will then be considered by members of Trench Wars upper staff (defined as the team of SMods and Sysops).
If accepted by upper staff, the proposal constituents and any others who have pledged to work on it will implement it according to a direct plan of action.  Additionally, upper staff may delegate staff resources to assist in the project where absolutely necessary (see “Required Resources” section), though the idea of the system is to place the largest burden of effort on the proposal constituents.
Finally, when the proposal is fully implemented, the final product will be reviewed by upper staff to be either acceptable or not in comparison to the original proposal.  If it is considered acceptable, the implementation is incorporated into the present Trench Wars system, or if it is a reform measure, replaces the currently applicable rules and/or procedures.
This proposal system is, and always will be, a work in progress.  It should be revised via method of proposal whenever it does not suit the needs of the zone.

II.	Purpose of TWPS

TWPS was created to address several problems inherent in the old TW system, which placed the burden of change on staff members who have generally served longest, relying on word-of-mouth to coordinate their efforts.  Recognizing the freedom that the preexisting system provides to those who have access to it, TWPS is offered as an alternative to rather than a replacement for how change is currently brought about in TW.  It increases the overall freedom of change for those who have in the past had very little of this freedom, while still retaining power in the hands of upper staff to reject changes that they believe are detrimental to the zone’s overall wellbeing.
The proposal system is not intended to create a democratic process by which to propose change.  Unfortunately, there is not enough interest by the general population in the goings-on of the zone to make any kind of real governmental body feasible.  Acknowledging these limitations, the Trench Wars Proposal System has been created as a large step towards making a more fair and functional system to create positive change in the zone.
It is by no means the end-all-be-all system of proposing change, and should someone desire to change how it operates, they are welcome to make a proposal suggesting the change.

III.	Properties of a Proposal

a. 	Overall properties
For the purpose of quick review, every proposal must be submitted with the same basic format and layout.  Proposals can be in straight text (txt), rich text (rtf) or Word document (doc) format.
There are seven sections in every proposal, and each must be completed correctly in order for a proposal to be considered.  Information on how to correctly complete each section is included below.

		b.	Header
			The Header section must include, in this order:

i.	Proposed by – This heading is followed by the alias that the submitter or submitters use most frequently in Subspace.
ii.	Email – Email address of person submitting the proposal.
iii.	Submitted – This heading is followed by the date which the submitter sent off the proposal for review.  It must match the date on the email or submission form, as applicable.
iv.	Proposal category – This heading designates the issues which a proposal addresses, and is followed by one of the following:
1.	Legislative: concerned with the creation and alteration of the set of rules that govern Trench Wars.
2.	Executive: concerned with staffing and administration policy, including hiring, promotion, termination, communication and overall organization.
3.	Judicial: concerned with rule and policy enforcement, and changing the appeals process related to enforcement.  Note that this does not mean proposals can or should be made for making ban appeals.
4.	Apolitical: anything that does not concern itself with any of the above (essentially game-related proposals).
iv. 	Class of proposal – This heading designates whether the proposal is creating something new, or is modifying a pre-existing rule, policy or system.
1.	Reform: proposal is revising a pre-existing rule, policy or system.
2.	Independent: proposal is largely independent of current rules, policies and systems.

c.	Overview
	Here a basic description of the proposal is given.  It should consist of 2 to 4 paragraphs, and details should not be included (best left for the Description section).  As this piece of the proposal will be highly scrutinized, and is the initial “selling point,” it should be concise and convincing.  Note that it should not be described in the overview why the proposal is being submitted (see Problem Statement); it’s simply intended to describe, in brief, what will be done should it be accepted.

d.	Problem statement
The problem statement is where a case is built for the proposal as being necessary to fix a problem that exists in Trench Wars.  It may include as many or as few problems as are necessary to justify it.  The object is to provide convincing proof that there are problems that the proposal can and will fix.  Each problem in the section includes three pieces, none of which have a formal heading.
i.	Basic description: A one to two sentence description of the problem that should be italicized, if possible.
ii. 	Explanation: An explanation, in paragraph form, of why this is a problem.
iii.	Rectification: An explanation, in paragraph form, of how this proposal will fix or help fix this problem.

e.	Description
The description is a thorough explanation of a proposal, including all important details that must be considered prior to its implementation.  There should be nothing significant that is left a mystery.  If a proposal is lacking in its description, either in not going into enough detail, or simply not addressing obvious issues, it can be rejected.

f.	Tasks
The Tasks section shows what the submitter and other proposal constituents intend to do to implement the proposal.  Generally, the bulk of the work required to put it into action should be in this section and not in the Required Resources section.  There may be as many or as few tasks as are necessary for the completion of the project.  Tasks should be put into a table format if possible.  Each line of the table should include:
i.	Task description: one to three sentences describing the task to be completed.
ii.	Contributor: the individual, by main SS alias, who has pledged to do the work.
iii.	Estimated Time of Completion (ETC): how long after the proposal is accepted (in weeks) the work is anticipated to be finished.

g.	Required resources
Any “resources,” or things that the submitter of the proposal is unable to get without help from upper staff, are listed in this section.  Proposals may be rejected for including too many items in this section, particularly if they can be put in Tasks.  Those submitting should think carefully about finding people who can pledge their effort to the project and by doing so, turn some required resources into far more attractive tasks.
IMPORTANT NOTE: Resources should be secured almost entirely by the individual making the proposal.  The only 100% acceptable “Required resource” is one which the person who is submitting has no access to – for example, adding a field in a database.  In this kind of case, almost all of the planning work should still be done by the person proposing.  Examples of unreasonable requests for resources: coding work that does not require special bot access; map development; website development
The Required resources section should be similar in appearance to Tasks, in table format if possible.  Each line of the table should include:
i.	Resource description: one to three sentences describing the resource needed.
ii.	Estimated work in hours: how many hours are anticipated to be required to provide this resource, either as a flat number, or if applicable, per week, month, etc.

h.	Co-signers
The co-signers section is the final component of a proposal, and is required in order to show that the ideas contained within are important to people other than those submitting the proposal, and also important to members of staff.  The minimum number of supporting individuals required is five (5), and two (2) of those five individuals must be members of Trench Wars staff.  However, it is far more convincing to have more supporters than the minimum number required.  Should a proposal be heavily debated among members of upper staff before a final ruling is given, one with over 50 supporters will have a much higher chance of being accepted than a proposal with the minimum 5.  This is because a proposal can be rejected for lack of convincing support, particularly if it is supposed to be a significant change.  The idea is that it is far more difficult to contest an idea supported by the combined effort of a large number of people than it is for one with only five total supporters.
Following the Co-signers heading, the section must include the following statement:
The following individuals hereby pledge as co-signers their complete support to the preceding proposal in placing or agreeing to have placed their primary SubSpace name, primary email address and date below.  Those who are members of Trench Wars staff have SS names listed in italics.  All who place their primary SS name, email and date of signing below do so with the understanding that knowing forgery of any kind will remove their right to create or co-sign any future proposals, completely invalidate this proposal, and will without question result in a ban from the Trench Wars server and if applicable, their dismissal from Trench Wars Staff.
Below this statement, each full and willing supporter of the proposal should place or have one of the proposal submitters place their primary Subspace alias, their primary email address, and the date at which their name was added to the list.  The order of the individuals should never be changed, so that the person who first pledged their support will always be at the top of the list, and the last person to pledge before submission will be the last on the list.
There are heavy provisions set against fraud in this section.  All of (but not limited to) the following constitute fraud: adding a person’s name as a co-signer without their knowledge; providing false information, such as an invalid email address or inaccurate date; or co-signing two aliases from the same computer.  Note that this last type of fraud does include “family” accounts where two people share the same computer.  However, if a member of staff Moderator or higher vouches for the status of the two accounts as being owned by members of one family, then they can legitimately both co-sign the proposal.  This should be noted immediately after the name, email and date as: (Family member of XXXXX, vouched by YYYYY), where XXXXX is the name of the other account and YYYYY is the name of the staff member that has vouched for them being family members.

IV.	Proposal Submission Procedure

		a.	Proposal creation
All proposals must be created according to the guidelines in Section III of this policy manual, Properties of a Proposal.  The final product may be in MS Word Document format, Rich Text Format, or plain text.
It is recommended that proposals are designed using the publicly available Proposal Template and an editor that can open the Word Document format.

		b.	Proposal submission
To receive consideration, a proposal must be submitted to the following email:

proposals@twsites.com

The subject should have the line Proposal: followed by the date submitted, as in:

Proposal: 2/1/05

The proposal should be included on to the mail as an attachment.

		c.	Preliminary Review
The Arbiter of Discourse (see section VI.c for explanation and duties of this position) is responsible for giving a preliminary review of all proposals that are submitted.  The purpose of this review is to find any proposals that have obvious flaws, and disqualify them from consideration by the upper staff team so that they are not inundated with proposals.  When a new proposal is received, a series of tasks will be performed that constitute a Preliminary Review:

i. 	Submitting to upper staff board: The Arbiter of Discourse will first post a new thread that includes the entirety of the proposal on the board established for upper staff proposal review.  This occurs before beginning a preliminary review to allow upper staff to review the decisions made by the Arbiter of Discourse if they wish to.
ii.	Categorization: The proposal must be initially categorized (purpose of the preliminary review) within 5 days of its initial submission date.  In that time it must be categorized as one of the following:
1.	Pending review: there are no initial problems with the proposal that prevent it from being reviewed.  No information needs to accompany this categorization.  After a “pending review” status is given, the proposal is said to be submitted for review (see Section IV.d.i).
2.	Improper formatting: the proposal has been rejected for revision (see Section IV.e) due to an error in the format corresponding to the guidelines in Section III.  A minimum one paragraph must accompany this categorization showing what the problem is.
3.	Lack of proper support: the proposal has been rejected for revision due to an inadequate number of co-signers, or an inadequate number of staff co-signers.  If there are any special circumstances (such as a co-signer recently leaving staff and therefore no longer counting as a staff signature), a minimum one paragraph should accompany this categorization explaining the situation.
4.	Infeasible: the proposal could never actually be implemented – it is either completely impossible or extremely improbable.
5.	Problem statement extremely subjective: the problem presented can not adequately be shown to be a wide-reaching problem; it is more a personal perspective of the proposal’s creator.  If this ruling is given, there are many people who probably do not see this as a problem at all.
6.	Fraud: the proposal has been determined to be fraudulent in some manner, intentionally misrepresenting some piece or pieces of information.  In almost all cases this will relate to the Co-Signer or Tasks sections, though it could relate to others as well, in any attempt to mislead or deceive upper staff in general.
7.	Special restrictions: the proposal has been rejected (see Section IV.e) due to special restrictions established by upper staff (see Section VII.a).  Note that this can not be used as a reason for rejection if the proposal seeks to modify a special restriction.
iii.	Submitting results: After the proposal has been categorized, then the results are submitted to the upper staff proposal board on the same thread as was used for the original proposal.  An additional thread must also be created on a publicly-viewable proposal board that can be read by anyone interested.  It must show first the original proposal, and then the results of the preliminary review.  Any information necessary to the categorization must be included on both the public and upper staff proposal review board.
iv.	Repealing a preliminary review: At any time during the two week period following the categorization, if upper staff comes to a majority vote (see Section IV.d.ii) to repeal the categorization of the preliminary review, it can be repealed and re-categorized (see Section IV.c.ii).  This is allowed to prevent a proposal from being unfairly rejected during preliminary review.

d.	Review

i.	 Time allowed
Upper staff has two weeks’ time to come to a majority vote decision on a proposal after it has been submitted for review (as defined in Section IV.c.ii.1).
ii.	Majority vote
Majority vote among upper staff is defined as:

51% or more members of upper staff coming to an agreement on the classification status of a proposal at the end of its review period.

Members of upper staff that abstain from any discussion on the proposal and put forth no opinion on how a proposal should be classified are not included in the voting procedure.  Therefore, they do not count as part of the total percentage of individuals needed to reach a majority vote.
A majority vote can be said to be reached if at any time during the two week review period, more than 50% of upper staff members have placed an agreeing vote.  This is used to expedite the classification process.

			iii.	Rules of classification
A majority vote must be obtained to classify the proposal as one of the following, defined in Section IV.e: accepted; accepted in confidence; rejected; rejected for revision; extended pending further review.  In order for the proposal to be rejected or rejected for review, it must be for one of the allowable reasons according to the type of rejection, and must include a detailed description that is one (1) paragraph minimum describing the reason for its rejection.  This decision must be posted on the appropriate proposal thread in the upper staff and public proposal forums by the Arbiter of Discourse as soon as possible after a majority vote has been reached (the actual deadline being 2 weeks after proposal was originally submitted for review).

		e.	Decision
Upper staff must decide to classify the proposal as one of the following according to the rules in Section IV.d:

i.	Accepted: If a proposal is accepted, it then moves into the Implementation process, specified in Section V.
ii.	Accepted in confidence: If a proposal is accepted in confidence, it moves into the Implementation process specified in Section V and is exempt from certain requirements.  This is a special classification intended to expedite the implementation process, and should only be given in certain circumstances.
iii.	Rejected: If a proposal is rejected, it can not be implemented due to serious problems that would not be solved by minor revision.  One of the following must be given as a reason for rejection:
1.	Infeasible: See Section IV.c.ii.4.
2.	Problem statement extremely subjective: See Section IV.c.ii.5.
3.	Fraud: See Section IV.c.ii.6.
4.	Special restrictions: See Section IV.c.ii.7.
5.	Other: Rejected for any other significant reason that leaves the proposal little chance of being accepted with only minor revisions being made.  Upper staff are advised to use this classification only as a last resort, and classify it into one of the preceding categories if possible.  A minimum two (2) paragraph description of the reason for rejection is required when classifying as Other (as opposed to the standard one minimum required).
iv.	Rejected for review: If a proposal is rejected for review, it could most likely be implemented if minor revisions were made.  One of the following must be given as a reason for a proposal to be rejected for revision:
1.	Unclear: The proposal is on one or many counts unclear on important details.  Without a better understanding of how implementation will proceed, upper staff is unable to accept the proposal.
2.	Lack of convincing support (from staff / from players / from staff and players): This classification is very subjective, as what support is convincing depends entirely on the proposal and the individuals who need to be convinced.  If a major change is to be made, then the support for the proposal must be extremely convincing, and usually far in excess of the minimum requirements for co-signers.  In this case, if upper staff is not convinced by the amount of co-signers, especially as regarding the issue being addressed, lack of convincing support may become a valid reason for rejection for review.  If the proposal mainly deals with staff matters and few staff co-sign, it can be rejected for lack of convincing support from staff.  If the proposal mainly deals with in-game matters or specific player-related matters and few players co-sign, it can be rejected for lack of convincing support from players.  If the proposal deals with matters affecting everyone, and few staff and few players have co-signed, it can be rejected for lack of convincing support from staff and players (the most serious lack of support rejection possible).
3.	Unreasonable request for resources: The proposal makes too many requests, or too large of a request, for outside resources in the Required resources section.  This classification is suited mostly to situations where resources that are being requested could have easily been privately requested directly to able individuals, pledged by those individuals, and then included in the Tasks section.  However, even in circumstances when most Required resources can not be relocated to the Tasks section, yet would be too large a burden on staff, this reason may still be used to reject a proposal.
4.	Other: Rejected for revision for any other reason that would allow the possibility of the acceptance of the proposal with only minor revisions being done.  Upper staff are advised to use this classification only as a last resort, and classify it into one of the preceding categories if possible.  A minimum two (2) paragraph description of the reason for rejection for review is required when classifying as Other (as opposed to the usual minimum one required).
v.	Extended pending further review: If upper staff can not get a majority vote on a proposal in the allotted two weeks’ time after it has been posted for review, they may decide to extend the review time, not to exceed 1 month in excess of the original deadline.  A review may only be extended once, after which upper staff must make a decision.

V.	Proposal Implementation

	After a proposal has been accepted, it must be implemented according to the proposal description.  Once implemented, it will be compared directly to the original proposal to ensure accuracy, and if it is determined to be satisfactory, it will be integrated into Trench Wars.
	
	a. 	Resources
Upper staff is required to provide all resources listed in the Required resources section as a stipulation of accepting the proposal.  The resources must be provided within 1 week of the date of proposal acceptance, if applicable.  If the resource is an ongoing one, it must continue to be provided as frequently as is specified.

	b.	Accountability
NOTE: If the proposal was accepted in confidence, then this section does not apply.
Every Sunday, a short progress report must be sent to the proposal submission address regarding the status of implementation, with the subject:

Proposal Report - 1/1/01: SubNick

Where 1/1/01 is the current date, and SubNick is the Subspace alias of the person or persons submitting the report.
The report should include one paragraph on the status of the implementation (more are of course allowed if needed), and below it the names of any Tasks that were completed in the past week.
	The Arbiter of Discourse will post the contents of each report on the upper staff proposal board’s thread that regards the proposal, using the same subject line as used in the email subject.  There will be no post made on the public proposal board until the proposal implementation has been accepted.
If reports are turned in late or not at all, upper staff may elect to suspend the proposal.  If a proposal being implemented is suspended, it can not become part of Trench Wars until upper staff decides to remove the suspension by means of majority vote (as defined in Section IV.d.ii).

c.	Review
When a proposal has been fully implemented, the deliverables (final product) are given or shown to upper staff.  Any main text can be submitted via the proposal submission email, and internet links to additional work, or references to arenas, can and should be included.
The Arbiter of Discourse will post all available information about the implemented proposal on the specific proposal’s thread for review by upper staff.
Upper staff has one week to review the implementation, compare it to the original proposal, and come to a majority vote decision to accept or reject the final implementation.  As this is again a subjective field, the quality of the work must be gauged from a personal standpoint to determine if it meets or exceeds the standards given in the proposal.
If the implementation is rejected, the Arbiter of Discourse will post the date and reason for rejection on the upper staff proposal board only.  The submitter(s) of the proposal/implementation will be contacted by email with the reason for rejection.
The proposal constituents may then revise the implementation, taking into account any problems, and resubmit as much as is needed in order for it to be accepted.  The Arbiter of Discourse will repeat all steps of the Implementation Review process in each case.
	If the implementation is accepted, then it goes into effect immediately, and at that moment becomes part of Trench Wars.  The Arbiter of Discourse will mark its date of successful completion at the end of the threads on both the public and upper staff boards, and the threads will be officially complete.  Upper staff will ensure that the implementation is integrated successfully into the zone as quickly as is possible.

	VI.	Appeals

Currently there is no formal appeals process for the Trench Wars Proposal System.  However, if a person strongly disagrees with a ruling made on a proposal, they may write an appeal first explaining the circumstances, and then stating their views on the matter.  It may also lend support to the argument to find several individuals to co-sign in the exact same manner as would be done on a proposal.
The appeal should be mailed to the same address as is used for proposal submission, but should begin with the heading APPEAL: followed by an appropriate description.
Upper staff will then deliberate on the appeal and make a special ruling by majority vote (see Section IV.d.ii).  A reply to the appeal should be given within one (1) weeks’ time.  If upper staff needs more time to deliberate, they should notify the appealer by email before extending the deliberation time.
While at the moment there is probably not a strong need for a formal appeals process for proposals, if it becomes a need and someone wishes to formalize it, they should write a proposal to do so and modify the way in which appeals are handled.

VII.	Miscellaneous

	a.	Special restrictions
i. 	New Leagues: Currently there are no proposals being accepted to create new leagues.  This is due to the lack of proper support, and the amount of time it takes to create a new league.

		b.	Fraud

If a proposal is deemed to be fraudulent, as defined as a purposeful and knowing attempt to deceive or mislead the proposal review team, the proposal is automatically rejected (see Section IV.e.iii.3), and can never be resubmitted.  Anyone deemed to be involved in the fraud may:

-  be banned without question for a minimum of two weeks, or on a case to case basis, longer, if upper staff sees fit.
- have their proposal submission and co-signing privileges permanently revoked.
-  be relieved of any staff positions they hold (if applicable).

Proposal fraud is counted as but not limited to: adding a person’s name as a co-signer without their knowledge; adding a person’s name to the Tasks list without their knowledge; providing false information, such as a knowingly invalid email address or purposefully inaccurate date as proposal submitter or co-signer; or co-signing two aliases from the same computer (unless a Mod or higher vouches for the accounts being owned by two members of the same family, as in Section III.h).

		c.	Duties of the Arbiter of Discourse

			The duties of the Arbiter of Discourse consist of the following:

i.	Posting all incoming proposals as new threads on the upper staff proposal board.
ii.	Performing a preliminary review of all proposals to remove badly formed proposals from upper staff consideration.
iii.	Posting results of preliminary reviews on upper staff proposal board, and posting new thread on public proposal board with results of each preliminary review attached.
iv.	Posting decisions made by upper staff on status of proposals, on both upper staff and public proposal threads.
v.	Posting all progress reports for proposal implementations on appropriate threads.
vi.	Posting implementation details/deliverables on upper staff proposal thread when received.
vii.	Posting acceptance notices on upper staff and public proposal threads when an implementation is accepted into Trench Wars.
viii.	Posting rejection reason and date of rejection on upper staff proposal thread each time an implementation is rejected.
ix.	Acting as main point of contact for any questions regarding the proposal system.
x.	Actively encouraging the development, submission, and integration of proposals into the Trench Wars zone.

	For any questions or concerns regarding TWPS, please contact your current Trench Wars Arbiter of Discourse.  If the Arbiter is not currently available, you may also contact the original Arbiter, qan, in-game.