Rotation for the Monthly TSC Meeting Manager/Coordinator

[arm4b]

During the #1 we decided to plan periodic StackStorm TSC meetings every month (first Tuesday of the each month). @armab was conducting the first couple of meetings to start the wheels rolling.

Now the idea and proposal is to set up rotation for the monthly StackStorm TSC meeting Manager/Coordinator who will be conducting the talk and load-balance the team efforts.

StackStorm team rotation history

Historically we already did some rotations at StackStorm:

• "release manager rotation" between team members running the automation to get the new release out and lead the release efforts. We'll keep this tradition.
• "support rotation" was a duty for the team members to help st2 community, maintain CI/CD automation, answer emails, twitter, forums, Slack questions, triage Github issues, PRs, etc, etc during the week.

This kind of rotations greatly improved team collective knowledge about the st2 system and skillset. It also gets everyone involved in every single part of the system, eventually helping understanding priorities, raising important questions and making better decisions as a team.

The TSC Meeting Manager responsibilities

Now the proposed responsibilities for the TSC Meeting Manager (rotated every month):

• lead the ST2 TSC meeting (prepare the agenda, questions, review progress based on previous meetings, etc)
• put the TSC meeting report together after the meeting took place (like First StackStorm TSC meeting Minutes (Mar 3 2020): Plans for st2 v3.2 release & the Linux Foundation Networking #1 Proposal: Pin only minimum versions of pip and setuptools #2)
• connect the dots, oversee the balance
• distribute team members involvement: encourage less active maintainers to be more active, ask for help
• raise & follow-up on important questions that were unresolved before
• make sure we go together towards the StackStorm roadmap, encourage discussions about what are project priorities

Personally I had fun doing TSC meetings and believe it's an interesting responsibility that would be advantageous to do by everyone in the Maintainers team.
Practically this will bring more diversity to our meetings, balance priorities, inspire development and bring more energy.

@StackStorm/tsc please provide your feedback/ideas so we can polish this and execute better based on everyone's opinion.

[arm4b]

I'd propose to start experimenting with this and see how it goes.

For example, TSC Meeting Coordinator rotation could be based on current release manager responsibility so he can raise discussions around priorities during the meeting. Ex:

• v3.2 release responsibility is @armab and @punkrokk. If we'll have any 3.2 items left @punkrokk may coordinate next meeting.
• v3.3 release could be ran by someone else. This way they can conduct the monthly meeting, being interested in discussions around release plans/efforts.
• We could get even more creative, for example preparing agenda/conducing monthly meetings in pairs.
• In case of no immediate release plans/agenda, we can just rely on a sorted list of @StackStorm/maintainers for this kind of rotation.

[nmaludy]

I would love to have some tooling around this to remind people that they are on rotation.

Just spit balling ideas:

• Maybe we could have rotations setup in the st2community pack stored in the datastore? Have it round-robin based on a list and post messages to Slack?
• Not sure if there are external tools that we could use for this purpose or not?

[arm4b]

Per discussion TSC Meeting is best conducted by the Release Manager in rotation, - someone responsible for getting StackStorm Release out.

Release Management and Rotation is now covered by the WIKI page:
https://github.com/StackStorm/discussions/wiki/Release-Management-Rotation

[arm4b]

Per @punkrokk proposal during the Jun 2 TSC meeting (#31 (comment)) this approach had its downsides like missing continuity and team returned back to the previous model with adjustments to run TSC Meetings by the future elected TSC chair for at least 3 months.
cc @dzimine

[mickmcgrath13]

2 things that come to mind to resolve with this are:

1. Ensure there is an up-to-date list of TSC members who are candidates for rotation so that at the end of one TSC meeting, we can look at the list and call out who's next. To @nmaludy's point above, perhaps we could have some tooling around this to remind folks who are scheduled for rotation (maybe an action/workflow in the same pack that notifies of the tsc call to read the rotation list and notify #tsc ?).
2. Ensure that there is opportunity for a fallback if the active person on rotation becomes unavailable or unable to fulfill the responsibilities.

[arm4b]

This could be an example WIKI: Release Management Rotation that's been maintained for the past 2 years with the release owners.

From that perspective, usually Release Managers are decided on fly during the meetings or in #tsc Slack as we discuss the ongoing plans and projects, depending on people's motivation and availability for the foreseeable future. It may be hard to plan the rotation for many months in advance, considering how open-source maintainers operate with no strict obligations. Perhaps planning for the next one or two meetings in advance would be a good enough aim?

In terms of priority for running the meeting, this worked well so far:
Current Release Owners > Maintainers who weren't in rotation > Other Maintainer Volunteers
Where the current release managers would have a higher priority to run the meeting as they need to coordinate the release activities. If there are no volunteers or a sudden change of plans, Senior Maintainers can jump in and save the situation.

[cognifloyd]

Assign the meeting host for the next meeting in the current meeting.