Project Management

[VMFortress]

We now have a team project! If you have opinions on how you think the project should be organized, mention them here!

[Advay17]

Just to confirm, is P1 high priority, or is P5 high priority?

[VMFortress]

Actually, I'd assumed the opposite (those were the default GitHub provided) but now I see that could be unclear. I think I'll change that. Maybe Very Low, Low, Medium, High, Very High? Or should it match our existing None, Low, Medium, High, Max?

[Advay17]

Honestly, either one is fine IMO

[VMFortress]

Updated it with the first option

[VMFortress]

I'm debating adding an additional field field for criticality alongside the existing priority category.

To be clear on the difference:

• Priority is how soon it should be done over other tasks
• Criticality is how much it impacts the system

Examples:

• High Priority, High Criticality: Primary auto causes the robot to go wild and crash into things as a competition
• Low Priority, Low Criticality: A comment has a misspelled word or a print statement is no longer needed
• High Priority, Low Criticality: A preset is incorrect but can be manually adjusted until fixed between matches
• Low Priority, High Criticality: Running back-to-back autos in the simulator crashes the code completely but you can just work around it by restarting the sim

It's not uncommon for people to just skip criticality as being unnecessary but I'd like to get any thoughts from the team.

[Advay17]

The biggest issue with this would be understanding the nuance in the difference between priority and criticality. Honestly, even looking at the examples, criticality and priority feel very similar to the point where there may not be a use in differentiating them. However I'm still on the fence, as knowing how soon we have to do something vs. how important it is to do something would be very useful.

[VMFortress]

It can be a lot to handle. Many of these things with project management can be hard to get everyone on the same page with.

[Advay17]

Do we want to have guidelines on what constitutes an issue's size? I feel like I'm kinda on the fence on many issues, so having clearer guides such as "small issues have x lines, big issues change x lines and change x files..." would be helpful IMO.

[VMFortress]

That's a good point. Its definitely a difficult thing to do. It is some combination of:

• Lines of code changed
• Files changed
• Amount of testing needed on physical robot
• Amount of research needed (new, unfamiliar areas)

Probably some others as well. I can look into what people usually use as guidelines unless anyone else has other ideas.

[VMFortress]

Not completely satisfied but what I put in there now:

• XS: Trivial change. Very low or non-existent risk. No robot or simulation needed.
• S: Small and isolated task. Few lines of code. No physical robot needed. May lightly use simulation.
• M: Moderate complexity. May touch a couple files. May require minimal robot testing (<1h) after simulation verification.
• L: Significant effort. Complex or has unknowns. Multiple parts or dependencies. May involve robot access (2-4h).
• XL: Very complex. Risky or cross-cutting. Likely needs splitting. Likely requires sustained robot access (>4h). May involve subjective iteration.

[Advay17]

Do we want to add repo specific projects for things like Vision, Auto, Mechanisms, etc.?

[Advay17]

Ooh, now this becomes a discussion again, and somehow the names match perfectly. Do we want to make the transition to github projects alongside the rest of the team's transition to project? Feel like it would be perfect for issue management.

[VMFortress]

I don't think it's a bad idea, just a matter of figuring out how we want to organize them. Especially as many issues span across multiple fields so how do we want those handled. The answer might just be that that span is its own project.

[Advay17]

Can issues not be assigned to multiple projects?

[Advay17]

In addition, we may also want to make GitHub teams based on these projects, as it would make assigning work easier

[VMFortress]

Might be able to do that. We'll just have to find the bast way to separate the projects. I think we don't need to rush into that right now though as I'd like us to at least get a cadence with one project first.