Bravo Fleet
Difference between revisions of "Command Policy"

Difference between revisions of "Command Policy"

From Bravo Fleet
 
(10 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{icons|bfo}}Last Update: 10 August 2023
{{icons|bfo}}Last Update: 1 June 2024


=1 - Registry Definition=
==1 - Registry Definition==
#The registry lists all starships, starbases, and other entities available to Bravo Fleet for use as Commands or Games.
#The registry lists all starships, starbases, and other entities available to Bravo Fleet for use as Commands or Games.
#The registry’s purpose is to maintain consistency across Bravo Fleet and its ongoing canon. As such, entries will not be added to, removed, or altered from the registry without permission of the Intelligence Office.
#The registry’s purpose is to maintain consistency across Bravo Fleet and its ongoing canon. As such, entries will not be added to, removed, or altered from the registry without permission of the Intelligence Office.
#The registry represents the In Character starships and starbases available to the Fourth Fleet in {{Year}}, and the starships and starbases available for Games and Commands.
#The registry represents the in-universe starships and starbases available to the Fourth Fleet in {{Year}}, and the starships and starbases available to members in their personal writing or the RPGs they play and run. They are represented on BFMS by Games and Commands, which are attached to the dossiers of the members who own them, and house the character biographies of the crew and the Missions and Stories depicting their adventures.
##Exceptions such as non-Starfleet ships or ships of a different era have been created for Fictions or Games, and may not be used as Primary Commands. These will be more often added, deleted, or altered.
##Exceptions such as non-Starfleet ships or ships of a different era have been created for Games, and may not be used as Primary Commands. These will be more often added, deleted, or altered.
##The use of registry entries in Games is governed by Section 4 of the Operations Policy.
## The use of registry entries in Games is governed by Section 4 of the Operations Policy.
#Ships in the registry should only be used in lore by the members or Task Forces (in the case of TFHQ ships or Flagships only) to which they are assigned. If a story requires another ship, it should use a name not listed in the registry and would fall within the bounds of member canon.
#Ships in the registry should only be used in lore by the members or Task Forces (in the case of TF Assets) to which they are assigned.
#Stories may depict ships, including Starfleet ships, not in the registry. These must never be written as the 'main' vessel in a story, and their place in stories must be restricted to minor or supporting roles. The existence and use of these 'NPC' ships constitutes member canon.
#Stories may depict other ships, including Starfleet ships, not in the registry. These must never be written as the 'main' vessel in a story, and their place in stories must be restricted to minor or supporting roles. The existence and use of these 'NPC' ships constitutes member canon.
##These ships must always have a name not found in the registry.
## These ships must always have a name not found in the registry.
##NPC ships may not be written as assigned to a joint mission alongside a member's ship, and especially not under their command.
##NPC ships may not be written as assigned to a joint mission alongside a member's ship, and especially not under their command.
##These ships should be playing roles like delivering supplies or personnel or being in need of rescue as a story's instigating event. They and their crews should not be recurring, significant dramatic actors in a manner that undermines the Squadron System (Section 3). Members who want to write multiple ships and crews must wait until attaining the fleet rank of Captain.
##These ships should play roles like delivering supplies or personnel or being in need of rescue as a story's instigating event. They and their crews should not be recurring, significant dramatic actors in a manner that undermines the Fleet Assets System. Members who want to write multiple ships and crews must wait until attaining the fleet rank of Captain.
#Events involving registry ships ''prior to'' 2399 may be referenced in circumstances such as character service records and backstory. This restriction changes at 2399 as this is when the current fleet canon went live; members should not be dictating fleet or member canon after this outside of their own characters and Command.
#Events involving registry ships ''prior to'' 2399 may be referenced in circumstances such as character service records and backstory. This restriction changes at 2399 as this is when the current fleet canon went live; members should not be dictating fleet or member canon after this outside of their own characters and Command.
#Fleet canon about a ship is defined by the Intelligence Office or any member who holds that Command. Subsequent members who command a registry ship must adhere to that fleet canon and not retcon or change it without permission from the Intelligence Officer.
# Fleet canon about a ship is defined by the Intelligence Office or any member who holds that Command. Subsequent members who command a registry ship must adhere to that fleet canon and not retcon or change it without permission from the Intelligence Officer.
##Fleet canon established by prior commanders is limited to the names of captains and crewmembers and the dates of their assignments, and major points of the ship's activities, such as participation in a fleet-wide storyline or where and when the ship was commissioned. Members are not beholden to retain more minor details of a ship's mission history, design, or configuration. Any pre-2399 history of a command established by a member is member canon and thus may be rewritten or disregarded by any new commander.
##Fleet canon established by prior commanders is limited to the names of captains and crewmembers and the dates of their assignments, and major points of the ship's activities, such as participation in a fleet-wide storyline or where and when the ship was commissioned. Members are not beholden to retain more minor details of a ship's mission history, design, or configuration. Any pre-2399 history of a command established by a member is member canon and thus may be rewritten or disregarded by any new commander.
##The history of registry ships is maintained on their wiki article. Members are free to depict this history as they wish, either retaining original text or rewriting. There is no obligation to mention events or history prior to their command. The only requirement is to retain a list of previous commanders, ''with links to their BFMS Commands'', as seen [https://wiki.bravofleet.com/index.php/USS_Rhyndacus#Notable_Crew here].
##The history of registry ships is maintained on their wiki article. Members are free to depict this history as they wish, either retaining original text or rewriting. There is no obligation to mention events or history prior to their command. The only requirement is to retain a list of previous commanders, ''with links to their BFMS Commands'', as seen [https://wiki.bravofleet.com/index.php/USS_Rhyndacus#Notable_Crew here].
#Ships are assigned to a member's dossier when they are created as Commands on BFMS. A member must create an application for the Command that the Intel Office processes. The IO does not create Commands for members. Commands exist to house Missions, Stories, and crew rosters; they show the ship on the member's dossier, and ensure the registry displays what ships are available or unavailable. ''All'' ships in use require a Command, including RPGs and squadron ships.
==2 - Primary Commands ==
##Once a ship has been relinquished, the BFMS Command will be labelled as 'Archive' and exist on the member's dossier for archival purposes only. Members may edit the Command page or the roster, but they may not add further Missions or Stories.
# The assigning and management of ships and Commands is governed by the [[Logistics Office Policy]].
#Members should not apply for Commands on BFMS until they are ready to acquire or change their Primary Command, or for a fiction/RPG proposal to be discussed with the Intelligence Officer/Operations Officer. Draft Commands or proposals self-identifying as WIPs will have their registry link removed or be deleted.
#Primary Commands are attached to a member's dossiers as their character's starship or auxiliary craft. They are the vessels assigned In Character to a member’s Task Force in the Fourth Fleet in {{Year}}.  
#Members may change their assigned Commands once every three months or after they are promoted, whichever comes first. This applies to ''all'' of a member's Commands; if only one ship in a squadron of two is changed, three months must elapse or a promotion must be earned before ''either'' ship can be changed.
##Regardless of what Secondary Commands a member may own, their Primary Command must always be a Starfleet ship assigned to the Fourth Fleet in {{Year}}.
##If a member has not used their full squadron strength entitlement, they may request ships to fill it anytime. However, this resets the Command change cooldown. So long as a member ''can'' request additional ships, they may do so as often as they like, but they may not change those ships until three months have elapsed or a promotion has been earned.
# Members can write on their Primary Commands on their own or, with some restrictions, with others.
##Exceptions may be permitted at the discretion of the Intelligence Officer. This may apply in cases such as the release of new starship classes or other significant alterations to the command registry.
##Members may only have one other member permanently writing on their Command. This member may play one or several characters, including crewmembers and senior staff assigned to the ship. This additional member may not play the ship's Commanding Officer; the CO must be a character assigned to the member who holds the Command.
=2 - Primary Commands=
##Members may invite others to temporarily write on their Command as guests. There is no restriction in how many guests may be on write on a Command at one time, but this collaboration cannot last longer than one mission and is expected to be limited to one or a handful of Stories. These guests may write characters from other BF Commands or RPGs in a 'cross-over,' or they may write new characters created for this collaboration. They may return later for more guest appearances, but this collaboration should stay in the spirit of a 'guest star' on a Star Trek episode.
#Primary Commands are attached to a member's dossiers as their character's starship or auxiliary craft. They are the vessels assigned In Character to a member’s Task Force in the Fourth Fleet in {{Year}}.
## Writing with others on a Primary Command does not require a proposal or activity commitment to be sent to the Intelligence Office. Members ''may not'' use their Primary Command as an RPG; ie, they may not openly recruit for crew or create a separate website, and collaboration should be limited to invitation-only. RPGs which any member of the Fleet may apply to join must be accepted by the Bravo Fleet Operations Officer, and thus Primary Commands are unsuitable for this purpose.
#Members can write on their Primary Commands on their own or with others. Writing with others on a Primary Command does not require a proposal or activity commitment being sent to the Intelligence Office. Members ''may not'' use their Primary Command as an RPG; ie, they may not openly recruit for crew or create a separate website, and collaboration should be limited to invitation-only. RPGs which any member of the Fleet may apply to join must be accepted by the Bravo Fleet Operations Officer, and thus Primary Commands are unsuitable for this purpose.
##These restrictions apply to Secondary Commands as well as Primary Commands.
#All Commands will be removed from a member's dossier upon transfer to the Reserves.
#When a member reaches the rank of Midshipman they may request a ship on the registry for use as their Primary Command. Ship classes available are unlocked upon reaching certain ranks.
#Members below the rank of Captain may only have one Primary Command. Requesting a new eligible Primary Command will result in the current registry ship being removed from the member's dossier and returned to the pool of available ships.
{| class="wikitable" style="margin:auto"
|+Ship classes by rank
|-
!Midshipman!!Lieutenant Commander!!Commander!!
|-
|[[California Class|California]]
|[[Aquarius Class|Aquarius]]
| colspan="2" |[[Akira Class|Akira]]
|-
| ||[[Centaur II Class|Centaur II]]|| colspan="2" |[[Defiant Class|Defiant]]
|-
|
|[[Challenger Class|Challenger]]
|[[Duderstadt Class|Duderstadt]]
|
|-
|
|[[Cheyenne Class|Cheyenne]]
| colspan="2" |[[Echelon Class|Echelon]]
|-
|  ||[[Edison Class|Edison]]|| colspan="2" |[[Excelsior II Class|Excelsior II]]
|-
|  ||[[Grissom Class|Grissom]]|| colspan="2" |[[Gagarin Class|Gagarin]]
|-
|  ||[[New Orleans Class|New Orleans]]||[[Intrepid Class|Intrepid]]
|
|-
|  ||[[Norway Class|Norway]]|| colspan="2" |[[Inquiry Class|Inquiry]]
|-
|  ||[[Nova Class|Nova]]|| colspan="2" |[[Luna Class|Luna]]
|-
|
|[[Olympic Class|Olympic]]
| colspan="2" |[[Manticore Class|Manticore]]
|-
|  ||[[Parliament Class|Parliament]]|| colspan="2" |[[Nebula Class|Nebula]]
|-
|
|[[Phoenix Class|Phoenix]]
| colspan="2" |[[Pathfinder Class|Pathfinder]]
|-
|  ||[[Raven Class|Raven]]|| colspan="2" |[[Prometheus Class|Prometheus]]
|-
|  ||[[Rhode Island Class|Rhode Island]]|| colspan="2" |[[Sutherland Class|Sutherland]]
|-
|
|[[Reliant Class|Reliant]]
| colspan="2" |
|-
|  ||[[Saber Class|Saber]]|| colspan="2" |
|-
|  ||[[Springfield Class|Springfield]]|| colspan="2" |
|-
|
|[[Steamrunner Class|Steamrunner]]
|
|
|}
=3 - Squadrons=


