Upgrading to Drupal 9

We are upgrading to Drupal 9! This is not a quick or easy process so you should expect this site to be temporarily out of commission at various points during this process. Please bear with us and check back with us later when we're ready to re-launch!

Site Policy

Site Policy


NOTE: Each amendment here appears with its linked proposal, ratifying it. Any amendment without a linked proposal should be considered invalid until the proposal ratifying it is found and linked here.

Starvation Mode for Departments

When a department has recently lost leads, either due to unforeseen circumstance or because the leads have been removed from position, then the department is in a starvation mode until new leads can be elected. If there are trained Evaluators available, then elections for temporary leads immediately begin as follows: If an evaluator expresses an interest in an open position and at least one other active player nominates them to the position then they are eligible for the position. After determining candidates - an election will be held to fill the position.

In the meantime, all department decisions will be addressed by a department collaboration of at least three trained storyhosts and at most five trained storyhosts for the department speaking on the topic amongst themselves to come to an agreeable decision. Any decisions that cannot wait until election may be reviewed by the newly elected lead afterwards for final approval.

Required Comment Field on Proposals

All proposals made, both at a department and site level, must include a text-area field for additional comments or clarification of the voter’s intent or objections to the proposal.

Proposal Repetition

In order to prevent abuse of the proposal system by a site member, any specific topic may be brought up to a vote at most three times. If it fails three times, it must wait for at a year before it may be brought up again. It is considered a 'dead' topic until a year has passed. A ‘dead’ topic may not be added as a sidecar to an existing proposal on another subject. A forum thread listing dead topics will be created and maintained publicly to ensure new site members who were not there for the previous conversations do not resurrect a dead topic before its time.

Creating Social / System / Setting Departments

The departments of vaxia.org and their topics of authority are as follows:

Social: The Social Department is responsible for maintaining the health of the community of vaxia.org. This includes moderation duties, interpersonal conflict resolution, communication assistance, helping newbies, creating and maintaining site and newbie tutorials and running community activities. In addition, the social department may act as a neutral party in disputes, assuming the social department itself is not in Conflict of Interest

System: The System Department is responsible for the game mechanics and overall game balance of the vaxian system as implemented in the settings of vaxia.org. This includes creating and maintaining documentation on rules, training new ASHs and keeping existing SHs trained regularly, as well as maintaining the Apprentice Storyhost Course. The system department is responsible for implementing numbers and rules for in-game elements the Setting Department has confirmed exist but is not responsible for confirming the existence of the element in the setting.

Setting: The setting department is responsible for the development and maintenance of the game settings of vaxia.org. The setting department is responsible for creating and maintaining documentation on the setting to be stored publicly in the wiki and providing training on setting details. This department also approves world-changing sessions and sagas proposed by storyhosts and resolves any consistency issues between existing plots and sessions. The setting department is responsible for confirming if a thing exists in the setting but is not responsible for implementing the system mechanics for it.

Each specific game-setting on vaxia.org has two setting leads. A site member may serve as a lead for more than one setting at a time so there will be a minimum of two leads in the setting department but they should make it clear at any point which setting they are speaking for at the time.

Newbie Helpers

Newbie Helpers are a specific subset of the social department. In order to become a newbie helper, you must pass the Social Department membership training and the newbie helper training. Access to this position is not dependent on any other earned rank - only on passing the relevant training. They are responsible for directly assisting the newest members of the site, providing player-targeted training, general site guidance, and assisting with RP opportunities to get new players settled in. The social department is responsible for creating training material and keeping newbie helpers trained.

Violating Site Policies

The Social Department is the department responsible for initial investigation and handling of violations of site Code of Conduct and the site Harassment Policy The social department may require a player to undergo additional training, coordinate a session schedule or request other behavior changes to avoid further violations. The Setting Department may also make recommendations to leads regarding revoking access for a player or removing a character from play for violations of site policy by the player if it will resolve ongoing violations. Revoking player access or removing a character from play requires 3/4ths of the current leads to approve the request based on provided evidence.

Department Forums

Forums exclusive to department members to allow for on-site discussion and decision making should be added to the site. Access to post on these forums is dependent on passing the related training course for the department. Access is not dependent on any other earned rank - only on passing the relevant training. Players are advised that spoilers may be present on the forums, and posters are encouraged to use the spoiler tag.

Qualifying Sessions

