Lore Staff Guidelines

General Guidelines

• All members of lore team are expected to be active. Activity requirements are to be met in a composite of interaction with the community and fellow staff on discord, the forums, or the server. Large lapses of on-server play may be forgiven if there is a sufficient amount of lore writing and community interaction. Inactivity is determined at the discretion of lore team administration, however unless a team member has ghosted from server play for months of time and has not maintained any significant community or team interaction, a member will generally be considered active enough.
• All leaves must be preceded with prior notice to lore team administration and the lore team. If a team member is going on leave they must notify the lore team, as well as ping or private message lore team administration with notice. Explanations for going on leave are not required, however a general estimate on when a leave is ending must be provided if available. If a lore writer goes on leave their duties are handled by lore team management unless otherwise delegated to relevant lore deputies. If the loremaster goes on leave, the deputy loremaster will assume the duties of lore team management in their absence.
• When submitting content to the wiki, you are still bound to the Wiki Staff Guidelines.

Whitelist Management

Granting a Whitelist

Whitelists may only be granted following a whitelist application process, unless special permission for a specific case has been granted by lore team administration. However, lore team administration may never grant itself special permission to dispense whitelists, even in the case of a lore writer vacancy.

Processing Whitelist Applications

Discretion on whether to accept or deny a whitelist application rests with the writer for the relevant lore department. Applications may be accepted or denied entirely at a writer’s discretion. For best results, a lore writer should carefully check the application against any relevant wiki pages and take feedback in an application thread into consideration. A race’s main wiki page should contain all of the relevant core content required for a whitelist application. If an application has any work which contradicts other wiki pages under the care of a lore department, the applicant should be worked with to bring their application in line with the overall lore instead of denied outright. Once an application is accepted or denied, a tag should be edited into the title saying either [Accepted] or [Denied]. The thread must then be locked and moved into the whitelist applications archives.

After an application is accepted, in order to grant the whitelist you must log into the web interface at https://byond.aurorastation.org/ and search for their ckey in the players category under the admin tab. Once you have found their profile on the web interface, click the “add whitelist” button next to the relevant whitelist. A general best practice is to discuss the contents of an application with the applicant and provide the opportunity to correct for any discrepancies before making a decision. An application must stand for a minimum of 24 hours before a ruling on the application can be made. This is in order to provide time for feedback to be posted on the application. An application must receive input from the relevant lore writer within 72 hours. If you need more time you must say so in the thread along with a tentative self-imposed deadline on when a decision can be expected. Discussing the application and any possible issues with the applicant, demonstrating active engagement with the application, provides flexibility to the deadline by which the application must be decided on. If no input from the relevant lore writer is forthcoming after 72 hours, the applicant may reach out to lore team administration.

Multiple requests will be issued to the relevant lore writer until they do something about the application. Failure to handle the application will result in lore team management handling the application at their own discretion. The results of an application being handled at lore team management’s discretion is that the decision cannot be grounds for reversal and whitelist granting or stripping. The decision is final and the whitelist can only be stripped through violation of whitelist expectations over the course of play, or granted through another application. In the absence of a lore writer in a lore department, the lore team administration must handle the whitelist applications or delegate it to a relevant lore department deputy. 

Applications that find themselves being denied due to administrative actions, lack of display of the knowledge of a species’ lore, or any other reason must wait a certain amount of time before applying, chosen by respective species' Lore Writers from the following: three days, a week, two weeks, a month, and two months. The initial denial of an application cannot be extended beyond two months. It must be reapplied upon the denial of the reapplication should behaviour not have improved, or not displaying adequate knowledge of the species’ lore to the expectations of the species’ respective Lore Writers. It is within the jurisdiction of the species’ respective Lore Writers to set additional requirements for reapplication, outside of the prescribed time constraints. A species’ Lore Writers may deny an application due to information that has remained confidential to the wide public. In such cases, the specific behaviours which should be improved should be discussed in private, if they can be improved upon. If a player believes they are being denied for unfair reasons, they are entitled to lodge a staff complaint against the denying staff member(s). If a time constraint regarding reapplication was issued by a Lore Writer that is no longer on the Lore Team, it will persist until the allocated time constraint has been completed.

Stripping Whitelists