#The Squadron system allows members holding the dossier rank of Captain and above greater flexibility in their Command choices. Where Commanders and below may pick a single Primary Command from a list, Captains are entitled to a certain level of ‘Squadron Strength’ in their Command selection. This gives them options like choosing between a single, larger ship or multiple smaller ones.
==3 - Task Unit and Fleet Assets==
#If a member holds multiple Commands under the Squadrons system, these ships are all subject to the same usage requirements as outlined under Primary Commands above. They may not be used as RPGs, and IC are starships assigned to the member’s Task Force.
##All ships must have their own Command on BFMS. This is solely to ensure the registry accurately reflects what ships are in use and dossiers show all of a member's ships. Members are free, however, to house Stories and Missions involving the ship and crew on any of their squadron BFMS Commands.
##Members with multiple ships should designate one as their Primary Command on BFMS. This is solely for display and organisational purposes, and has no other or IC significance. The Primary Command must be a Squadron Commands, and may not be an RPG or Fiction.
##Members have some freedom on how to IC depict these multiple ships. They may be entirely unaffiliated, all falling directly under their Task Force’s IC chain of command, with the member using them to tell totally different stories.
##Members may use all/some of them to form an IC-only unit within their Task Force, referred to as a squadron. This typically takes its title from the squadron’s ‘lead ship’ or starbase (for example, a squadron led by the USS Endeavour would be called ‘Endeavour Squadron’). This ensures all squadrons have a unique IC name. Members may not call these IC units ‘task groups’, to avoid confusion with the OOC unit.
##Members may create an officer in command of this squadron, who may or may not also be the commanding officer of one of these starships/starbase, and who falls IC under the chain of command of the member’s Task Force. All Canon Policy rank restrictions remain.
#The Squadron Strength to which a member is entitled is dependent on their dossier rank.
{| class="wikitable"
|+'''Squadron Strength by Dossier Rank'''
!Captain
!Fleet Captain
!Commodore
!Rear Admiral
!Vice Admiral
!Admiral
!Fleet Admiral
|-
|3
|4
|6
|7
|8
|9
|10
|}


