Story Team Processes

[squakhawk 14043]

Story Team Processes

 

What is it the ST Sects do exactly?

 

In an effort to increase transparency on the functioning of staff teams, along with providing some insight into how various things work on Story Team, we’ve decided to provide the following to give an overview of the general processes ST and its various subteams carry out when performing their work on the server. This is by no means exhaustive, and prone to slight shifting as needs arise, but should still provide a good idea of how our teams function. The sects go as listed below.

 

 

Story Lore (Lore Team, LT) - Primary duties of Lore Voting, MArts, Amendments, Sreqs, Lairs, Lore Enforcement, and Lore Applications.

 

Story Event (Event Team, ET) - Primary duty of conducting and acting in Events. Some ET may specialize into single-roles of lore sub-teams or builder.

 

Story Build (Build team, SB) - Primary duty in build requests set up by the story team, story admin, other staff teams, autonomously, or by the player base (under specific circumstances).

 

Loremasters (LM) - Advisors to The Story Admin and Story Management regarding large implications in upcoming lore or events.

 

Story Administrator (Story Admin) - A representative of Story Management to the administration.

 

 

---

 

 

The Lore Team

 

The Lore Team, commonly referred to as LT, generally handle a number of tasks which range quite a bit. There are:

• Reviewing and voting on lore 
• Handling lore applications
• Handling story team tickets (/sreq’s)
• Investigating issues pertaining to lore enforcement

Each will be described in greater detail below:

 

Lore Reviews and Voting:

Almost any time lore is submitted, it goes through the following process.

It is given a very quick look by an acting Lore Manager to ensure that it is not something which falls under the umbrella of ‘Bad Lore’ - concepts that are deemed inherently difficult to implement in a way that results in fun and interactivity for everyone involved, hinges on things that are very difficult to balance around fairly and consistently in our Minecraft medium, or is otherwise ill-suited for lore being related to it. It is not that these are uninteresting or lame ideas, just things that cannot be done well on the server in current times. See

Some pieces, such as Creatures, are automatically passed with certain guidelines. Others, such as lorepieces submitted which dont quite fit in the LOTC universe or are written far below modern lore standards, are denied with some pointers and explanation given to the writer. 

After this initial look, a submission is then categorized as either an amendment (smaller / minor things, like a single adjustment to a single spell in a larger piece) or something worthy of a full review and voting.

 

Amendments are posted in a channel specifically dedicated to them, where LT who review them can take a look and give either their approval or disapproval of said amendment, with any open discussion about them being done in another channel. Once a sufficient amount of votes have been cast, the amendment is then either implemented into the main lore post it was submitted for or denied. This is aimed to get done relatively quickly.

 

For lore which is deemed to necessitate a full review and vote, it is added to a “loremag”. The way loremags function is as follows:

 

• When a previous mag has been completed, a new mag will be posted. These mags will generally contain 4-7 lore submissions that LT are asked to review and vote on. These reviews are intended to ensure the following (where applicable):
  • There is some form of in-universe lore backing for how this lore exists / functions
  • The things offered by a lore are balanced properly, fair, and sufficiently clear in mechanics and function
  • There are no other apparent issues present
     

Reviews are able to vote on each lore submission within a mag, their potential votes being:

• Y - good as is, ready for implementation on the server
• Y + !!! - good, but has some edits that should be made before implementation
• !!! - indifferent, not necessarily bad, but definitely needing some changes to it
• N+!!! - ill-fit for implementation, requires some serious changes, rebalancing, or reworking before it can be considered
• N - No, bad fit, inherently flawed, or not done well enough to justify further consideration
• A - Abstain, biased. Usually for people who have some vested interest in the lore submission itself or related submissions (ex: the writer of one cleric submission cannot cast a vote on a different cleric submission), but still wish to provide feedback. They can help point things out regarding background, balance, etc., but their vote does not impact the acceptance or denial of a lore
• C2A - Call to action. Reserved for rare cases where, despite potential issues with a submission, for the good of the community it may be advisable to push it forwards anyways
• Other - exactly as it sounds. Other, if for whatever reason a vote does not properly fall into any of the above vote types

 