Whitelists are for managing the quality of roleplay of whitelisted races. If the quality of roleplay a whitelisted player engages in is contradictory to the lore of the whitelisted race, or demonstrates a lack of understanding for the whitelisted race’s lore, their whitelist may be stripped. To remove a whitelist log onto the web interface at https://byond.aurorastation.org/ and search for their profile in the players category through the admin tab. Once you have found their profile, click the “remove whitelist” button next to the relevant whitelist.  For a best practice, a whitelist must never be stripped without good reason. Warnings should be issued prior to stripping a whitelist to allow for correction in their behavior. The amount of warnings before stripping a whitelist is at the discretion of the relevant lore writer. Keep a log of warnings issued to whitelisted players for accountability to lore team administration.  For conduct which is especially egregious, a whitelist may be stripped without prior warning. For proper guidance on handling whitelist management, consult lore team management when unsure. Stripping whitelists without appropriate cause may result in disciplinary action. However, lore team administration should be lenient and handle these situations on a case to case basis. 

News Articles

There are a variety of news organizations in the galactic news database on the forums. Articles are an important feature of living lore and let us tell stories and arcs in real time by providing everyone with in character news updates from around the setting. These serve as important storytelling tools which the whole server can read. When writing an article, the content of a news article can be anything from war reports, political and economic drama, sports news, advances in technology, or even dramatic retellings of events that occurred on the server. While the writing can be just about anything a writer chooses, here’s a few key things to keep in mind when writing an article.

1. Only write articles for news agencies which are under the jurisdiction of your lore department. If you are a deputy, make sure your direct superior approves of your article before posting it. If you are writing an article which is under the jurisdiction of another team, first get their approval before posting your article. EXCEPTION: Mendell City and Tau Ceti based channels are a common area for the whole lore team. However, any articles submitted to these channels must be reviewed by lore team administration.

2. Respect the formatting and voice of the news channel you are writing for. Most of the news channels in the galactic news database have a specific formatting and bias associated with them. If a channel has a header in all of its articles, include it. If it's formatted in a specific way from dates and times to spacing or even font, use that as well. If the channel is biased or written in a certain way, maintain consistency by keeping that same “voice.” While these can and have changed over time, it should be done with careful consideration, and should never be done by deputies or other departments without the approval of the relevant lore writer.

3. Never use news articles as a vehicle for retcons. When writing an article, make sure to carefully read any relevant previous articles to ensure retcons or contradictions do not occur. Articles are the highest visibility form of lore writing off-server, and contradicting previous articles may cause great confusion with the news reading community. 

4. Coordinate with relevant writers when writing your articles. If you article prominently features another department’s race, you must gain their approval before posting your article. This is to ensure that their race is portrayed appropriately and consistently with that writer’s canon and does not contain contradictions. In general, you want to coordinate with any interested lore team members as much as possible using the coordination channels. This way you can gather as much feedback as possible and improve the consistency of our lore. When articles consist of large arcs or major changes to the setting, you must get the approval of lore team administration before posting it. Examples of these would be starting wars, major changes in international politics and trade, changes in national leadership, the larger galactic economy, or the destruction of major planets.

5. All edits, changes, or deletion of past articles must be approved by Lore Team Management. This is important for quality control. If previous articles must be tampered with or even archived and removed from circulation to facilitate changes to lore, they must be approved by lore team administration as an important check for the far reaching consequences it may have on our shared lore setting. 

6. Lore Team Management reserves the right to curate lore in news articles. This means if you post an article which contradicts one of the above points, or otherwise is deemed unacceptable to the direction of the server’s lore, the loremasters reserve the right to edit, modify, retcon, or even delete any violating articles. All relevant writers will be notified and in the case of deletion or retcon, an announcement will be made to the community. If the writer displays malicious intent in violating the rules when posting such an article, disciplinary action may be taken. However, if it is the result of an unintentional creative difference, no disciplinary action will be taken.

How To Recton News Articles

Over the course of years of lore development older articles become defunct in their nature. Whether they are forgotten and new lore which directly contradicts them is made, or they become incompatible with changes in lore over time, the need to remove old articles crops up. Follow the Major Retcons guide and rules in the Wiki Development section of these rules and regulations in order to have retconned news articles archived. All articles that are archived will be announced to the community and a description of why it was no longer canon will be affixed to the article in the archive.

Major Retcons