== 3.1 - Starship Strength ==
#The assigning and management of Task Unit Assets is governed by the [[Logistics Office Policy]].
 
#Members may use these assets in their stories, with some limitations. These assets should never be significantly altered by the events of a member's writing without the permission of the Intelligence Officer.
# Ship classes are allocated a certain level of Strength depending on their size, power, modernity, and so forth.
##Task Force Headquarters and Secondary Stations may be freely depicted, without permission, by any member of any Task Force as locations their ships can visit on their journeys. TFHQs or stations may never be depicted as being significantly imperiled over the course of a story.
# Members may select any number of ships as their Commands under the Squadrons system, so long as the total Strength does not exceed their rank entitlement.
##Task Force Flagships and Guest Ships may only be used by members of the TF to which they are assigned.
# Ship classes by rank (As above in 2 - Primary Commands) may not directly correlate with a starship's squadron strength. This is intentional, reflecting how some ships may be more or less popular when they are a member's only command, but valued differently when part of a larger squadron.
###Task Force Flagships may be depicted in a member's stories with permission from the TFCO.
 
###Task Force Guest Ships may be freely depicted, without permission, by members of the Task Force to fulfill 'cameo' roles in stories. This constitutes minor usage, such as the mention of a ship's off-screen activities (for example, providing the initial report of an incident that leads to a member's ship conducting the deeper follow-up investigation), or a rendezvous with the member's ship to deliver supplies or a crewmember.
{| class="wikitable" style="margin:auto"
###Guest Ships may be used in larger roles in the stories of TF members with permission from the TFCO. More significant story roles include, for example, the ship in need of rescuing as the main objective of a mission, or a joint operation between two starships.
|+Ship classes by rank
#Development of Task Unit Assets is the responsibility of TF Staff, with the oversight of the Intelligence Office. This constitutes building their wiki articles, determining the asset's mission profile, and creating its CO and other crewmembers. Each Task Unit Asset should have sufficient information about it available that multiple members may depict it in their stories with relative consistency.
|-
#The usage of Task Unit Assets by members remains member canon. Members are encouraged to add their use of an asset to its wiki page to build a shared narrative among others in the TF, but this should be to facilitate a spirit of shared ownership, not provide constraints.
!1!!2!! colspan="2" |3
!4
|-
|Small Civilian Ship
|[[Alita Class|Alita]]
|
|[[Constitution III Class|Constitution III]]
|[[Odyssey Class|Odyssey]]
|-
|[[Aquarius Class|Aquarius]]|| colspan="2" |[[Akira Class|Akira]]||[[Galaxy Class|Galaxy]]
|
|-
|[[California Class|California]]|| colspan="2" |[[Duderstadt Class|Duderstadt]]||[[Obena Class|Obena]]
|
|-
|[[Centaur II Class|Centaur II]]
|[[Echelon Class|Echelon]]
|
|[[Ross Class|Ross]]
|
|-
|[[Challenger Class|Challenger]]
| colspan="2" |[[Excelsior II Class|Excelsior II]]
|[[Sagan Class|Sagan]]
|
|-
|[[Cheyenne Class|Cheyenne]]|| colspan="2" |[[Gagarin Class|Gagarin]]||[[Sovereign Class|Sovereign]]
|
|-
|[[Defiant Class|Defiant]]
| colspan="2" |[[Inquiry Class|Inquiry]]
|[[Vesta Class|Vesta]]
|
|-
|[[Edison Class|Edison]]|| colspan="2" |[[Luna Class|Luna]]||
|
|-
|[[Grissom Class|Grissom]]|| colspan="2" |[[Manticore Class|Manticore]]||
|
|-
|[[Intrepid Class|Intrepid]]
| colspan="2" |[[Nebula Class|Nebula]]
|
|
|-
|[[New Orleans Class|New Orleans]]|| colspan="2" |[[Pathfinder Class|Pathfinder]]||
|
|-
|[[Norway Class|Norway]]|| colspan="2" |[[Prometheus Class|Prometheus]]||
|
|-
|[[Nova Class|Nova]]||[[Sutherland Class|Sutherland]]
| ||
|
|-
|[[Olympic Class|Olympic]]||
|  ||
|
|-
|[[Parliament Class|Parliament]]|| colspan="2" | ||
|
|-
|[[Phoenix Class|Phoenix]]||
|  ||
|
|-
|[[Raven Class|Raven]]||
|-
|[[Rhode Island Class|Rhode Island]]
|
|-
|[[Reliant Class|Reliant]]
|
|-
|[[Saber Class|Saber]]||
|-
|[[Springfield Class|Springfield]]||
|-
|[[Steamrunner Class|Steamrunner]]
|
|}
#For example, upon reaching the rank of Captain a member has a Squadron Strength entitlement of 3. If they already have a Commander-level ship, they are only using 2 of their Squadron Level. They may ‘upgrade’ as they did upon reaching the rank of Commander, returning their current ship to the registry and choosing a single new Command with a Strength of 3. If they keep their ship with its Strength of 2, they may choose to add to their dossier another ship with a Strength of 1.
##Members are under no obligation to use their total Squadron Strength. These Commands are a reflection of the hard work of members, however, and may be chosen for storytelling opportunities or simple prestige.
#‘Small Civilian Ship’ is a catch-all term for non-Starfleet civilian vessels members may wish to use for different kinds of storytelling. It refers to ships of, for example, the [[Kaplan F17 class]] or the [[Groumall class]], usually freighters, that are not affiliated IC with Starfleet and may be used for trading, prospecting, exploration, or other adventures. Acquiring a ship like this is subject to a successful Fiction Proposal, and so they are not listed as available on the registry but created as required by the Intelligence Office.
#The Intelligence Office may make adjustments to ship class Strengths to account for balance as the system and canon evolve. No member will have an asset removed because of a rebalance, but they would only be grandfathered in until they wanted to change their squadron, at which point the new strength values would be used.
 
