TL quarterly planning process RFC #97
Conversation
maniarathi
requested review from
justincc,
kislyuk,
parthshahva,
rexwangcc,
samanehsan,
mckinsel,
hannes-ucsc,
xbrianh,
NoopDog and
sampierson
maniarathi
changed the title
maniarathi
force-pushed
the
maniarathi-tech-planning-process-rfc
branch
from
459d1e3 to
39af982
Compare
maniarathi
force-pushed
the
maniarathi-tech-planning-process-rfc
branch
5 times, most recently
from
801d396 to
3ea6769
Compare
|
|
||
| - Quarter 1 (Q1): first Monday of January -> last Friday of March | ||
| - Quarter 2 (Q2): first Monday of April -> last Friday of June | ||
| - Quarter 3 (Q3): first Monday of July -> last Friday of September |
There was a problem hiding this comment.
It doesn't really matter, but this is kind of a weird way to define quarters. For example, this year it would leave a 9 day intra-quarter period between Q3 and Q4.
There was a problem hiding this comment.
Removed it altogether since the Roadmap and Planning RFC doesn't contain it.
There was a problem hiding this comment.
Looks like it's worth a whirl :)
However, it does seem a bit heavyweight. It would be nice for us to be conscious of the burdens of process and planning, and put some effort into (iteratively) streamlining them. It's preferable for developers to develop more and process less.
|
|
||
| | Week in Milestone (Week in Quarter) | Deliverables | | ||
| | :----: | :--- | | ||
| | **M2W3 (Week 7)** | - Each component MUST enumerate the work they believe the DCP should prioritize in the following quarter, along with rough estimates of time (sized using T-shirt sizes) and specify any other activities that will also occur (e.g. onboarding new team members) and rough estimates of time. | |
There was a problem hiding this comment.
If this process is meant for TLs to surface their thoughts about the technical requirements of the DCP, specifying "other activities" seems like a distraction.
There was a problem hiding this comment.
I put this here because I feel like one of the common reasons for overcommitment is not allocating enough time to other activities. Surfacing them at least creates some constraints when trying to consolidate things because when you see everything on the table, you realize that the math doesn't check out.
^^ last sentence somewhat stolen from Marie Kondo.
| of what TL would like to prioritize work on in the following quarter. | ||
|
|
||
| **Component:** Also known as a “Box” or a *chartered component*; represents a piece of the DCP led by a TL and worked on | ||
| by a team of software engineers. The list of chartered components are maintained |
There was a problem hiding this comment.
nit: some chartered teams consist of not only software engineers, but also computational biologists and ontologists (e.g. DataProcessingPipelines)
|
|
||
| **TL Roadmapping Shepherd:** Each quarter one TL acts as the “Shepherd” to make sure the TL planning process takes place | ||
| in time to produce the expected Technical Objectives RFC for presentation to the TL+PM planning meeting. The Shepherd | ||
| role will rotate once a quarter according to a spreadsheet drawn up post the approval of this RFC. |
There was a problem hiding this comment.
It'd great for the TLs on duty if they could get notified (by people or by some cron jobs) at the beginning of each Q, or at least a few weeks before their shepherd role starts.
…g process such that TLs are able to surface technical priorities via an artifact to the quarterly TL+PM call that will shape the yearly roadmap of the DCP.
| | Week in Milestone | Deliverables | | ||
| | :----: | :--- | | ||
| | **M1W1** | A Google Doc is sent out (either the previous document used from a previous quarter or a fresh document) to the Technical Architecture team in order to solicit input on what are deemed to be important technical areas of improvement that should be prioritized in the upcoming quarter. The input to this document is free-form and TLs may or may not choose to participate, with the understanding that if no participation is given, no objectives will be generated. | | ||
| | **M1W2** | The Technical Architecture Chairperson (Chair) will spend the week coalescing the free-form text into concrete objectives that will be presented in the Technical Architecture meeting. A discussion will ensue to form consensus around the objectives and if no consensus is met, the entire set of objectives will be included in the RFC for further debate during the RFC's community review. | |
There was a problem hiding this comment.
I recommend the consensus part is spread over 2 weeks rather than one, so that someone who happens to absent one week still has a chance to comment on the second. Or this could be left to the RFC period. What do you think? Otherwise lgtm.
There was a problem hiding this comment.
Hmm maybe my language isn't clear here? That's actually what I was going for.. M1W1 was part one of consensus and M1W2 was week 2 of consensus building? I was trying to say that if somehow it's done by W1, then we can skip week 2.
maniarathi
force-pushed
the
maniarathi-tech-planning-process-rfc
branch
from
8aa051e to
19e2767
Compare
|
Per the comments in today's Tech Arch discussion, one additional week has been added to the process to accommodate up to two Tech Arch calls for technical objective discussion. |
This process has been heavily modified since the last activity on this RFC back in August and therefore is going through a second full round of RFC review. If you have approved the RFC in the past, please revisit the document.
November 18th: Last call for community review