We have session reports for many types of sessions on the site. But for completion of the automated A/SH course and any other computerized measurements we need to have an idea what constitutes a session that qualifies as a session for purposes of this document. Those requirements must be measurable and automatable. They are as follows:

1) The session must have been held within the last year.

2) The session must have had two or more participating characters that are not SH characters, NPCs, or owned by the A/SH running the session.

Use it or Lose It

When you take on a role of additional responsibility on Vaxia.org - we rely on you to fulfill that role. That means we expect SH's to run sessions, Evaluators to evaluate, wiki documentation to be completed by leads, and training to be created if that is part of your role description.

But like many forms of group work it can be difficult in some groups to tell who is doing the work and who is taking up the slack. Which means, when elections come around - no one knows who to vote for and who not to vote for unless gossip has gotten around. This puts everybody into the awkward position of having to trust word of mouth for important information about the activity levels of site leadership.

A duty activity monitoring system will be publicly accessible tracking the following measurable metrics where they matter for the relevant roles. Where possible to be automated, the system will alert site membership for additional review when duties are being neglected.

1) Qualifying sessions run within the last year
2) Characters promptly evaluated within the last year vs. opportunities to evaluate characters
3) Items promptly evaluated within the last year vs. opportunities to evaluate items
4) Wiki articles created within the last year
5) Wiki articles edited within the last year
6) Responses to threads in the SH requests forums within the last year
7) Oldest unread PM at the time of viewing the monitor
8) Last access to the site at the time of viewing the monitor

These metrics will be directly and automatically relevant in the following specific cases:

1) If a storyhost has not run a session and put in a session report for it within the last three months - they will lose access to the storyhost position and must retake the storyhost course to renew. Previously run sessions that qualify will continue to qualify.
2) If an evaluator has not evaluated a character or item within 72 hours of its submission within the last six months - they will lose access to the evaluator position and must retake the evaluator course to renew.
3) If an evaluator has not run a session and put in a session report for it within the last six months AND has not evaluated a character or item within 72 hours of its submission within the last six months - they will lose access to the storyhost position and must retake the storyhost course to renew. Previously run sessions that qualify will continue to qualify.
4) A lead who loses storyhost or evaluation roles loses the lead position as well until renewed. Until renewed they are considered to have taken an unannounced vacation.

Vacation Mode and Temporary Appointments

While real life is always more important than game, by accepting a position of authority on the site you have obligated yourself to fulfill a need on site. When life does not allow you to participate, the vacation button is provided to allow you to notify the site that you will not be available for that time.

Vacations of non critical site members or short vacations of critical members may be easily handled. Long vacations of critical site members require additional steps. This is most critical for leads - as they are an elected position. When a lead goes on vacation for more than two weeks they are required to select a temporary lead from the pool of available storyhosts trained for the department. When a lead plans to go on vacation for more than two months or goes on an indefinite vacation by doing so they are stepping down from the position and an election is immediately held to appoint a replacement to fill out the term.

Not Notifying of Vacation or Not Returning from Vacation

Sometimes people go offline and they just simply don’t come back. The person may be in the middle of a personal or medical crisis or may simply have lost interest in the site. If this happens, the site must be prepared to move on. Unfortunately determining the point at which a lead left their posts is difficult at best. A computer may be able to provide some insight into the activity levels of a member - but it is not perceptive enough to determine the exact point at which action should be taken - a human needs to do that.

Any trained member of a department may request that the department go into starvation mode. If that request is seconded by another trained member of the department, the department will hold a departmental proposal on going into starvation mode for the department.

Offsite Discussions

Given our need for Transparency offsite discussions of policy and offsite decision making runs directly counter to that effort. While the initial idea generation of a proposal may occur off-site at some point that information in full must be entered into the site. The information does NOT need to be immediately publicly accessible but if you need to use it later to substantiate a grievance claim or other dispute then we need an on-site copy of it from the timeframe so that we can confirm the content.

This includes saga proposals, so that in cases of emergency (illness or unannounced vacation) we can request the technical admin retrieve relevant information for continuation of saga plots. World run sagas are not exempt from this requirement.

Official off-site communications such as a Skype meeting amongst leads should be documented on the site with meeting minutes and a summary of any decisions and actions to take next within 72 hours of the meeting. AIM conversations may be logged and added as documentation within 72 hours as well.