== 3.2 - Starbase Strength ==
 
# Starbases as Commands work the same as starships under the Squadron system, but are subject to different requirements. They represent starbases assigned In Character to the member’s Task Force in the Fourth Fleet in {{year}}.
# Members do not have to choose between a starbase or starship under the Squadron system. They are only restricted by their rank’s total Squadron Strength.
# Registry Starbases are created by the Intelligence Office, and will have their own wiki article explaining the location and setting material relevant to that starbase that has been ratified by the Intelligence Office. This is Fleet Canon that cannot be altered without permission of the Intelligence Office, even by the member to whom the starbase registry is attached. As such, members should heavily consider their choice, as a Starbase Command is under more restrictions and requirements from the Intelligence Office.
## Members interested in creating a station command should consult directly with the Intelligence Office if one of the concepts on the wiki isn't suitable for their idea.
# Because stations impact shared canon more directly than starships, members will be unable to trade in a station for six months after acquiring it, not including time spent in the reserves.
 
{| class="wikitable" style="margin:auto"
|+Starbase classes by Strength
|-
!2!!3!!4
|-
|[[Jupiter Class|Jupiter]]||[[Anchorage Class|Anchorage]]||[[Canopus Class|Canopus]]
|-
|[[K Class|K-Type]]||[[Copernicus Class|Copernicus]]||[[Unity Class|Unity]]
|-
|[[Regula Class|Regula]]||[[Narendra Class|Narendra]]||
|-
|[[Vision Class|Vision]]||[[Presidium Class|Presidium]]||
|-
| ||[[Watchtower Class|Watchtower]]||
|}
 