• Once enough reviews and votes are collected, a Lore Manager reads the piece themselves, goes through the reviews, and compiles the feedback into a single document along with the votes received. This compilation is then sent to the individual(s) who made the submission, with instructions on what should then be done (usually making edits based on LT feedback, sometimes doing that and resubmitting for another review, etc).
• LT are unable to vote on any lorepiece they’ve previously proofread, worked on, or may stand to benefit from. Further, an LT who may have a vested interest in a lorepiece not passing for any non-objective grounds is unable to vote. Should an LT who pass by both these criteria find themselves biased still, they may still submit feedback with an A vote. Should a manager find an LT’s review to be heavily biased or nonobjective, their letter vote may be changed to an A vote. 
• This feedback is only available to the lore writer, and is an amalgam of the general consensus of LT feedback. If LT feedback was misconstrued, misread, solved in another place in the lorepiece, or otherwise invalid/unnotable, it is not included in the compiling draft.
• Once an entire mag has been completed, a new one comes in, and the process is repeated. This happens ideally within 1-2 weeks.

 

Some things to note:

• MArts go through a process much the same as normal lore submissions, though are handled by fewer individuals and are evaluated on slightly different criteria, namely: How well the MArt fits within the themes of the magics/lore being used for its creation, if there are any balancing concerns, and any other concerns or feedback that MArt reviewers may have. MArts are compiled and sent to their submittors in the same way normal lore submissions are.
• Members of LT cannot vote on their own submissions should they submit any lore. This also extends to contributing to lore submitted by other individuals in most capacities.
• Most lore is not submitted by LT - in general, few LT actually do much lore writing. They just work to ensure that the lore which is submitted and made active is held to a standard, is balanced, and fits properly on the server - not much lore is written internally with express staff support. That said, there is some lore which is handled and written internally. These pieces generally concern larger backend things such as deities, world lore, or relate to planned wide-impacting eventlines.

 

Tickets:

LT handles the majority of story requests made, as most of them relate to the signing of items or structures, updating of MAs/CAs/TAs, or are asking questions about the lore. Some tickets may take longer than others depending on the request or question, but most tickets are able to be handled by most LT, though often members will allow LT who are better versed in a lore area than they may be to answer questions or handle tickets from it. 

 

Enforcement:

When lore issues are reported (powergaming, redline breaking, etc.), LT on enforcement will note the issue in a channel, collect both evidence provided and evidence able to be found, and go about doing whatever other work may be necessary to determine the facts behind the issue.

This is an impartial process, though nuances are considered when and where appropriate, as issues can range widely. Due to such a range, there is no one singular ‘process’ by which issues are handled aside from collection of evidence and deliberation about what should be done. Unlike moderation, there is no single sheet of infractions and related punishments on a scale due to the complexity and nuance of lore, and how severity can range from harmless to catastrophic.

When a conclusion is reached, parties involved will be reached out to as necessary to inform them of the issue and whatever the consequences of it may be.

 

Lair Reviews and Voting:

