RFC

What an RFC is?

An RFC or a Request For Comments, is a document that describes a set of requests for comments on a particular issue. These can be low level technical problems or high level management issues.

How to create a RFC?

• create a new issue on the GitHub
• the RFC number is obtained by the current date and time in the format yyyymmddhhmm
  • an RFC openened on Febuary 16th, 2023 on 7:28 PM would be: 202302161928
• the date time is based off of CST (Regina)
• the rfc number should be followed by a title
• the body of the RFC should contain enough relevant information to get someone reading it fairly upto speed on the issue at hand
• in your RFC you should mention how long you want it to stay open for (default is 1 week from the date of creation)
• if you need an issue resolved immediately, you can tag it as an emergency
• the RFC should be shared on every relevant subteam's slack channel (use @channel if it's an emergency)

When to create a RFC?

• when you need advice or opinion on a given topic
• when there is a conflict about what to do between parties
• when there are major design decisions that need to be made that concern a large protion of the team
• use the rfc template on the github

How to vote on a RFC?

• open an RFC
• it remains open for a week? (or you can specify a date)
• only people who made a meaningful contribution to the RFC get a vote
  • meaningful contributions are any contributions that provide substance to the debate and discussion at hand, it cannot just be a couple of lines you need to provide a reasoning behind your stance
• at least 2(+1) people need to comment on the RFC, for it to escalate to a vote
• vote needs to pass with a >=66% (absolute) majority
• voting shall be non-anonymous to leave a voting trail of the original voters, all voters are required to provide a reasoning behind their stance while voting
• if the RFC is tagged as an emergency i.e. it needs to be resolved in less than a week
• then it still needs to meet the quorum for voting mentioned above
• however, there needs to be a meeting where every party involved gets 5 minutes of uninterrupted floor time to speak

What if the RFC fails?

• if the RFC does not have enough participants to escalate to a vote then it is marked as stale and closed, it can be reopened at anytime by anyone, but still needs to meet requirements to escalate to a vote
• if the vote does not pass, then the RFC is closed, however it can be reopened with a 50% (absolute) majority from the original voters
• once an RFC passes it cannot be reopened
• if you were not one of the original participants and need to reopen an existing RFC, you can ask the original voters of the rfc to vote for a re-open, upon failure of vote to reopne you can just create another rfc in reference to the closed one

What if the RFC is adopted?

• if the vote passes then the rfc is adopted effective immediately
• once an RFC is adopted and closed it cannot be re-openened, however adjacent issues that might be needed to discuss can reference the closed RFC, but need to open a new one

Examples of when a RFC might be raised?

• why we need to use Rust for all programming?
• why we should not design our own PCBs?
• why the subteam should have four co-leads?
• why we should refactor the entire codebase to use xyz library?
• how do we handle a data race between task1 thread and task2 thread?
• switch from carbon fibre to aluminium for connectors?

link to an example RFC

rfc: 202304252210
title: a one line explanation

Abstract

explain the problem in as little words as possible, try not to use technical jargon

Stakeholders

who all does this affect

Problem

explain in detail what the problem this rfc is referring to

Solution

expalin in detail the solution or solutions that you have tried, if none then leave this blank

Difficulties and Risk

what difficulties are we facing or might face, what risks are we facing or might face, if possible explain how we might mitigate these

Proof of concept

how would we be able to start small, to prove that this solves more problems than it causes

Testing and Robustness Assurance

how will we be able to test the solution/solutions to ensure safety, robustness and corectness of the proposed solutions

References

links to relevant resources

Fallacies

These are some factual fallacies and examples so you can avoid them

Strawmanning

Strawmanning is when someone misrepresents or distorts another person's argument or position in order to make it easier to attack or refute. It involves creating a weaker version of the opposing argument that is easier to attack, rather than engaging with the actual argument that was presented.

Argument: We should look into fuzz testing to imporve safety and reliability, here is a library for fuzz testing provided by LLVM foundation
Refutation: We shouldn't do things because they are cool and it'll take 2 months at the very least