Offsite conversations held elsewhere but not promptly documented are not considered eligible for inclusion in grievances because in those circumstances we have no way to confirm the accuracy or the time-frame of the information provided. Again, offsite communication does NOT have to be publicly accessible so long as it can be confirmed by the technical admin in some way as being recorded from the expected time-frame: PMs and personal filespace folders are absolutely acceptable locations to make private records.

Election Process for Leads

Leads are responsible for maintaining the training documentation and course for their own lead position so that new leads may be properly trained as they take on the role. On taking a lead position, a the newly elected lead must proceed through the training course and documentation maintained by the previous lead within a month of taking the position before they are allowed to update the course with new information. Failure to undertake and pass the course within the month will remove the current lead from position and trigger an election to elect a more qualified lead to the position.

Elections will be held yearly. Qualified and interested candidates may nominate themselves for the position in the yearly election. Any active player may vote on leads. Leads are limited to holding the same department lead position for two consecutive years. This is to encourage a continuous transfer of information and documentation, to develop the skills of a lead in more than one site member, and to ensure that existing leads continue to advance their skills in a competitive environment. Previous leads are encouraged to continue to participate in the department and provide advice to the newly elected lead as needed. After two years in one position the lead may lead for a different department or refrain from being a lead for a year. After the year 'off', they are eligible for the original position again.

The first yearly election will be held within a week of this amendment being accepted.

Voting Requirements on Departmental Proposals

Department leads are required to provide documentation and training Materials for site members to learn and demonstrate knowledge of their understanding of the department needs. This allows us to track site members who have undertaken the basic training for the department. Those who have taken the training for the related department are allowed to vote on departmental proposals for the relevant department since we can confirm they are familiar with the material. Access is not dependent on any other earned rank - only on passing the relevant training.

Proposals should be marked for the one or more departments they are related to or marked as general proposals for those that do not fall under a specific department. For voting on multi-department proposals training is only required for one of the departments.

Instating Mediators

This proposal is to formally introduce a mediator position onto the site. These will be specially trained players who will assist with mediations and social duties. Mediators are the first responders to conflicts onsite. They train players who need extra Help with abiding by the code of conduct, and when players break the code or their social contracts they are often the ones who bring it to the Social Leads attention. During mediations, they are the neutral party that helps the aggrieved players work toward a solution. It is an optional position onsite, and no one is forced to be a mediator if they don't want to.

Having Mediators removes a current bottleneck in authority. Having only two people responsible for all of the training/punitive action/social duties onsite isn't desirable or practical. The mediator position will spread out the work to avoid overloading the leaders onsite.

I'd like to address an issue that came up in the forum thread so that there can be some clarification here (so people don't have to go all the way back to read it in the forums). What makes the Social leads different from Mediators? Leads still set policy and train Mediators. They handle the most difficult situations. Social Leads also have the sole authority to give instant red strikes.

Requirements of Mediators:

  • A candidate for becoming a Mediator must first have reached at least 40 HXP for their account
  • The active Mediator team will vote to approve any new candidates for becoming Mediators. A 75% majority is required to approve the addition of a new Mediator to the team.
  • Starvation mode would be when the Mediators have less than 4 members. When this occurs, getting the minimum percentage of votes can be more difficult. In order to move quickly, a vote of the Social department Leads can supplant the normal Mediator team vote, but only in this case. Both leads must agree in order to approve new Mediators during starvation mode.
  • Mediators are empowered to award Notations and even Yellow Strikes, the latter of which must be reviewed and approved by at least one Social department Lead before becoming final.
  • If a Mediator is found to be in abuse of power, confirmed by the active Social department Leads, the punishment is an automatic Red Strike and all the associated restrictions that entails.
  • If a Mediator is the recipient of a Yellow Strike, they will lose their Mediator privileges and title immediately and for six months from the time of the incident, at which point they can re-apply by re-taking the Mediator training and exam and awaiting approval by the team as though they were a brand new mediator.
  • If a Mediator is the recipient of a Red Strike, they will lose their Mediator privileges and title immediately and for twelve months from the time of the incident, at which point they can re-apply by re-taking the Mediator training and exam and awaiting approval by the team as though they were a brand new mediator

Removal of a Separate Evaluator Role