== 3.3 - Attached Ships ==
 
# Certain commands, like starbases, have an attached ship, which has its own registry entry but has an effective Strength of 0. Whether or not an attached ship is selected does not affect a member’s Squadron Strength.
# Most attached ships are assigned to starbases. Upon requesting a starbase, the member should identify to the Intelligence Office an appropriate choice of ship from the registry. That ship will then be removed from the public pool. It will not be given a BFMS Command, but should be written about as part of the starbase’s Command.
# The ''Odyssey''-class always has an ''Aquarius''-class ship attached. Unlike with starbases, the ''Aquarius''-class’s name is predetermined and cannot be changed. Details about an ''Odyssey’s'' ''Aquarius''-class will be listed on the ship’s wiki page.
# A strength 1 starship is attached to every station command in order to ensure that members have the ability to interact with fleet events set in other areas. This starship is assigned to the station directly to support it, as the ''Defiant'' was to DS9. This does not add to or subtract from the strength of a member's squadron, i.e. you could not use additional squadron strength to attach a strength 2 starship to your station.
# Members may choose to depict any of their other ships as attached to or operating out of the starbase.
 
== 3.4 - Requesting Squadron Ships ==
 
# Members must use BFMS to request any Commands under the Squadron system, in the same manner as Command requests at the ranks of Lieutenant Commander or Commander.
# BFMS requests for new Commands under the Squadron system must use the ‘Lore Office Proposal’ window to clearly communicate their allocation of their Squadron Level. This must include what ships, if any, are being returned to the registry.
## If a new Captain requests a Command with a Strength of 3 with no further detail, the Intelligence Office will assume they are returning their current ship to the registry, just as with previous upgrades, and process accordingly.
## If a Member wishes to retain their current Command and add another, they may request the new ship under BFMS and say so in the Proposal window. A simple message, such as ‘I am keeping the USS Lollipop (Strength 2), and adding this one (Strength 1) for a total Squadron Strength of 3’ will suffice.
## If a Member wishes to return any of their ships to the registry, they must say so. Any requests for additional Commands that does not include a registry return and would bring a member over their Squadron Strength will be deleted. A simple message, such as ‘I am returning the USS Lollipop (Strength 2) and adding this one (Strength 3) for a total Squadron Strength of 3’ will suffice.
# If the Intelligence Office receives competing requests for the same starship, requests for a primary command from Lieutenant Commanders or Commanders will be prioritised, or upgrades to a single Strength 3 starship for new Captains. After that, ships will be allocated on a first-come, first-served basis.
=4 - Fictions=
#Stories about alternative settings such as non-Starfleet ships or historic eras are called 'Fictions'. Like primary or squadron commands and RPGs, they have their own BFMS Command page and are held to the same standards in content and canon compliancy.
#Fictions may only be written by one individual member. Stories with multiple writers count as role-playing games, which fall under the purview of the Operations Department.
#A member who has reached the rank of Commander may submit a fiction proposal to the Intelligence Office. This is not necessary for fiction based on their Primary Command.
#The proposal should explain the premise of the story, a loose estimation of expected length, and what it contributes to Bravo Fleet canon, present or historic. It should include a broad activity commitment, such as '1 Story posted per month.' This is not a binding agreement, but helps the Intelligence Office identify inactive Fictions.
#Starfleet ships in the year {{year}}  are not an appropriate setting for Fictions. Members should use their Primary or Squadron Commands for these.
# Fictions do not draw from ships in the Bravo Fleet Registry, and so should discuss their ship, station, or concept needs with the Intelligence Office so an appropriate entry can be created.
#Fictions not set in {{Year}} should ''not'' draw from ships in the Bravo Fleet Registry. Members are subject to the same rank-based restrictions of classes (for example, a Commander writing a fiction set in 2375 still cannot request a Sovereign-class), but of course can request era-appropriate ship classes not listed in the registry.
# A new fiction will have its own Command on BFMS, assigned to the member. This Command is for use solely within the bounds of the accepted fiction proposal, and must not be used as a Primary Command.
# Bravo Fleet fiction supports and enriches Bravo Fleet Canon, present and historic. Proposals from non-Trek settings will be rejected. Proposals from alternate universes of Star Trek will need to demonstrate their relevance to Bravo Fleet Canon content, themes, or characters to be accepted.

