Weekly dev meeting purpose/format

[ghost]

With all the recent Zulip discussion around the weekly dev meeting's format and recordings, I thought to start an official topic about it where we can toss around ideas, and hopefully come up with some agreed standards going forward.

Please note that this is specifically discussing the weekly dev meeting, not the fortnightly outreach or design meetings.

It occurs to me that we're trying to come up with solutions (what format should the meeting take, should it be recorded or not, etc.) without really defining what the problem is... So my question is this:

What is the purpose of the weekly dev meeting?

Some thoughts that come to mind:

• Give the wider community an update on how Backup development is progressing
• Solve problems, unblock issues, review PRs, etc.
• Decide where effort should be focused for upcoming bug/minor releases

Until we decide why we have weekly dev meetings, I don't think we'll ever successfully come up with a plan on how best to run them.

Once we decide on the purpose for these meetings, then we can discuss what format they should take. I think it's obvious that different formats suit different types of meetings (e.g. the traditional reading through the agenda of current issues, etc. is better suited to a community update-type meeting, whereas a 'sprint' type format is better suited to a problem solving/unblocking-type meeting).

Also dependent on the purpose/format of a meeting is whether or not it should be recorded for the benefit of those not in attendance. Some formats lead themselves better to a recorded meeting, while others maybe not so much.

It may be the case that there are mutiple reasons why we'd like to have these meetings, and so maybe we need multiple types of meetings... E.g. alternating each week between a community update meeting and a 'sprint'-type meeting, or adding a third type of meeting at a different timeslot.

Let's discuss!

[docwilmot]

Excellent summary/intro

It may be the case that there are mutiple reasons why we'd like to have these meetings, and so maybe we need multiple types of meetings... E.g. alternating each week between a community update meeting and a 'sprint'-type meeting, or adding a third type of meeting at a different timeslot.

I feel that two main types of meeting are needed/intended: community updates, and decisions about issues. Community updates would likely be both to let the community be up to date, but also pitched in a tone that would encourage potential users to want to try our great software, similar to a promotional campaign. But decisions would require a more "business" type setting, to hear issues, grievances, problems and get consensus on moving forward. I think our meetings have managed to have both, but neither well.

There are I think two main reasons why I raised the idea to revise the format:

• The community updates are repetitive. I think that this is likely to drive people away rather than encourage.
• The business aspect could use some more formality, so that persons hoping to move on with a problem arent disappointed after waiting a week, sometimes more, for some guidance. Even worse when we spend disproportionate amount of time discussing matters that move small areas forward, at the expense of focusing on big picture perspectives. Unfortunately I (and maybe others) have come to see meetings as the time/place to get decisions, rather than via the GH UI.

So my hope was simply to remove the repetition, and make it more reliable to get a decision when one is needed. Maybe we cant or shouldnt do both, and need to have two types of meeting? Or maybe we can have a non-meeting process for making decisions and keep the meetings community and promotional. Is there any tool that helps there?

I dont know if a weekly recorded meeting lend itself well to sprints TBH.

Again those were my thoughts, and I'm happy that we are discussing it further.

[ghost]

Unfortunately I (and maybe others) have come to see meetings as the time/place to get decisions, rather than via the GH UI.

I have noticed this too, especially when requiring input from @quicksketch. It seems the weekly dev meeting is more likely to get his eyes on something than a ping in an issue...

I think an ideal meeting from my POV is one in which updates for the community can be mentioned (e.g. new modules, PMC updates, requests for help with such-and-such, etc.), then a focus on issues/PRs that need attention, either by members who attend meetings but aren't as active in the queue, or which need discussion that happens better 'in person' rather than via comments.

So it seems to me like two purposes for weekly meetings are/can be:

• Community updates (hear what's happening, what's current, where people can focus efforts, etc.)
• Getting help with issues/PRs (be it decisions, direction, guidance, etc.)

[stpaultim]

Good topic and good ideas.

Here is what I think the weekly dev meetings are good for (the purposes they are serving):

1. Community Updates and Announcements. I don't think that these take up too much time on the agenda and I find them helpful.
2. Drawing attention to important issues that might otherwise drop of the radar screen of contributors. This is where the existing format is useful (despite it's drawbacks).
3. Addressing blockers and/or making decisions to move issues forward. I think that this works better for participants that are able to attend the meetings. If I'm stuck in the issue queue, I find the weekly meetings an opportunity to ask questions, get feedback, and/or get a decision on something I need a decision on. I try to bring issues up that other people who can't attend would like to see addressed as well, but certainly it's always more effective is you are able to be there yourself (which is often not possible).
4. There is a social/community aspect to these meetings. For me participating in them live helps keep me connected to the community.

I also like to have "work" meetings or scheduled time to work together on issues, but it might be that these meetings are not the best place for this.

[indigoxela]

I see some consensus re the purpose of the dev meeting: several people (including me) think that there are multiple. 😄

Although some concerns were raised, that pure working sessions (sprints) aren't really suitable for recording, I wouldn't completely discard that idea yet. Maybe we just have to figure out how to tweak it, so at least a short portion could get recorded – to show a wider community how things get done in Backdrop. But maybe it still doesn't work well for the scheduled format.

Regarding the decision purpose: I'm a bit skeptical, that the dev meetings are a suitable place for conflict resolution – such stuck issues probably need cautious handling and shouldn't get discussed in public.
Decision and guidance if an issue needs help with the direction to go (it's unclear which way is recommended) – this might work, but could be a challenge. Especially if it's necessary to evaluate possible side effects of a complex problem.

IMO one central purpose of the weekly meetings (all of them) is to reach a wider community. But I think the current format works fine for that. Sure, some repetition should be reduced, but from the outreach perspective they all work.

[philsward]

For the "sprint" idea, I think it would be cool if one person could kind of control the narrative and share their screen and talk about what they are doing from the code side.

Sprints, I won't have any interest in personally, but someone who codes might like to look over the shoulder of the person doing the coding, or review or whatever when playing back the recording.

Sprints could become tutorial type lessons while also being productive in moving issues forward.

I think this would solve the silence problem while also making it entertaining and informational.

There's also plenty of video editing solutions that are designed to cut and "remove the silence", so there's really no excuse not to record sprints and post them though that format would probably be painful to listen to which is why I suggest a lesson and screen sharing format.

My biggest complaint with dev meetings is the lack of progress. I've been away for 4 months and the same issues are still there. Maybe if we agree to dedicate 3 hours per month to focus on some of those issues, we can move closer to getting them off the books so new issues can be added and dev meetings feel fresh and exciting.

It's not that the dev meetings in their current form aren't entertaining, the content just feels stale and stagnant from week to week.

[docwilmot]

Related, should we revisit priority tags? I suspect part of our issue is that everyone works on their own little parts of the project, then we all wait to get each other to review stuff, when in fact "each other" isnt really interested that much in your little thing, just his/her own little thing. So forward movement is slow. This is a theory.

[philsward]

I think you hit the nail on the head @docwilmot

[jenlampton]

A long while ago we talked about turning off the video recording at some point during the meeting, and moving discussions that were less useful for PR purposes to the end of the meeting, after the recording had ended.

We could revisit this format, but move the whole "Backdrop CMS Project Progress Report" after the recording had ended. That would leave the recording covering all the announcements, and anything anyone specifically added to the agenda that week that needed a discussion -- making it more useful for those watching later. But it would leave everything on the agenda that we usually talk about -- things that may not make much progress, but that serve as useful reminders to look at those issues (or milestones).