2024-05-13 Leads Meeting

Emma for ops vote

• digital media stuffs, been on for over a term

• unanimous as usual

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)

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

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

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

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

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

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

DRAFT Open Source Licencing

• mech cad isn’t public so no point in licensing right now

• make license for software only

• determined hardware would be closed source

• https://github.com/UWARG/hardware/tree/master/Projects ← ee hardware is open source

• https://www.oshwa.org/definition/

• make ee stuff not be open source

how do we play anni card?

https://uofwaterloo-my.sharepoint.com/:w:/r/personal/uwarg_uwaterloo_ca/_layouts/15/doc.aspx?sourcedoc=%7B8f8410c1-858b-4a41-bc68-78c0767ef01d%7D&action=edit

no ideas, Daniel will go for it

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 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