In order to formalize a review process for retcons in our lore, all major retcons must first have a feedback thread on the lore staff forum for the duration of no less than 72 hours and no more than one week before it may be implemented. These feedback threads will then be announced to the lore team where they will be allowed to input criticisms, praises, and suggestions. After one week, the Lore Master will then have to choose if the retcon will go into effect. If the Lore Master is unsure about their decision, or if suggestions in the threads are determined to be necessary and may take some time to include, the Lore Master may delay the decision by a maximum of 72 hours, unless the lore developer making the proposal requests more time to make changes based on suggestions. No major retcons may take effect until this process has been completed and the Lore Master has agreed to implement the proposed changes.

A major retcon is defined as moderate to large changes in pre-existing lore, such as species rewrites, history reworks, deletion or removal of existing content, or any significant reworking of lore-based wiki pages.

The following does not qualify as a major retcon: Spelling corrections, formatting changes, general corrections to syntax or grammar, rewording the same sentences, any new lore additions which do not intentionally contradict pre-existing lore, corrections to mistakes such as wrong dates or names, small changes which have minimal impact on the overall culture and narrative of its field in our lore.

If the Lore Master feels a major retcon may require wider community input, the Lore Master may bring the proposed retcon to the public for feedback within this one week window, either on the forums or one of the official discords.

If you are unsure if a retcon would be a minor or major retcon, or if it would need this review process, ask the Lore Master or Lore Master Deputy. Always inform the loremaster before posting a retcon feedback thread to the forums. Although the Lore Master must be informed and has discretion if a major retcon may take effect, the Lore Master may not refuse to allow a lore developer from beginning the major retcon feedback process.

Event Rules and Regulations

The following section is both a guide on how to do events and the rules and regulations that surround them. It is important for all lore staff to be aware of these requirements.

Mini-Events and Arcs

Before going further, it is necessary to cite the differences in Mini-Events, and Actual Events, as well as their associated arcs, as they have two separate sets of rules and regulations.

Mini Events can be defined as the following: An event, or set of events, that while potentially canon, has little to no impact on the setting at large, run with already available assets, or assets that can be created by one person within the timeframe of a week. Their impact is mostly focused on player characters, and aftershocks are generally limited to the SCCV Horizon, or another limited area the event takes place in, such as a space station being visited. No spur-shattering moments, instead being built around more mundane things, that could be seen as day-to-day in the Orion Spur. The overarching objective being to create an environment where players can develop their characters by reacting to everyday canonical situations as they occur, which they might not have been able to do as effectively without a staff-planned event.

This differs from actual events and their arcs, which are much wider in scope in both lore impact and development time.

Mini-Event Rules and Regulations

• Mini-Events, and their arcs, must be properly documented on the forums in the form of a calendar post, made following Arrow’s Guidelines. They should not be documented on the wiki.
• Mini-Events must also be announced to the server at large at least 5 days in advance of their planned date, and be presented to the administrative team, any relevant species writers or loremasters at least a week in advance.
• Mini-Events must be approved by any relevant species head whose lore is used, canon or non-canon, it doesn’t matter.
• Loremasters must approve canonical mini-events and their associated arcs, however, they do not need to be posted in the Lore Staff section of the forums for review.
  • This does not mean Loremasters should not be aware of the happenings of the event, but in general, a lesser review process, only there to ensure that if something occurs that results in a staff complaint, Loremasters do not need to play catch-up to understand the general context of the situation.
• Mini-events should, whenever possible, be planned in conjunction with a member of the administrative team, who will then act as the assigned administrator for the mini-event(s).
  • Due to their potentially short development time, this is to cut down on miscommunication and ensure the assigned admin is also up to date as to what will be occurring during the event. If this is not possible, standard procedure should be followed.
• Any technical requirements of mini-events are not to be referred to the Dev Team as a staff assignment. It is of course okay if a specific member of the dev team wishes to assist, but it should not be considered a project the likes of handling technical requirements for actual events. Either use assets already present or get someone to code whatever you want without making it an assignment they need to do as staff.
• Non-Canonical Mini-events do not require the approval of Loremasters, but instead the approval of a member of the Administrative Team. It is preferable that this approval comes from a primary administrator, but approval from a secondary administrator is also acceptable.
• Canonical Mini-events follow all the procedures of canonicity as regular events, including death retcons.
  • Any complaints that result from a canonical mini-event are to be handled as all staff complaints against lore team members are.
