Confluence Rework Proposal

Description of Proposal

Confluence is the team’s wikipedia. It serves as a critical tool for preserving the organizational memory of HA, and enables future high altitude members to get a picture of previous decisions that the team has made. Most work done on the team is documented in it. Currently though, the confluence is very hard to use given the sheer number of generated documents. This has led to issues in locating needed previous work. There are a multitude of solutions to this problem, from a more dedicated review process for new documentation, to starting fresh with a proper organizational system, but this proposal seeks to start our rework by reorganizing how the confluence sections are created, and creating a standardized naming convention to improve the searchability of the confluence.

The proposed structure is in Tommy’s confluence: https://purdue-space-program.atlassian.net/l/cp/4VP5QuuR on the left hand side of the screen. Look at it before reading further.

HAT : High altitude team documentation = non technical team documents outlining the roles, processes, and systems that enable the team to exist.

ON : Onboarding = onboarding documentation that serves as the intro to high powered rocketry for new team members. This includes a glossary of terms, introduction to confluence and jira, and any other non subteam specific onboarding information.

COM : Command media = technical requirements and processes that have to happen for physical or software hardware before work is continued. This includes information like minimum safety factors for thermal and structural components, manufacturability processes, and testing requirements for structures. It could also include requirements for code, including comment templates. Additionally, there could be exact descriptions on how systems documentation is worded. This would replace the PSP command media.

DATA : Database = any generated materials research by one subteam should be put here. There will be a generic template for all materials data, so every team can document what they’ve researched in the same method. Here can also live any testing data that would be applicable to more than one subteam, including hotfire test pressures and temperatures, or material strength test results. There could also be information on fasteners here, and resins, in more of a list format.

PL : Proposal Collection = repository of existing, implemented, and rejected proposals, in addition to instructions on how to write proposals. The information on voting processes will be in the HAT section.

SP (and DM2): Spaceshot (and dark matter two)= where all spaceshot work goes. Instead of each subteam having documentation on every vehicle they’ve ever worked on in their specific folders, the subsystem and system level documentation should be located in that specific rocket’s collection. This will greatly decrease the time it takes for a structures member to find information on the propulsion system’s chamber pressure requirements, for example. It will also de-silo our documentation, and by using a single template for all CONOPS and systems, everyone will be able to figure out what each other are working on a lot easier. NOTE: this is for PDR level work. There should not be a dozen different despin mechanisms here, just the one that people are fleshing out. Conceptual documentation should be in the subteam’s folder because that information is not only applicable to one vehicle, but many.

STR (and all subteams): Structures = each subteam’s folder. The folder starts with a specific onboarding document to that team, an org chart outlining RE’s/systems reps/leads, and then the rest is left up to each lead (because idk how stuff other than structures would be formatted lol)

RES : Resources = general resources applicable to any subteam, including prior vehicles, and textbooks.

Please add more sections to this document if I missed anything.

Each document generated in the file tree would start off with that collection’s two to four letter code. This way, we can have multiple onboarding documents for different subteams with the same name, which will help new users find things with the search function. Additionally, templates will be generated for every type of document that is usually used by team members. This will greatly simplify the process for new members when creating documentation, because they will be able to use previous examples of work from previous designs.

Pros and Cons of Implementing the Proposal

Purpose of Proposal

The confluence is borderline unusable for new members and even leads. Individual subteams may be doing a good job, but the team-wide confluence is very convoluted if you’re looking for documents outside your own subteam.

Plan for Action

Leads need to vote on it and delegate the task of reorganizing (or do it themselves).