All references to the "evaluator" role in the Site Constitution are retroactively amended to the Storyhost role instead. All Storyhosts are now evaluators, and there is no separate evaluator role. The SH role is the prerequisite of becoming a Lead, rather than the evaluator role. SHs no longer gain a 3-month reprieve for having evaluated characters or items under the "Use it or lose it" section of the site governance.

Double Jeopardy Clause for Site Grievances

In order to avoid subjecting a player to multiple punitive actions for the same incident, we will not review an incident a second time after the initial incident has been reviewed. Any punitive actions to be given to any involved players should be given at the time of the initial review.

Once an incident has been reviewed by the Social Department for Code of Conduct violations or has been reviewed in the course of resolving a Grievance, the incident will not be subject to a second review unless new evidence relevant to the original incident has been submitted, deemed relevant by the Social leads, or the Grievance coordinator, and verified by the technical admin.

Players addressed or not-addressed during the initial review may not be subject to additional punitive actions unless additional evidence has been provided and a second review has been initiated.




Site Constitution

NOTE: The Site Constitution and initial Amendments were voted on in Spring 2014 by a majority of active players at the time. Everything here is copied directly from the voted-on proposals which should be on record in the site's archives for comparison.


Given the current age and History of the site, we need to start planning for the long-term.

In the many years of Vaxia’s growth, we have had many different approaches to handling site decisions, but we have often relied on memory and convention, or the decision-making of the server owner (or loudest member) of the site. We haven't had much of this written down. While overall this has gotten us along, it hasn’t been without many bumps, pain, and leaps of faith. But where memory is unreliable, open to interpretation, and generally malleable to the personal needs of the most convincing voice in the discussion - words are not. Which is to say:

If it’s not written down, it doesn’t exist.

The goal of this document is to write down a formal structure for vaxia.org’s continued site administration to provide for the coming decades. Ideally we will never have to rely on this document to secure the health and safety of the site - but there’s always the chance and we can’t predict the future.

Guiding principles

Guiding principles should be used as guides to decision-making in the future. These are the overarching principles that take precedence over any department, storyhost or individual decision. If a site decision is in violation of the guiding principles then that decision should be reviewed and adjusted to bring it into agreement. If that is not possible, then the decision should be reversed.

The Three F’s

The “Three F’s” are the goals of our decisions on the site. In order, they are “Fun”, “Freedom” and “Fairness.” Ideally every decision on the site will incorporate some aspect of all three of these principles. Realistically, not every decision is going to be able to do that. Where possible, err on the side of “Fun” for the most people, followed by “Freedom” for the most people, followed by “Fairness” for the most people.It is important to note that the principles of Fun, Freedom, and Fairness are judged based on their impact on the majority of the site - not by the impact on an individual.


Fun is a measure of the general enjoyment of the site. This is not purely a matter of players enjoying the material produced on the site, but also more measurable aspects such as the overall difficulty to learn and rule the system, the impact of technological limits on play, or the feeling of being safe on the site. What is fun for one person is not necessarily fun for another, nor will it continue to be fun for all time - decisions based on fun need to consider multiple viewpoints and the long-term impacts of decisions made.


Freedom is the ability to act on the site as you wish, so long as you don’t unduly impact another’s freedom or fun in the process. Freedom includes the ability to be allowed to fail as well as the ability to be allowed to succeed. Other elements of freedom include being allowed to ask for advice and assistance out of character, and having a minimum baseline of support for the play of characters regardless of the character's specific aspects such as evil alignment or other concept-based choices. Other characters are free to welcome the play of a specific character or not as the case may be. Not every decision is going to be able to avoid impacting an individual, but again multiple viewpoints and the long-term impact are critical.


Fairness is the out-of-character understanding that your work and efforts are just as valued as those of any other member of the site. Fairness is found in system mechanics that are overall balanced for cost of experience vs. payoff, observable means of making site decisions, and being able to have the same opportunity to contribute to site efforts. Fairness does not guarantee success though it should guarantee equal opportunities to succeed. Characters may experience IC unfairness, players should not. Again, this principle is best applied with multiple viewpoints and long-term impact.

Transparency Transparency is understanding that, wherever possible, we act and speak in the open. Conversations should be logged and recorded on the site. Verbal meetings should have meeting minutes. Decisions, and what was said during the course of those decisions, should be publicly available for review afterwards wherever possible.