• As mentioned above, canonical Mini-Events should have their impact and aftereffect limited to the SCCV Horizon, or minor impacts on the corporate organizations characters work for.
  • In addition, unless given express permission by the Lore Team Administration, Mini-events are limited to an intensity of Low, or Medium. Should you wish to run a High Intensity Mini-Event, reach out to the current LTA members.
• The Main Objective of Canonical Mini-Events is to create an atmosphere between larger arcs where there are canonical opportunities for players to develop their characters, rather than develop the setting.
  • This could be something as simple as a party; basically any situation that players can react to, or interact with, in order to further develop their characters. Keep it in mind when planning mini-events.
• It is encouraged that beyond reaching out to the administrative team, other teams such as CCIA are also reached out to, both to keep them in the loop, and to possibly include in mini-event arcs.

Event Arcs

Event Arc Planning and Timing

Major Event Arcs should be planned and presented for review before the arc that would precede them is completed. An example of this would be that, after the second event of an arc taking place in the Coalition, an arc plan is presented that would take place in Adhomai. This is to give both the dev team and yourself ample time to prepare the following arc, and minimize the gap between major arcs. In theory, there shouldn’t be more than a three to four month gap between major arcs. Presenting an arc while its predecessor is still ongoing, and then immediately starting work on it helps tremendously with ensuring this gap remains small.

The Lore Team Administration reserves the right to decide the timing of arcs in relation to each other. Just because one arc was approved before another, does not mean that it will come first. Such a decision should be preceded by a team discussion on the reasoning behind it, and allow team members the opportunity to express their thoughts about changing the timing of event arcs to the Lore Team Administration.

Major Event Arcs should also in some way impact the setting in which they are run as a whole. This could mean the entire Spur, or just a single system where the arc takes place. This impact does not need to be clearly defined by the crew, they may simply be in the wrong place at the wrong time, but an impact on the overall setting should be the theme of any major event arcs

Event Rules and Regulations

• Major Events and their arcs must be properly documented both on the forums before/during them, and then properly documented on the wiki afterward. This documentation should follow not only Arrow’s Guidelines for the scheduling of events themselves but also the Arc Outline Template that can be found here.
• Arcs should also be announced with a general time of occurrence to the server as a whole two months before their scheduled time, to alert players of what might be coming next. Whenever possible, this should be kept OOC only.
  • An important part of this is ensuring that you will in fact be ready in two months. Announcing months ahead of time, only to be delayed constantly, will merely leave the player base waiting on their hands for the arc to begin, not as engaged as they might be.
• Major Event Arcs must be presented in the Lore Staff Section of the Forums, to be approved by Loremasters after a review period. This presentation should take place during a major event arc that would be preceding it, as mentioned above.
  • In addition to the Loremaster review and stamp of approval, Major Event Arcs should be discussed amongst the entire team in regards to their impact. If possible, other teams should incorporate some of the impact of an arc into their own lore, in order to make the setting feel more alive.
  • Both the Head Developers and LTA reserve the right to request changes or alterations to proposed arcs and may deny arcs at their discretion.
• Events follow the server’s canonicity rules, as outlined below.
• When Scheduling an Event; the forum calendar post should follow this format.
  • The Event Scale section must be filled out with one of the following intensity; Low, Medium, High, or Extreme.
    • Furthermore, the LTA and Head Developers have the final say as to what an event's intensity classification is or should be.
• Any arc that would see the running of a high or extreme intensity event must also see that the event specifically is approved by the LTA and Head Developers before the arc proposal being presented on the forums.
  • This should be done by the relevant team creating a rough draft of the arc, including the reasoning for why an extreme intensity event should be run, and how it will improve the arc.
• All event arc proposals must follow these rules;
  • This is the format for event arc proposal forum posts, the long description is a google doc, shared via link to anyone who access the link.
  • This is the template used for the cover page of the proposal.
  • The Proposal Document should be several different documents, with a main document containing the links to the others being the “cover page” of the proposal. This page should outline the overall objective of the arc, and specific goals that are needed to accomplish the objective. The centerpiece of this page however should be an overview of the arc, including its stages; as well as the traits of the arc.
  • Linked to the proposal page, there should be a document, or set of documents, containing the written information about the arc, including event summaries, articles, wiki changes pre and post arc, and potentially even differing sets of articles and events depending on actions taken by the crew over the course of the arc.
  • Technical Requirements such as sprites, code, maps, and other similar things should be compiled into a technical document, with the arcs name, and if approved, then forwarded to the Dev Team in a newly created channel for managing the technical side of the arc, who will work on it as part of their contribution to the staff team. Whenever possible reference images should be provided, and outlines of event maps made for the dev team.
  • In addition, the development process should be coordinated by a member of either the dev or species team running the arc, who acts as a manager for the technical side, ensuring that work is completed in a quick and organized fashion.
  • By the time everything has been entered into the appropriate fields, the document should look something like this.