Latest revision as of 15:43, 1 June 2024

This article is official Bravo Fleet Official Policy.








Last Update: 1 June 2024

1 - Registry Definition

  1. The registry lists all starships, starbases, and other entities available to Bravo Fleet for use as Commands or Games.
  2. The registry’s purpose is to maintain consistency across Bravo Fleet and its ongoing canon. As such, entries will not be added to, removed, or altered from the registry without permission of the Intelligence Office.
  3. The registry represents the in-universe starships and starbases available to the Fourth Fleet in 2401, and the starships and starbases available to members in their personal writing or the RPGs they play and run. They are represented on BFMS by Games and Commands, which are attached to the dossiers of the members who own them, and house the character biographies of the crew and the Missions and Stories depicting their adventures.
    1. Exceptions such as non-Starfleet ships or ships of a different era have been created for Games, and may not be used as Primary Commands. These will be more often added, deleted, or altered.
    2. The use of registry entries in Games is governed by Section 4 of the Operations Policy.
  4. Ships in the registry should only be used in lore by the members or Task Forces (in the case of TF Assets) to which they are assigned.
  5. Stories may depict other ships, including Starfleet ships, not in the registry. These must never be written as the 'main' vessel in a story, and their place in stories must be restricted to minor or supporting roles. The existence and use of these 'NPC' ships constitutes member canon.
    1. These ships must always have a name not found in the registry.
    2. NPC ships may not be written as assigned to a joint mission alongside a member's ship, and especially not under their command.
    3. These ships should play roles like delivering supplies or personnel or being in need of rescue as a story's instigating event. They and their crews should not be recurring, significant dramatic actors in a manner that undermines the Fleet Assets System. Members who want to write multiple ships and crews must wait until attaining the fleet rank of Captain.
  6. Events involving registry ships prior to 2399 may be referenced in circumstances such as character service records and backstory. This restriction changes at 2399 as this is when the current fleet canon went live; members should not be dictating fleet or member canon after this outside of their own characters and Command.
  7. Fleet canon about a ship is defined by the Intelligence Office or any member who holds that Command. Subsequent members who command a registry ship must adhere to that fleet canon and not retcon or change it without permission from the Intelligence Officer.
    1. Fleet canon established by prior commanders is limited to the names of captains and crewmembers and the dates of their assignments, and major points of the ship's activities, such as participation in a fleet-wide storyline or where and when the ship was commissioned. Members are not beholden to retain more minor details of a ship's mission history, design, or configuration. Any pre-2399 history of a command established by a member is member canon and thus may be rewritten or disregarded by any new commander.
    2. The history of registry ships is maintained on their wiki article. Members are free to depict this history as they wish, either retaining original text or rewriting. There is no obligation to mention events or history prior to their command. The only requirement is to retain a list of previous commanders, with links to their BFMS Commands, as seen here.