Secrets prevent site members from being able to judge the worthiness of a potential-lead during elections, creates an environment of mistrust around those who have off-site communication, and generally encourages deceptive behavior in both those in power and those not. In order to safeguard the health (both mental and social) of the community and our long-term continuation, we must operate in the open as much as possible.

In general, all concerned parties should be able to participate and review the process of decision making in order to fully understand both the considerations that went into the decision and the choices of the decision makers involved.

Not all discussions are appropriate for a completely open discussion, though the option should always be considered first. For example: A personal dispute between two players may be best held in private, through both players should be involved as they are the concerned parties for the situation.

Origin of Power

Without players we don’t have a site. And we have no right to take from players what they are not interested in giving. They are people and they have rights. To add any new power or privilege for the site, a given department, or site representatives not already described in this document, the players must first agree to give that power through the systems described in this document. Any powers not specifically granted to the site, its departments, or its representatives in this document are assumed to be retained by the individual player.

Roles and Responsibilities

Roles are a defined set of powers and responsibilities that a player on the site may have. They are not considered to be exclusive of each other. Like hats, you can have more than one role on the site. However, at any point where there may be confusion a member who has more than one role should make it explicitly clear which role they are speaking as at that time. You cannot serve in more than one role for the same decision.

For example - if a setting lead is building a major saga, he is doing so in his role as a storyhost, which is why he must get the approval of another setting lead to approve the saga. He cannot serve as both storyhost and lead on the same decision.

The following roles are acknowledged on the site. An individual can hold one or more of these positions simultaneously:

Inactive Player
While there are also inactive and sporadic players with accounts, they don’t often participate in the community IC or OOC. These are accounts that are still on the site but have not been used - players who have left the site, or have not been able to return for an extended period of time. An inactive player cannot also be an active player. An inactive player had not participated in the site community within the last six months.

Active Player
Your average site member. An active player cannot also be an inactive one. A player has created a character and has posted on the site. An active player is a site member who has participated in the site community within the last six months. Some players are not currently able to roleplay due to personal circumstances, so having roleplayed recently is not a requirement, but if they have posted in the OOC rooms or on the forums they are still participating in the site and are active members. An active player may create site proposals and participate in them but has no additional responsibilities on the site.

Apprentice Storyhost
An apprentice storyhost must also be an active player. An apprentice storyhost is a site member currently in the process of training to become a full storyhost. An apprentice storyhost creates content under the mentorship of storyhosts, and actively develops the setting and system to fulfill the needs of the players. An apprentice storyhost is responsible for Running Sessions and proactively developing plotlines for characters. An apprentice storyhost is also responsible for actively attempting to progress through the course to become a full storyhost.

A storyhost must also be an active player. A storyhost is a site member who regularly runs sessions for players every three months and creates content. A storyhost creates content, runs sessions, proactively develops plotlines for characters, provides input on the sagas of other storyhosts, and mentors apprentice storyhosts. They are also responsible for contributing to department projects for their relevant skills and increasing site membership and storyhost membership. Storyhosts actively develop the setting and system to fulfill the needs of the players.

An evaluator must also be a storyhost. An evaluator is a site member who has received the additional training and responsibility to fulfill additional duties for departments, such as the ability to approve content flagged by the system as needing additional review. Training and testing Evaluators is a joint effort by all departments to ensure they have a complete understanding of duties from multiple perspectives.

A lead must also be an evaluator, this is to ensure the lead has a complete understanding of required tasks. A lead is a leadership position for a department. A lead takes a primarily reactive role, responding to questions, requests for guidance, and assistance as they arise. A lead is responsible for resolving topical disagreements between storyhosts when it comes to questions regarding the topic their department handles. A lead is also responsible for maintaining training and documentation for future leads. All other department work to create and curate content is handled under the storyhost role. A lead can (and should) actively participate in the department in that role.

Technical Admin
A technical admin is not required to be a site member. The technical admin is there to provide technical and logistical services related to the hardware and software of vaxia.org. The technical admin provides technical advice according to site needs as outlined in this document and any future proposals and amendments and is otherwise uninvolved in site governance in this role. This is primarily a reactive role to site requests and a proactive role to server and system security needs.


Departments are a collection of trained active players, led by two leads, that address specific needs for the site and players within an assigned topic. Individual site members may be members of more than one department, but a lead may only serve as a lead for one department at a time.

