TSC Agenda 2021-12-07 about tsc HOT 3 CLOSED

Would like to inform the TSC that the release-SIG is recommending a point release in early 2022 per Nov 23 meeting (notes here https://github.com/o3de/sig-release/blob/main/meetings/notes/2021%20-%20November%2023).
The SIG will discuss further in their meeting on 12/7 o3de/sig-release#27
Approximate Release Date: Jan 13, 2022
Hoping to discuss this in the 12/7 meeting. In particular the release-SIG would like to know any initial feedback or concerns from the TSC.

from tsc.

Would like to discuss RFC archiving (apologies if this has been discussed before):

• Currently all RFCs are siloed in SIG repros
• Have inconsistent standards for naming
• Discovery is becoming hard

from tsc.

Committee Attendees
Tobias Alexander Franke
Karl Berg
Nick Lawson
Jeremy Ong
Royal O'Brien

Observers
Claire Massey
Tony Balandiuk
Halle Ford
Pip Potter

Royal - Two commit rule because maintainer privileges are conferred to chair and co-chair. 5 sigs don't have people. Usual term length is 1-year.
Karl - Chair's role is logistical/organizational. Doesn't seem to have a need for the same technical bar
Tobias - You mentioned the term length on average is 1 year?
Royal - Confirmed
Tobias - Are there any negative aspects of having one year?
Royal - Too much churn in the chair role can cause too much volatility. Anyone who is a chair is within their rights to step down
Jeremy - Chair should be self-cognizant of limitations with respect to technical bar (abuse of maintainer privileges would be unexpected for someone occupying this role)
Pip - Security and ops are somewhat stranded pending advice from the committee (without chair/guidance). Time between nomination to election is fast (little time for discussion). Should consider longer lead time next year's cycle.
Royal - What cadence/lead time would you suggest?
Pip - At least a month of lead time to be aware that the elections were coming up
Jeremy - Is this a process sig-ops would ostensibly handle?
Royal - Sig-ops should cover all non-code related tooling, but processes should be governed by this group. TSC handles process because it's global to all sigs.
Pip - Community is a bit confused and needs some clarification, happy to direct questions related to overarching process to the TSC (e.g. GHI management).
Royal - TSC could provide direction to the sig-ops group on what automation could be needed for GHI
Jeremy - Chair elections were accelerated this year because some groups were without chairs in any official capacity at all, and direction was needed
Royal - Right, this was a middle path
Pip - Should chairs attend the TSC meeting
Royal - TSC can request chairs attend the TSC meeting, or set up independent meetings
Pip - Not much cross-sig organization/communication
Jeremy - Currently the mechanism used are comments on the TSC meeting agenda
(Royal to put out motion regarding sig chair requirements)
Jeremy - Pip did you get the clarity you needed regarding the role of sig ops (Pip: yes)
Halle - Sig-ops charter needs updating correct?
Royal - Yes. There's a PR for forming a governance document.
Halle - Is there an individual on the TSC responsible for updating it because the community has requested it
Royal - We should turn it into an issue thread to help accelerate it and get feedback on it. Claire is this an active issue already?
(o3de/community#105)
Jeremy - Next agenda item is discussing feature vs date-based releases
Karl - Dislike date based releases
Pip - Counterpoint is without strong technical program management, will be hard to coordinate feature based releases
Royal - Date-driven releases may result in "incomplete" features or missed features.
Tony B - Agrees
Karl - Feature-based deployment may not be as hard, there may exist a set of features that community can rally behind.
Royal - Cadence still needed to provide some predictability for community
Karl - Not great to have a release just for the sake of having a release. There's a cost to the process
Tony - We shouldn't avoid aiming for date-based releases just because it's hard necessarily
Jeremy - A compromise could be setting a particular cadence and requesting that sigs coordinate to advise the TSC on what features they would like to achieve each release cycle, with mechanism to provide slipping too far
Royal - That could work
Nick - We'll need a bit of a hybrid. Features need to fall in without a timeline.
Royal - TSC can't direct and make decisions on what's releasable without guidance from sigs
Tobias - Concern with feature based releases is that timeframes may vary too much.
Royal - Yes, there has to be a stopping point
Jeremy - Yea, cadence can't be too long or it will be hard for people to migrate between stable releases
Karl - Would migration be difficult if releases are far apart because nothing notable is shippable yet
Jeremy - I expect there to be an accumulation of migration cost due to incremental changes (thousand paper cuts)
Royal - Sigs should be planning based on what they believe is achievable within the requested cadence
Nick - There's an ad hoc approach based on date + sig feedback
Royal - Feels like there could be chaos with some sigs requesting to hold the bus, others requesting to catch the bus
Pip - Is sig-marketing an input to the release process
Royal - Sig marketing shouldn't drive release or process but can receive information about what features were slated
Jeremy - Does this group have thoughts on the cadence
Royal - Engine is changing really fast, too fast to match, say, a year-long cadence
Jeremy - Might even encourage a live-at-head model if there's sufficient volatility
(cadence to be revisited later)
Tony - There is a Rev the Engine initiative and a recommendation was made to consider a point release. This would be a release that contains a number of UX improvements without features.
Halle - Number of bug-fixes/ux in a branch
Royal - Sounds like a point release
Jeremy, Karl, Tobias - No objection
Tony - Will inform the sig-release group

Tobias - Internal work going on with terrain, would like to coordinate with others working on terrain
Karl - Should discuss with Terry M and Mike B
Tobias - Another thing brought up is bug prioritization, and the process related to it
Pip + Royal recommends leveraging existing triage meetings to pitch the bug and explain why it should be higher priority, in addition to leveraging GHI and discord.

from tsc.