Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Current »

 Leadership Team
  • Emma for ops vote

    • digital media stuffs, been on for over a term

    • unanimous as usual (smile)

  • Ayoung stepping down

    • Hardy not a lot of thought on this

      • Hardy onsite next term so good there

      • Hardy step down after that and find someone to replace him in meantime

      • Looking to do nominations for this?

    • Why do we need three leads?

      • We need two leads for onsite target

      • Having more leads means less people know what’s going on

      • EFS is a big team

    • Project Manager vs Leads

      • pm is for a single project

      • could we use PMs for more projects?

    • Hasn’t been communicated yet (keep roles for now)

 Team Direction
  • Comp Focusing all projects

    • We want to learn by doing

    • Shift will happen slowly but this is where we want to be

      • zp will continue for now to keep most of EFS team occupied until new projects are properly scoped

  • What we don’t want to be

    • We’re not a research group

    • We’re not a pcb design club

  • Members need to understand the system before they should be given the go ahead for very technical stuff.

    • It’s brutal all our system engineering is wrapped up in a few people.

    • It’s hard to design a board without understanding the application (and even harder if it’s your first board ever)

    • will be discussed next leads meeting, very contentious

    • Daniel Puratich

      • you need to understand what your customer wants before u make a product

      • you need to see use case before implementing

    • R D

      • leads should provide resources and direction

      • we need to have leads who get the system instead

      • retention isn’t great, we put a lot of effort into onboarding but after the polish members are thrown into deep end

      • in autonomy people complained about getting easy tasks

        • new members constantly got easy tasks and not more development

      • we need to develop our members, this is hard, we dont have management experience,

      • management stuff is a lot of time, most people dont wanna be managers

      • most of warg’s management is sorta good enough

      • will get a lot of push back from people who want the interesting engineering when pushing for dedicated managers

      • we are hour constrainted, more managers is more inefficiency

      • low amounts of glue work is hurting warg https://noidea.dog/glue

      • monthly system time for questions, more of a presentation and explanation with diagrams, from tech dir Nathan Green for thoughts here

  • Do we all agree with this? this is big …

    • This is an interpretation of Team Charter , do we agree?

    • my examples are mostly ee related but arguments extrapolate to all subteams

  • Systems Meeting

    • Weekly sync for zeropilot program in addition to aeac? We’re in integration phase now, need mech stuff soon ish

  • Next Major Projects

    • Baby steps to learn and improve as we go!!

    • Pegasus is for two competition seasons, this one and next

      • give us more time for the harder developments for comp after

    • Fixed wing (then maybe VTOL) program is on the side

      • no proper plan, we discuss after comp, start simple, learn over time

      • smaller scrappy initially then go better over time

      • for anyone confused: https://en.wikipedia.org/wiki/VTOL

    • do AEAC this year (ofc lol) then once more for sure

      • , then SUAS? See how competition goes but we figure this out in future

  • Concerns

    • possibly we cant get tasks for all EFS people to work on

    • change name from EFS to firmware

    • “I have no concerns when it comes to the team direction. I think moving to CAN is a great idea and me (and other EE leads I think I can speak for them) emphatically agree that system understanding is a requirement among general members. We have discussed this in our own meetings and have come up with some ideas to remedy this.” -Nolan

 Meeting Notes Organization
  • No two pages can have the same name in confluence

    • this is challenging when the headings for each subteam are broad

    • for example not every subteam can do “S24 Meetings” so

  • We should standardize the organization and naming for consistency across subteams

  • I tried to stealth improve this, but most yall realized it was different and changed it back to what your subteam was doing before lol

    • I tried for something like “<term> <subteam> Meetings”

  • I dont care what we do, but we should have a standard across all subteams to avoid the oddities this causes

  • @xier

 Director Syncs
  • I put em roughly once per month and ones this week for some subteams.

  • Please move the time if it doesn't worky. Scheduling these is a lot of grind ngl.

  • no contention

 Asana
  • Is anyone using this?

    • most members dont use asana mostly leads and pms

  • Any thoughts on this as a system or has AEAC sync and the director’s memories kind of replaced the need for a ticketing system? Leads kinda do the same thing for their subteams.

  • Free for all reasonable for now: how are subteams using asana

    • mech looking into it, but have other systems (in confluence, meeting mins, disc, decision docs)

    • autonomy used for all projects and subtasks, PMs use it a lot, use outside of meeting mostly, mostly for leads and pms, most descriptions go into confluence

    • ee - doesnt use

    • efs - same as autonomy mostly, delegate to members, dont use conf for ongoing tasks, only leads use it

    • ops - most user is leads, pre similar

  • no strong feelings epic

 Bootcamp File Naming
  • How do we wanna play this?

    • could say “as of F23” but ugly heading?

    • the archive has no folders

    • rename to date they were archived when we move to archives folder

 New Confluence Pages
 Project Managers & Senior Members
  • Can we give them their own chat and access to the email (outlook) and such?

    • why do we need a specific PMs channel

      • distribute passwords

      • “I agree with this notion. I think bringing PMs closer to leads is a good step. I will admit that this doesn't hugely affect EE because we hardly have PMs”

      • see

    • pms in subteam lead chats

      • mech pms are in mech leads chat

      • autononmy does the same thing

      • subteams can do this themselves

        • should be done on case by case basis

      • should be done for all subteams so that PMs can ask for 2FA in those chats and other stuff

    • Why do PMs need email access?

      • oppertunity to upload stuff

      • dont need to be manually given the email, dont need to cc

    • Make a channel in #information

      • put all the passwords and such there!!

      • people wont talk in the channel

      • not that deep

      • flight test coordination & PMs should get it

        • for example wingchee does emails and stuff & ryan also PM

      • Daniel Puratich done

    • can we do it on a need to know basis like the bay code?

      • ok copy bay code one for this when the time comes

      • itll be annoying when they do duo

      • will be an edge case

  • Nathan Green Daniel Puratich agreed high level.

  • Clear difference between senior member and PM though?

    • more thinking go brrr

    • Project Manager Onboarding updates?

    • pure admin stuff grindset go brr

    • lots of PMs also fit IC definition

    • using senior member more often

    • PM leadership sync is good to get feedback!!

    • Organization Roles hard to find?

    • over documentation?

    • Role information is kind of scattered

    • Clearly outline role as a part of onboarding

    • bigger discussion for after?? next leads meeting

    • more Alison Thompson thoughts coming in future (smile)

 RFC System
  • Smile Khatri good idea for discussion (thx!!)

  • Directly merge into main in the future?

    • RFCs are a lot of work and RFCs are an extra barrier to documenting our system.

    • R D

      • Arch doc is meant to be an agreement between subteams

      • if anyone can edit it’s easy for subteams to get confused

      • Directly responsible individuals are cited in the document, changes must be approved by them

      • github PRs

    • Alison Thompson

      • could talk to each other more to avoid discrepancies

      • doesn't make a lot of sense for pure mech stuff

      • mech section is excessively vague to avoid RFCs

      • doesn't make sense for some workflows?

      • not anybody should edit it

        • lock document to just PMs and leads (make edits as suggestions)

        • writing too completely diff things is a lot (RFC then arch doc)

          • same thing twice

    • Daniel Puratich

      • lock arch doc to PMs and Leads

      • contentious changes should be discussed in AEAC

  • No labels