2 - Primary Commands

  1. The assigning and management of ships and Commands is governed by the Logistics Office Policy.
  2. Primary Commands are attached to a member's dossiers as their character's starship or auxiliary craft. They are the vessels assigned In Character to a member’s Task Force in the Fourth Fleet in 2401.
    1. Regardless of what Secondary Commands a member may own, their Primary Command must always be a Starfleet ship assigned to the Fourth Fleet in 2401.
  3. Members can write on their Primary Commands on their own or, with some restrictions, with others.
    1. Members may only have one other member permanently writing on their Command. This member may play one or several characters, including crewmembers and senior staff assigned to the ship. This additional member may not play the ship's Commanding Officer; the CO must be a character assigned to the member who holds the Command.
    2. Members may invite others to temporarily write on their Command as guests. There is no restriction in how many guests may be on write on a Command at one time, but this collaboration cannot last longer than one mission and is expected to be limited to one or a handful of Stories. These guests may write characters from other BF Commands or RPGs in a 'cross-over,' or they may write new characters created for this collaboration. They may return later for more guest appearances, but this collaboration should stay in the spirit of a 'guest star' on a Star Trek episode.
    3. Writing with others on a Primary Command does not require a proposal or activity commitment to be sent to the Intelligence Office. Members may not use their Primary Command as an RPG; ie, they may not openly recruit for crew or create a separate website, and collaboration should be limited to invitation-only. RPGs which any member of the Fleet may apply to join must be accepted by the Bravo Fleet Operations Officer, and thus Primary Commands are unsuitable for this purpose.
    4. These restrictions apply to Secondary Commands as well as Primary Commands.

