[Feedback] Deliverables sync meeting

[choldgraf]

Summary

We're trying out a fortnightly deliverables sync meeting! See #148 for context.

This issue is a place to collect feedback and thoughts as we run through these meetings for the first few times, in order to help improve them in the future.

Let's leave this issue open for a few cycles of the meeting and see if it is a natural place to provide feedback, and we can close after we've had time to iterate a bit.

I'll put this in "Needs Review" for a few days after each meeting, and move it to "waiting" in between meetings.

Actions

• Collect feedback over a few weeks of running this meeting
• Incorporate feedback over time or in focused development
• Close this after a few cycles

[choldgraf]

A few thoughts that I had after our first deliverables sync meeting today (some of these may just be things that I need to work on personally :-) )

• Be more disciplined about not talking "meta / process" stuff at the beginning, even if those are discussions that need to happen, have them in the monthly team meetings or in issues elsewhere.
• Do a better job of sticking to the script of our actions to take in the meeting.
• We need to clean up the deliverables and the activity boards for this meeting to be maximally useful. The development board should have just the major things people wish to actively work on soon, not a laundry list of a million items (we can use the github repo issues lists directly for this maybe)

[sgibson91]

Do we need a process about what goes on the boards too? I've been adding PRs but maybe I shouldn't be doing that? E.g. my blocked items today were the issue and linked PR (one will close the other). In the case where an issue has an associated PR, perhaps the issue is enough and folks can find the PR by clicking through? But I also don't open an issue for every PR I make 🤔

[choldgraf]

@sgibson91 totally agree we should iterate a bit on the boards too...I feel like we don't quite yet have that process down

[damianavila]

Do we need a process about what goes on the boards too? I've been adding PRs but maybe I shouldn't be doing that? E.g. my blocked items today were the issue and linked PR (one will close the other). In the case where an issue has an associated PR, perhaps the issue is enough and folks can find the PR by clicking through? But I also don't open an issue for every PR I make

From previous experiences...

• when the PR was generated as a (or part of a) response to an existing issue, you only put the issue on the board and reference the PR in the very same issue.
• when the PR was created first but some general discussion is needed, create an accompanying issue and put the issue on the board, and foster the discussion on the issue.
• when the PR was created first and it is "self-contained" just put the PR on the board (it is actually behaving as a sort of issue-PR entity)

[damianavila]

@2i2c-org/tech-team, are there any notes from this meeting I can take a look at?

[damianavila]

@2i2c-org/tech-team, are there any notes from this meeting I can take a look at?

Or there were not any notes and it is just the issue content: #174

[choldgraf]

I'm going to close this one because I think that we're tracking discussion of our team planning process here: #182