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!


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.