Infrastructure protocol for meetings, proposals, and action items

[starbelly]

For quite a while meetings, proposals, and action items have been some what arbitrary. We all show up to a meeting and we have rolling dialog, which is mostly fine. However, IMO it sets a not so good precedent. Namely, it doesn't require :

• you create an issue prior to the meeting for all to digest
• further it does not require you bring an issue to the table with decent rationale
• what's more it does not require the person bringing the issue to the table have a plan for acting on it

I suggest we make use of a light weight protocol like we do in building and packaging which so far seems to work well.

https://github.com/erlef/eef-build-and-packaging-wg/issues

This system consists of a two issue templates :

• agenda item : https://github.com/erlef/eef-build-and-packaging-wg/blob/master/.github/ISSUE_TEMPLATE/agenda-item.md
• action item : https://github.com/erlef/eef-build-and-packaging-wg/blob/master/.github/ISSUE_TEMPLATE/action-item.md

We all have ideas which is great, but if they are not well thought out, if the rest of the group doesn't have a chance to digest the issue before hand, and further if there is no clear plan on how to act on the item(s) (including who is going to own them) then meetings can become chaotic, issues get created but are rarely taken any further, etc.

This does not mean there can't be some rolling dialog at some points, but generally IMO we should avoid that.

[benoitc]

I would suggest rather we don’t base our activity on the meetings and keep opening tickets, discuss it and work on it asynchronously. We should reserve meetings to the review of current backlog and new tasks from it. Specific meetings could also be proposed by opening a ticket. In short let’s brake this routine anf focus more on day-to-day activity.

[starbelly]

Yeah, to me this, protocol doesn't require things be taken care of at a meeting, it can work async/online too. It's a forcing function if you will and I think it can better illuminate to people interested what's going on as well. Thoughts?

[benoitc]

What I am not sure to like is to have some specifics agenda for a meeting. I would prefer to have all things put in GitHub first. meeetings could be used then to sort items or clarify a point. Eventually tickets could be tagged as « need to be discussed in meeting» so it would be discussed in priority at the next meeting. That way meetings are just bridges between cycles of tasks. We could still have some specialized meetings when needed that could be tagged/projected on GitHub also. This method work well for some teams around and would be a good fit for us IMO. It would also make sure anyone can participate whatever their time zone. Thoughts?

On Tue 2 Mar 2021 at 18:22, Bryan Paxton ***@***.***> wrote: Yeah, to me this, protocol doesn't require things be taken care of at a meeting, it can work async/online too. It's a forcing function if you will and I think it can better illuminate to people interested what's going on as well. Thoughts? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#49 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAADRIQAHQ5CDNQK2HHGQL3TBUNDVANCNFSM4YNKXCCQ> .

-- Sent from my Mobile

[starbelly]

Yeah, that's precisely what I'm suggesting, it's just lightly structured. Everything goes into github first, that's the biggest part of it. It just so happens to support non-chaotic meetings as well.

[benoitc]

if we have an agenda template it basically means we will have an agenda, isn't it? We don't need it if we focus the meeting in handling the backlog and tag items. What is desirable imo is to comment each tickets that need it during the meeting and ensure we have milestones at some poiny.

[starbelly]

I mean yeah, it doesn't have to be THAT protocol, but I'd like to have some light weight protocol whatever that is. I just pointed to that one as thus far it's working for B&P, if it worked for this group, and possibly marketing, we may have a model that we can include in a "working group kit".

[benoitc]

I would like to try what I proposed: 1. Everything happen here (on github). All tasks and what motivate them should be described first there 2. Tickets enter in the backlog and should be tagged to their corresponding priority or feature 3. Meeting will be focused on prioritization of the backlog, fixing milestones and solving tickets that need more discussions. 4. Tickets that need discussions should be marked like this some days before the meeting 5. a task not described here doesn’t exist IMO this « protocol » would increase the transparency of the group and make our work more asynchronous. It would remove also the opacity introduced by the meetings and private chat on slack. Bonus point. Since every task would be documented first the work may not rely anymore on 1 person as it is now and would help new contributor to join. We can refine that over the time. Let’s try it?

On Fri 5 Mar 2021 at 01:22, Bryan Paxton ***@***.***> wrote: I mean yeah, it doesn't have to be THAT protocol, but I'd like to have some light weight protocol whatever that is. I just pointed to that one as thus far it's working for B&P, if it worked for this group, and possibly marketing, we may have a model that we can include in a "working group kit". — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#49 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAADRISXELMCLQ5M5HQHADDTCAP23ANCNFSM4YNKXCCQ> .

-- Sent from my Mobile

[starbelly]

That sounds good to me, it's essentially what I was proposing, so I'm on board with it. Let's kick it off with some issues for this coming meeting 🚀