Bikeshedding

Bikeshedding, also known as Parkinson's law of triviality, is a phenomenon where people focus on small, unimportant details while ignoring more complex or critical issues. The term comes from the idea that people will spend more time discussing the color of a bike shed than the design of a nuclear power plant, even though the latter is much more important. It can happen in group discussions, meetings, and decision-making processes, where people tend to prioritize simpler and less controversial topics to avoid conflicts and feel more productive.

Argument: We should have GPIO pins on the SUCK so that we can have some level of future-proof and modularity
Refutation: No! We should call them "unused" pins

Red herring

Introducing a secondary issue that is often irrelevant or misleading in order to divert attention from the main topic or argument.

Argument: We should have a hybrid rocket engine and test it rigorously
Refutation: But what colour are you going to paint the test stand?

Ad hominem

Attacking the person making the argument instead of the argument itself.

Argument: We should use a platform agnostic toolchain
Refutation: You are a dumb person!

Appeal to authority

An argument from authority standpoint is when someone uses the opinion or testimony of an authority figure to support their argument, even when the authority figure is not an expert on the subject. It involves relying on the credibility of the authority figure rather than on the evidence or reasoning for the argument. This fallacy can be misleading because not all authority figures are experts in every field, and their opinions may not be relevant or accurate in certain contexts.

Argument: We don't need a central data logger, as it increases complexity
Refutation: We should because uWaterloo does it

D: ...voltage regulator heat sink was cut off...
A: Also what do you mean regulator was cut off??
D: The heat sink Part
A: Did you do the math before doing that?
D: Yes, Math is it won’t matter
A: show math pls
D: I doubled checked my thoughts with Austin last night

False Dilemma

Presenting only two options when there are actually more.

Argument: We should use Rust to ensure memory safety, for critical tasks
Refutation: We are using C++, we can use either C++ or Rust

False cause

Assuming that because two events occurred together, one caused the other.

Argument: An elevator is not a analogous environment to a rocket
Refutation: The code does not work

Second System Synrome

The tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence.

Adapter & Interface

SUCK

Standard and Unified Connector Kit

This standardises the connectors that connect all the boards on the stack together

This was done as a conclusion of RFC #202304162103

Layout

10x2 connector

Pinout

(left to right, topview)

The GPIO pins, should more accurately be labelled as unused or N/A. If these pins are used for any purposes, then they will be documented here.

Connectors

The physical header pins are non-reversible to ensure things aren't plugged in the wrong way.

CAN Bus

Priority Lookup

lower the number, higher the priority

Stack

This is how the stack is organised.

(top to bottom)

1. Radio Board
2. GPS Board
3. Flight Computer Board
4. PDB + Battery
5. Engine Board

PCB Dimensions

It is an octagonal PCB. Where each side of the octagon is 3 cm

Radio Board

Flight Computer Board (Flight Deck)

Components

Micro-controller

STM32F405RGT6

Sensors

• Acceleromater
  • 3x KX134-1211

• Gyroscope

• Magnetometer
• Barometer

IO peripherals

• multi-color LED arrays
• buzzer
• non-volatile external memory
  • FRAM

Error Detection

Each critical sensor is present in a group of 3, a voting system is used to determine the more precise output, which the assumption is, would also be the more accurate output.

PDB + Battery Board

Engine Board

Dissect, Select, Reflectm before you start architecting

You can't be an industry disruptor, if you don't disrupt the industry.

So, you wanna be a systems architext?

So, you wanna write clean code?

So, you wanna write OOP code?

So, you wanna write modular, distributed code?

So, you wanna specify requirements or be AGILE, or KISS, or DRY, or ASS?

So, you wanna be a 10x engineer?

So, you wanna optimise your code?

So, you wanna write unit tests/ do Test Driven Development?

So, you think you know how computers work?

So, you wanna build an MVP?

So, you wanna take technical decisions?

So, you wanna write documentation?