Each department is considered a peer and equal to other departments on the site and within their assigned topic the department is allowed to make additional policy and decisions on that topic provided the policies do not violate the guiding principles outlined in this document. Departments do not have authority outside their assigned topic.

Departments are led by two leads, who are responsible for stepping in for each other when the other is unavailable or in a Conflict of Interest position. They are also responsible for resolving topical disputes within the department, defining and providing training for site members who wish to participate in department projects and votes, and defining training and documentation for future leads of their department.

Where a topic bridges two or more departments, the department leads and department members should work together to address their parts of the topic to create policy that addresses the needs and concerns of all involved departments.

Departmental Proposals

Proposals are a formal suggestion to a department to change a departmental policy or ruling and may be put forth by any active player. This proposal is announced to all and must be available for review and voting by all department members for two weeks before it may be considered agreed upon by the department.

During that two week window the proposal may be updated to address specific issues noted by reviewers. If issues are brought up then effort to account for the issue should be made and changes if needed made to the proposal. The two week approval window is automatically extended from the moment of revision for another two weeks to allow voters to change votes in light of new information.

At the end of the two week window, the results of the proposal are made visible. If an objection still exists, mediation by the appropriate lead(s) may be attempted.

Mediating within a Department

This process is meant to address disagreements regarding the department’s assigned topics - disputes of fact not personal disputes between department members. This process is intended to provide a structure for departments to handle the day-to-day needs without overwhelming the department leads with minor requests.

When two department members disagree on a departmental topic matter they should first attempt to discuss the situation between themselves and find a mutually agreeable solution. If that fails, the department members may then turn to others in the department for assistance in coming to a mutual agreement. If that fails, they may turn to the leads for the department for the relevant topic. Before entering mediation, the situation must first be attempted to be resolved and two or more possible outcomes defined for the leads to consider.

Once a lead has been called to make the decision, all affected parties agree to accept the decision of the department lead where the decision is not in violation of guiding principles.

Leads are obligated to consider the available outcomes first before they may create another option to resolve the conflict. They must show their process of thought, and the logic used to determine it should be included in the decision writeup so it may inform any future decisions and ensure that Transparency has been maintained. The decision is only considered finalized once the decision writeup is put into the wiki for record keeping.

Conflict of Interest

Oftentimes, Conflict of Interest is something people do without realizing it out of an instinct to be kind. While it can be dangerous, it is often not malicious, and it is very important to keep that in mind. As a social community, conflict of interest will naturally grow amongst friends.

Because site members may have more than one role, they may easily find themselves in a position where they are making a judgement on a situations which will affect their role on the site or affect one of their characters, or the players or characters of a close friend, family member, or relationship. Likewise, bias good or ill may exist between site members for past actions, decisions or rulings that need to be accounted for.

In those situations, the site member is considered to be in conflict of interest. Being in conflict of interest does not automatically render the site member unable to voice opinion or observe the ruling on the decision, but it does mean their bias needs to be taken into account when it comes to making a decision on the situation.

In these cases, a separate neutral party should be involved to assist in the situation even if under normal circumstances they would not be called on. For example: A departmental policy that does not normally call for outside department input, or a lead decision in which one of the leads is in conflict of interest may require another member to step in. The neutral party should be agreed on by the members in conflict, but if that is not possible they may be requested by members of the department not including those in conflict of interest.


Sometimes problems are just too large to handle within a single department, the department leads may not be trusted with the decision or other signs of significant leadership problems may exist. While a department may have authority over the topic involved - in some (hopefully rare) cases - a significant grievance must be addressed on a level outside the department to handle issues of Conflict of Interest or abuse of position.

Process of Resolving Grievances

When a situation has risen to the point where a grievance needs to be addressed outside of the department, there is a process any site member may follow to request the situation be addressed and resolved.

1) The site member with a grievance that falls under violation of guiding principles should go to the Anonymous Mailer
2) At the mailer they may freely describe the grievance and must give specific evidence.
3) Wherever possible, citation of department policy and violations of the systems outlined in this document should be provided.
4) Any violations of the guiding principles should be specifically noted when the grievance is lodged.

Conversation about the grievance should be held in public, any question of the credibility of a site member’s position on the site innately involves the entire site and thus the entire site is an "involved party." Site members in conflict of interest situations (including any specifically named members) are allowed to contribute to discussion but not vote on the resolution of the issue itself.

