RFC: More effective weekly meetings

[diwakergupta]

Hi all,

Building on #3542 and #3563 , I wanted to start a discussion on how to make the weekly meetings more effective.

First, to state the obvious: often with 20+ attendees, these meetings are very expensive. It stands to reason that continuously strive to make those meetings a good use of time for everyone attending. Also, to be very clear, none of the below should be interpreted as a critique for any individuals. Running these meetings is a lot of work (I know first hand), and I'm deeply grateful to Jude for shouldering that burden for so long.

This is the current standing agenda for the blockchain weekly meeting (doc):

• mainnet check-in
• testnet check-in
• Stacks 2.1 / L1 updates
• Discussion
• Action items

Observations:

• A lot of time is spent on status updates. Or more broadly, on information dissemination / broadcasts. Most of these updates can just as easily be shared async. IMO it's not a productive use of this meeting to just share info (of course there will be exceptions).
• By virtue of being the meeting "runner", @jcnelson ends up doing bulk of the talking. Often there isn't much actual discussion.
• While the meetings often end with "everyone know what they're doing?", IMO we can do a better job at tracking what's getting done on a weekly basis, and holding a higher bar for ownership, accountability and visibility.

So with this background, here is my proposal. As always, this is just one set of ideas and I'm sure there are other better ideas out there -- so please chime with your thoughts below!

• BEFORE the meeting: make sure any tasks that are assigned to you are up-to-date. Link PRs, if it's at risk or delayed leave a comment as to why, if it's done make sure it's marked as such etc etc. Most issues need NOT require live discussion during the call.
• WELCOME I recommend everyone starts with video ON. Obviously this would only work if attendees accept this as a shared norm, and obviously exceptions / caveats apply. But I think making this visual connection, even for a minute at the start, would make a difference. Attendees are welcome to keep their video on after this, but it's optional.
• REVIEW Go through any tasks from last week that are not yet done. Per prior agreement, tasks should be scoped to 3-5 days. Including PR turnaround time, any task that has been started should not take more than 1-2 weeks to be completed (i.e. PR is merged). For any tasks that are delayed, instead of a mechanical description of current status, discuss how to expedite / unblock and if there is any learning or improvement we can apply going forward.
• ASSIGN Individuals can quickly talk through what they're planning to work on this week. This assignment should be reflected on Github and all such tasks easily visible perhaps in a column on the project board. This can then be used for the REVIEW segment next week.
• DISCUSS Any topics that would benefit from a live discussion -- could be specific technical questions or process issues. Bigger, open ended questions (like design for a new system or service) would be OUT OF SCOPE for this meeting -- these should be tackled in smaller groups (whether sync or async, as appropriate)

How to handle TRIAGE of new issues? There's been some discussion around setting up an ON-CALL rotation comprising of core contributors. One option is to make this an ON-CALL reponsibility:

• Conventionally, the primary on-call would be the first point of contact in case of any incidents. But most weeks there are no such emergencies (and let's keep it that way!🤞🏽). So my proposal is the on-call use time during the week to, among other things:
• Triage any new issues -- assign priority and make sure issues are "right sized"
• Review stale issues (needn't be done every week, maybe once a month or every other week). We also need to do a sweep of stale issues that have been since closed -- I suspect many of them are still relevant.
• Work on eng quality tasks, work on CI/CD, fixing flaky tests, making tests faster etc.
• Work on documentation (rust docs, wiki etc)
• Review any ImmuneFi reports

I suspect there'll still be new issues that require further discussion in person. The hope is that most of new issues can be triaged in a straight forward manner, and only a few issues (if at all) would require live discussion.

Would love to get thoughts from @jcnelson @kantai @igorsyl @saralab @wileyj for sure!

[igorsyl]

Thank you for your thoughts, @diwakergupta! I have considered this advice for sBTC Tech Planning. What did you think of the format for the Blockchain Architecture meeting on 2/17?