Summary

Summary of the rest of the document, outlining main challenges and action items. Ignore the specific technical stuff for now.

• Challenges & Action Items
  1. Lack of requirements
     • Outline requirements before designing something. Keep them as simple as possible; don’t add a requirement if it’s not actually a requirement. This prevents unnecessary work.
     • Requirements should be set so that the team goal is accomplished
       • Define a specific goal: How long do we want our CubeSat to remain functional in space? What timeline are we shooting for?
  2. Members wouldn’t take on the “boring” tasks: infrastructure, research, PR reviews, etc.
     • Not sure how to handle this
       • We sorta need a mindset shift to doing whatever is needed to create a space-ready CubeSat. If we can do that, then ideally, people would start completing these tasks.
     • When a PR is made, tag 2-3 specific reviewers on Discord. Publicly tag them again if they don’t review within a certain amount of time. It’d be nice if we could track how many PRs each member has reviewed (there’s probably a GitHub action we could use)
     • In-person PR review sessions
  3. FW and HW deadlines were not met; estimating deadlines was hard.
     • More communication about task progress. If a ticket isn’t progressing, hand it off to a more senior member and work up in seniority.
     • Break tasks up so deadlines are easier to estimate
  4. Most members didn’t commit enough time to be given high-priority/”interesting” tasks; major tasks were too vague and open-ended
     • Major tasks can become “epics” led by a senior member who handles architecture and breaks the “epic” into sub-tasks. Regular members can be given these sub-tasks.
  5. The number of active members fluctuated a lot. Some months, we had 10-15 active members, while other months, only the leads and 1-2 members were active.
     • Make the onboarding challenge harder (less like a step-by-step guide) so we know members have at least a certain level of commitment
       • Level 1 onboarding unlocks level1 tasks. Level 2 onboarding unlocks level2 tasks
       • Weekly onboarding help sessions
     • Need to start pushing for more commitment from people (4-5h/week)
     • Create list of members at beginning of term (push for members to be active throughout the whole term)
       • If members want to join later, add them on a case-by-case basis
     • Quality over quantity
  6. Members wouldn’t create their own tickets or ask many questions
     • Try to promote asking questions (in public channels) and thinking of stuff we can implement/improve/fix. It requires members to be a bit more proactive about things.
• Ideas
  • Monthly technical presentations by sub-team members after they complete a major project. They could be ~5min at the end of a general meeting or something.
  • Switch weekly subteam meetings to subteam work sessions (move member updates to being asynchronous)
    • Not sure if this would work well with some people being off-campus

General Notes

• Would monthly technical presentations be useful?
  • Once a major project is complete, it’d be a good way to provide an update to the rest of the team. These could also be held internally for the sub-team.
• What’s the actual goal for this CubeSat? How long do we want the CubeSat to remain functional in Space?
• We need more commitment. We should start saying members should be able to give ~5h/week to Orbital work if they want to get something out of it. We can’t give important tasks to people who can’t commit at least that much.

Software

What went right

• We completed a minimally functional CDH system
• We have a core set of experienced members/leads who’ll continue to next comp

What went wrong

• Not many people wanted to work on infrastructure and research tasks (toolchain, CI pipeline, testing, etc.). These are very important as they make development a lot easier.
• Some tickets are vague and open-ended (ex: Design the command manager) which is difficult for a newer member to work on.
  • These could be good “epics”. Maybe we could have 1 senior member assigned to each “epic” and they’d break it up into several tickets that newer members could complete?
    • Consider switching to a different project management software
      • I think Notion or GitHub Projects should be fine, but there could be an argument to use JIRA, Trello, Clickup, etc
• Only 2-3 people would create tickets
• Only 3-4 CDH members/leads would review PRs
  • What if we gamify this?
• Back in the day, we tried to architect things so that other teams could avoid FreeRTOS. We changed our minds about this pretty much immediately tho.
  • Some of our architectural decisions were probably still impacted by our team structure. We should revisit the architecture.
• Lack of integration with other subteams. We had some great integration with Comms near the end of comp, but it all should’ve started much sooner.