After discussion, when a solution to the situation is presented then a standard proposal, including the two week window for voting will be used to resolve the conflict. Voters may choose from the paths of resolution provided during the discussion, with an option to fill in an optional resolution of their own if none of those provided are satisfactory. It is possible for a solution to simply be a statement that the grievance is not valid - and this solution should be included as an option on all grievance votes.

At the end of the two week window, the results of the vote are made public. In order for the solution to be accepted, a simple majority of players active within the last two weeks must particulate in the vote to ensure the vote reflects the opinion of enough people on the site to be trusted as a valid opinion.

In order to approve a solution, after participation requirements are met, the solution must be approved with a 3/4ths majority of the votes cast with the following exception: When votes cast are below 10 (after accounting for participation requirements), then simple majority is used instead due to the small population size involved.

In the case of an unclear result further discussion and additional proposals will be required until the situation is resolved. While under review, the subjects of the original grievance (as well as anyone in a conflict of interest situation with them) may continue to act as a member of their position.

However, if the voting results in a removal of a role or limitation of power, decisions made by the involved parties during the span of time since the original grievance was entered may be reviewed with further scrutiny or rolled back entirely under the judgement of the department or as a secondary proposal.

Role Removal

If a site member holding a role of authority (apprentice storyhost, storyhost, evaluator or lead) does not abide by the decision of grievance vote or if the site votes to have them removed from position, they will immediately lose the role in question and associated powers. Related roles may also be reviewed and potentially revoked as well depending on the nature of the original grievance. In such a case, if the site member held a critical position on the site - such as a lead - a special election will be held for the new position.

Starvation Mode

Vaxia relies on it’s population of players and storyhosts to keep alive. Sometimes both can be hard to locate. In thin times, the site will operate under an extraordinary circumstances mode called “starvation mode”. While in starvation mode efforts to increase the population of available site members to address a need for storyhosts, Evaluators or leads are a priority - the sooner critical positions are filled, the sooner the site may return to standard behavior.


The members of the current site cannot hope to imagine the needs of the future site, be it in a time of strong growth or dormancy. With that in mind, this document may be updated at any time with amendments. Amendments are a type of proposal that is a formal suggestion to active site members to change the behavior of the governing structure as outlined in this document and it's amendments at the time of making the proposal.

The new amendment is announced to all players on the site and may be put forth by any player. It must be available for review for two weeks for feedback, review and updates. If updated, the two week window is extended from the moment of revision for another two weeks. During the two week span, all active site members may vote on the new amendment.

At the end of the two week window, the results of the vote are made public. In order for the amendment results to be accepted, a simple majority of players active within the last two weeks must particulate in the vote to ensure the vote reflects the opinion of enough people on the site to be trusted as a valid opinion.

In order to approve an amendment, after participation requirements are met, the amendment must be approved with a 3/4ths majority of the votes cast with the following exception: When votes cast are below 10 (after accounting for participation requirements), then simple majority is used instead due to the small population size involved. This is to ensure that the system described in this document can continue to operate at critically low membership levels - effectively 'starvation mode'.


Continue to our Amendments list for updates to this constitution





"Transparency is operating in such a way that it is easy for others to see what actions are performed."

This means for the most part: In public. In writing. Openly.

Why? Because this keeps us honest, it increases the trust of our player base and storyhost base, and generally it keeps us on our toes. A bad idea will get punctured more quickly. A good idea will get support more quickly. Transparency isn't meant to be used as a weapon, it's meant to be used as a sanitizer - sunlight to make it clear and obvious that all those acting are doing so in good faith.

Which isn't to say every single little thing needs to be handled in the open. Personal disputes, SH saga negotiations, inter-player resolution - all of these things can be handled privately as needed. The concerned parties are already in the room after all.

Where things need to be transparent is when the concerned parties are the entire site. Criticism of leadership is a public concern (as is praise!). New rule handling, or modifications of site policy - all are public concerns. While the initial germination of an idea can be handled privately, at some point the work needs to go public, for both public review and public accountability of the decision makers involved.

Public review means: Not on AIM, not on email, not on PM. In Discussion room isn't a public enough location, and chat scroll could effectively erase the conversation from view. Public means, in the forums.

Wiki Main : Go to Wiki Main Page
Site Policies : Go to Site Policies Main Page

Subscribe to RSS - Site Policy