Change Call Format: Async Updates, Biweekly for Specific Issue Discussion, Occasional Calls for Deeper Discussions

[ghost]

(revised 2018-11-11 to reflect discussion in the comments below)

Statement of Problem

Currently our bi-weekly call is 30 minutes. This is just enough time for the "standup" portion, but it does not leave enough time to discuss complicated issues, which is the main reason for doing a synchronous conversation.

Proposed Solution

• Keep call length at 30 minutes
• Do the done, blocked, next stuff async (like js and go already do)
• Use synchronous time to discuss complex topics requiring synchronous discussion. Topics should be proposed ahead of time in the usual agenda doc.
• Periodically, there may be a complex issue that cannot be resolved within the bi-weekly time. We will schedule other synchronous calls for those, as needed.

Next Steps

I am open to other suggestions. If there are no additional replies by end of this week, I will implement the above plan by changing the calendar event.

[Stebalien]

So, we had the same issue in the go-ipfs one but we fixed it by:

1. Having everyone fill in "done, blocked, next" ahead of time.
2. Cutting the synchronous standup to "big" items. That is, we juts go around in a circle calling out important things.

We may still need an additional 30m but we may want to try something like this first.

[ghost]

Yeah, you're right, we need to move to the Go Core Engineer meeting model that @diasdavid designed. It's vastly more efficient. It's going to require setting up a rotation to create the call issue each week, create the cryptpad, make sure people fill it in ahead of time, etc.

I'm thinking we should try to do both. Extend the meeting to 1 hour so that everyone blocks the extra time on their calendars, but aim to not use the extra 30 minutes most weeks unless it's really needed. WDYT @Stebalien ?

[Stebalien]

I'm always a bit wary of extending meeting times as meetings tend to fill the space allotted. However, if we explicitly mark the second half as "reserved for complex discussion", I think that's totally reasonable. Even if we scrunch down the standup portion, we'll still likely not have time for discussions like that.

[raulk]

Just wanted to chime in to say that I agree with what you’re both converging to.

As the community grows with external parties, I’m more comfortable with a standup model that scales O(logN) and not O(N).

[jacobheun]

I'd also prefer to not extend the meeting time unless it's needed. I think we should just remove the standup portion of the call altogether.

Having everyone fill in "done, blocked, next" ahead of time.
I think we should definitely do this. Even if we don't do the standup on the call we can still get a quick look at what everyone is working on, and other teams / community members can see what we're up to as well.

This would give us the full 30 minutes for agenda items, preferably those that need a discussion. It may make sense to add the optional extended 30 minutes if we we're still regularly running short on time, but I'd really like to see us change the format up first before doing so.

[daviddias]

"work expands so as to fill the time available for its completion"

This is one of the famous Parkinson's Laws. It is sometimes applied to the growth of bureaucracy in an organization but it also describes the phenomenon well that happens when things are not optimized.

A corollary to it is that "Work contracts to fit in the time we give it". Read more at https://en.wikipedia.org/wiki/Parkinson%27s_law

My advice is to learn how to optimize the meeting first. Here is a collection of articles to inspire you:

• http://projectmanagementhacks.com/meeting-tips/
• http://www.asianefficiency.com/podcast/087-john-poelstra/
• Recommended books:
  • Rework
  • Deep Work
  • Getting things done

[Stebalien]

I believe the idea is to effectively have two meetings:

1. The bi-weekly meeting.
2. An as-needed, blocked-off design discussion meeting.

We can shrink the bi-weekly part but many technical discussions won't fit in a 15 minute slot.

[ghost]

Thanks for all the feedback on this issue. Let's definitely switch formats for the next call (a week from tomorrow).

One question: won't the done, blocked, next async updates be duplicative with each week's Go and JS engineering async standups? I'm hesitant to ask people to write the same report twice. Is there any scenario where the two would differ?

[ghost]

(re-titled this issue as we all seem to agree not to lengthen the call atm; the best summary is the tweaks described here ^^)

[Stebalien]

Copy/paste? There are also a lot of libp2p spec/project things that won't make it into the go/js meetings. But that's also a reason to make it async.

[ghost]

Doesn't copy/paste feel weird though? It's like engineers are doing redundant administrative work simply because of the org structure. Maybe we could leave it to people to provide a pointer to their {$LANGUAGE} Core Dev Sync cryptpad update, and then add any libp2p-specific stuff in the biweekly's cryptpad?

There are also a lot of libp2p spec/project things that won't make it into the go/js meetings

Yes, I definitely agree with this. That should be in the libp2p bi-weekly's cryptpad for sure.

[ghost]

Steb, are you doing copy/paste for the IPLD Bi-Weekly?

[Stebalien]

Well, we had our first today so I just put everything IPLD related (not much). Honestly, the "go core" meeting has been a bit ipfs focused.

Really, I think you're probably right. We might as well cover small bug fixes etc in the language specific meetings and then higher level libp2p endeavors here.

[ghost]

Closing - resolved. See #16