• Staff Complaints regarding event arcs, such as complaints regarding canon deaths, are to be handled as per the respective rules.

Event Intensity Scale

This is for internal use by the lore team, lore team administration, and head developers to help classify where on the intensity scale a proposed event should fall. These are guidelines, with the LTA and Head Developers having the final say on event intensities.

• Low Intensity - There is no external threat to the crew that can cause physical or mental harm.

• Medium Intensity - An external threat that can cause physical or mental harm is present, however it is easily overcome by the crew, and during overcoming it, or should the crew fail to overcome it, there will be a minimal loss of life or risk of injury among player characters.

• High Intensity - An external threat that can cause physical or mental harm is present and overcoming will be difficult. During overcoming it, or should the crew fail to overcome it, there will be a moderate loss of life or risk of injury among player characters

• Extreme Intensity - An external threat that can cause physical or mental harm is present, and the main focus of the event. During overcoming it, or should the crew fail to overcome it, there will be a high loss of life or risk of injury among player characters.

Canonical Deaths in Events

From the server rules: 

"Happenings related to canon events, usually ran by admins with the guidance of lore staff, are considered canon. The lore writer and the admin coordinating the event can make exceptions if permitted by the lore masters and the headmins. In the case of character death caused by the canon event, the death is considered canon and permanent unless the lore masters and headmins explicitly permit the character's death to be retconned.

This only applies to deaths related to the canon event. The other canon and death rules are still valid, this applies only to stuff that happens due to the event itself.

Event Awards

Awards are considered any in-game way that represents a noting of a certain action, broad or specific, during events by the lore team. Commonly, this is done in the form of medals or a plaque. Participation awards that apply to all characters during an event or awards given to the Horizon's crew as a whole can be given at the discretion of the relevant event manager and their team. However, such awards cannot be in-round items or custom items, except those given to the Horizon as a whole.

Unique awards are for the purposes of this section, defined as any awards which mention a player character's name.

For specific/special awards, the following rules apply;

1) Any unique awards given to player characters cannot be an in-round item during standard rounds. Any request for unique awards as custom items will be immediately denied. Awards may only be used in (event) rounds where the use of awards has been explicitly permitted in the event description (such as award ceremonies). This permission can come with certain restrictions (i.e. the usage of dress uniforms/formal clothing together with the award) This rule does not apply to signed items.

1a) Writers may include mention of specific/special awards and the player characters which received them in articles, at the discretion of the LTA, but may not include this on any lore wiki page, outside of arc summaries.

2) The reasoning behind the unique award has to be for how something was accomplished, not just accomplishing something. This reasoning must also meet the highest OOC standards of roleplay, for example, no awards for characters who ignored pain.

3) The reasoning mentioned in number 2 must also not be directly tied to combat or fighting in any way. Unique awards may be handed out for something like exceptional planning and organization, but not for destroying a mech.

4) Unique awards may only be given to player characters with the express permission of the LTA. Furthermore, Head Administrators reserve the right to deny any awards on the grounds of failing to meet the highest standards of roleplay.

5) These rules do not apply to NPCs or Event Characters, only to player characters.

6) Specific/special awards from corporations must also be approved by the Lead CCIA Agent.

Recognition of Player Characters in Official Lore

For the purposes of this section, official lore is defined as anything written by members of the lore team, and posted to either the official galactic news database, or published on the Aurora Wiki.

1) Player characters should only be recognized in official lore if they influence the course of an IC development, and player characters should never be mentioned otherwise.

2) Lore Writers are strictly forbidden from including their own, or other members of the Lore Team’s characters in any official Lore. Furthermore, Lore Writers are restricted from creating IC developments which would inevitably create lore that features their characters, or other members of the Lore Team’s characters.

3) Approval from the LTA is required before recognizing any player character in official lore.

3a) All recognition of a player character must be removed from official lore should the attached player be permanently banned from the server.

4) The Administration Team, through the Head Administrators, reserves the right to mandate the removal of recognition from a player character in official lore, should they believe they do not conduct themselves appropriately in character, or if a character’s player does not conduct themselves appropriately.