Lairs are submitted by the Story Administrator or a Lore Manager to be voted on by a team of voters for lairs. Players who may have a special interest in a lair (member, adjunct player, or of any "oppositional faction", are discounted from lair votes and removed from the chat. Lair approval requires 2/3rds of voter majority and story administrator approval. Lairs are submitted and within three to seven days have voting closed; voters must provide feedback as to why they are voting to accept or deny a lair or their vote is discounted. Feedback is open discourse in the chat, which is logged and wiped with lair votes which may have ST with special interest before they are re-added to the chat. 

 

Lairs are judged on a variety of factors, though most heavily based on their application criteria (See Lair Rules and the Application for more information). Primarly after this, lairs are judged based on whether they already are/have a cohesive group (in essence, to prevent putting the cart before the horse on a settlement before a group is even roleplaying), if the group has not attempted to / cannot get land under a nation, if the lair members are a part of other groups/lairs, and if the group's purpose requires it to have an independent stature of land. Lairs as well have build requirements, although fairly lax, to ensure a solid build is prepared or in vision to make sure the group fits into the world well upon establishment. 

 

In total, lairs are meant to be a base of operations of last resort - a group that requires a base of somekind and cannot by any means acquire land elsewhere, or is culturally distinct enough to require its own place of settlement. Lairs however in this regard, strictly do not function as micro-settlements - lairs are designed to be not a tier down from nations, but a separate entity entirely. Groups which hold no claim to hide, actively promote as a settlement, and function similarly to a nation rather than a guild or order are unlikely to be accepted.

 

 

 

---

 

 

Event Team

Event team (ET), as the name suggests, handles ST events on the server. The process by which events come about is relatively simple.

• Smaller events or one off occurrences are generally free game for any ET member to do. Oftentimes these are just for fun type things, and will provide either a neat trophy item or item of extremely limited mechanical use as a potential reward.
• Larger events or longer eventlines require ET to submit a form detailing an outline of their event, what groups will be involved with said event, and request approvals for any ST materials to be handed out in the event. Additionally, character artefacts (CArts) which may be rewarded must go through a round of submission, review, and approval before they can be given to characters in an event. These CArt submissions are done internally by management.
• Further Management and/or ST Administration Approval may be required for eventlines involving or affecting large amounts of lore, such as events concerning deities or world lore. Oftentimes events which do such are prepared by management and ST administration internally rather than being left open to all of ET.
• Sometimes when there may be a large world event, some ET may retract from running events proactively, and may act instead as Actors within these larger events. Conversely, when events such as the Map Antag or Midmap Antag occur, ET may be barred from running unrelated events.
• On occasion, ET may forego utilizing ST Build requests and may build their own event locations.
• On occasion, ET may receive approval from management to commission skins from the playerbase for mina paid out by ST Management. 
• ET are unrestricted in their capacity to run events so long as they are run by managers for quick approval. This includes what playerbases an ET may cater their events towards. However, should an ET be found highly impartial, or extremely giving to one playerbase they may stand to benefit from, they are reprimanded accordingly. ET do have some mild restrictions on what they may do events about specifically, strictly for quality control purposes.

 

 

---

 

 

Build Team

Build Team, or Story Builders, provide a number of different services to the server. They primarily handle making builds for use by Event Team members in their events, which can range in size from small creatures to entire settings and set pieces. In addition to this, they sometimes may assist with cleaning up the world (landscar removal, terrain improvements, road building etc), or sometimes handling tickets from players who are engaging in something requiring changes to be made to the world (area of effect rituals, for example). Rarely, they may be tasked to focus on improving areas of the world, or overhauling areas to better align with world lore or events. As well, Build Team is a critical role in the development of new maps for the server, providing the groundwork for the fine detailing of new environments.

The general process Story Builders do their work is as follows:

• An Event Team member will post a request in a staff channel detailing what they need built, when they would like it built by, references for the build, and other useful information.
• A Story Builder will react to the request to indicate they are Accepting it and will work on it.
• Once completed, the Story Builder will react to the request again to indicate it has been completed.
• After completion, roughly every month the Build manager (Or Story Admin) will payout mina costs based on an aggregate of effort, time taken, complexity, and player presentation.

Additionally, it is possible that Story Builders may find their own work in the form of the aforementioned matters of landscar cleanup, terrain improvement, and similar things, and denote their work in this channel as well. Intermittently or entirely solo, there may be a request by build management to build certain assets such as dungeon tiles, beasts, buildings, and so on for further use. A build team member may provide these assets autonomously and log them as well.

 

 

---

 

 

Loremaster

Loremasters are a subsect of ST that answer directly to the Story Admin itself, though hold no factual or written process. Loremasters function as both spiritual and literal guides for the team, functioning to help in defining higher end or older lore which may be incomplete, unknown, or insufficient. Loremasters do not interfere with lore or events without approval from either ET management or The Story Admin, though they may guide their own eventlines or write their own lorepieces if it betters or clarifies server lore. Loremasters hold no sway over the passing or denial of lorepieces, and serve explicitly and single handedly as an advisory role on lore or events with large implications.

 

 

 

---

 

 

The Story Administrator

The Story Admin, more or less, is a representative of Story Management acting on their behalf to the administration. Story Team, unlike most other teams, functions very collectively in its roles - often team members intermingling with other subsects as they get better at their tasks, or their passions change. A Story Admin, outside of maintaining a vested interest in the server vision and story team’s vision first, too is beholden to Admin Approval. Amended in January 2026, Admin Approval is a process that occurs in which the Story Admin must submit certain items or actions for approval before actioning them. With some changes from the administration, this mostly occurs with large, sweeping changes to the map, to lore, or how either may affect players. Such is listed below.