3 - Task Unit and Fleet Assets

  1. The assigning and management of Task Unit Assets is governed by the Logistics Office Policy.
  2. Members may use these assets in their stories, with some limitations. These assets should never be significantly altered by the events of a member's writing without the permission of the Intelligence Officer.
    1. Task Force Headquarters and Secondary Stations may be freely depicted, without permission, by any member of any Task Force as locations their ships can visit on their journeys. TFHQs or stations may never be depicted as being significantly imperiled over the course of a story.
    2. Task Force Flagships and Guest Ships may only be used by members of the TF to which they are assigned.
      1. Task Force Flagships may be depicted in a member's stories with permission from the TFCO.
      2. Task Force Guest Ships may be freely depicted, without permission, by members of the Task Force to fulfill 'cameo' roles in stories. This constitutes minor usage, such as the mention of a ship's off-screen activities (for example, providing the initial report of an incident that leads to a member's ship conducting the deeper follow-up investigation), or a rendezvous with the member's ship to deliver supplies or a crewmember.
      3. Guest Ships may be used in larger roles in the stories of TF members with permission from the TFCO. More significant story roles include, for example, the ship in need of rescuing as the main objective of a mission, or a joint operation between two starships.
  3. Development of Task Unit Assets is the responsibility of TF Staff, with the oversight of the Intelligence Office. This constitutes building their wiki articles, determining the asset's mission profile, and creating its CO and other crewmembers. Each Task Unit Asset should have sufficient information about it available that multiple members may depict it in their stories with relative consistency.
  4. The usage of Task Unit Assets by members remains member canon. Members are encouraged to add their use of an asset to its wiki page to build a shared narrative among others in the TF, but this should be to facilitate a spirit of shared ownership, not provide constraints.
Retrieved from "https://wiki.bravofleet.com/index.php?title=Command_Policy&oldid=13544"