5) The Lore Team must strive to recognize a wide variety of characters and players in official lore, by;

5a) Ensuring the potential for obtaining recognition is available to all players who play in events.

5b) Ensuring a character is never recognized more than two times.

5c) Endeavour that a player never has one of their characters recognized more than twice within a short time frame. The definition of that time frame is at the discretion of the LTA.

6) Player characters cannot be recognized if they are being recognized for something that has a large impact on the overall setting, and instead be contributed to the Horizon crew. An example would be a player character being recognized for discovering a new phoron deposit, or doing something extremely significant for an arc.

7) When recognizing player characters, writers should ensure that recognition is limited to articles, and rarely put onto non-arc wiki pages. As an example, a character saves a dog from a house which is on fire, and this is mentioned in an article, but would not be mentioned on the wiki entry for that house’s location.

Lore Team Expectations and Staffing

Lore Team Administration

The lore team administration consists of the loremaster and deputy loremaster. They are at the head of the lore team and steer the direction of our game’s direction in story telling. They are responsible for curating the content of our official lore in all forms, managing the lore team, staffing lore departments, handling neglected whitelist applications, and mediating disputes between different lore departments. The loremaster cannot concurrently serve as a lore writer or lore deputy. The deputy loremaster may concurrently serve as a lore writer. This is to prevent the loremaster from having a bias when writing lore, and to help them to serve as an impartial arbitrator when discussing the direction of our lore and disputes between different lore departments.

The loremaster is appointed by the server’s head developers and in turn appoints their own deputy loremaster, typically through an application process. The loremaster has the power to take disciplinary actions against lore writers and deputies only with the approval of the deputy loremaster. The loremaster may only staff lore writers through an application process which provides the community with the opportunity to provide their input, and cannot directly appoint a lore writer without observing the process.

Lore team administration may not appoint deputies, however all lore deputies must be approved by lore team administration before their applications can be accepted. The requirements for the lore writer application process are at the discretion of lore team administration. Lore deputy hopefuls must also go through the application process before they can join the team. In the event that there is a lore writer vacancy, jurisdiction over that department is absorbed into the responsibilities of lore team administration, but the duties associated with it may be delegated to any deputies within that department. Even in the event of a lore writer vacancy, the loremaster may not appoint deputies to that department but must appoint a lore writer first who may then select their deputies within the rules. Lore team management is expected to be active in both the management and editorial review of content, and in interaction with the community through discord, forums and server play. Lore team management is expected to set the example in both lore writing and code of conduct.

Lore Writers

Lore writers are the departmental heads of the lore team. Each lore writer is in charge of a major playable race of our server’s setting, and handles all of their lore and manages the whitelists associated with their jurisdiction. Lore writers are appointed by lore team management through the developer application process. Writers are expected to be active in both terms of lore writing and server play. They are expected to maintain consistency between their news articles, wiki pages, and on-station events. They are expected to follow the rules laid out in the “How-to” guides above. Writers are also expected to coordinate with their fellow writers in their projects and to uphold the code of conduct in their interactions with each other, their fellow staff, and the community. They are allowed to appoint up to two deputies through the developer application process and may delegate any of their duties to their deputies as they see fit. Lore Writers reserve the right to modify the application process when selecting their deputies to any extra requirements they desire, and cannot be forced to accept deputies against their will by lore team administration. A lore writer cannot concurrently serve as the writer for multiple lore departments and is ineligible for lore deputy positions. However, a lore writer can concurrently serve as deputy loremaster.

Lore Deputies

Lore deputies are the appointed help of lore writers who assist by performing any tasks delegated to them by their lore writer, or lore team management in the absence of a direct superior. They are the de facto proteges of their writer and should be trained as heir apparents by their superior. Despite this, lore team management reserves the right to appoint other applicants to lore writer positions when vacancies occur. A lore deputy cannot serve in multiple deputy positions simultaneously. If a lore deputy would like to apply for a different deputy position, they may apply but if accepted must forfeit their previous position. Lore deputies are not expected to manage an entire lore department unless there is a lore writer vacancy in their department. Even though lore deputies have decreased responsibilities when compared to writers, they are still expected to maintain a degree of activity in both lore writing and on-server play. Like everyone else on the lore team, deputies are expected to abide by the code of conduct in their interactions with their team members, fellow staff, and the community.