How to make meeting / discussion process more inclusive and asynchronous?

[felixfontein]

Summary

As pointed out by @ganeshrn in #33 (comment), the current meeting times make it hard for people from some parts of the world to participate.

This issue should be used to collect some ideas on how to improve this, so that we can discuss these and possibly implement some of them.

(Related issue: we have too many things to discuss in meetings and too little time for everything. Earlier suggestions were to move more discussions to issues, and have the meeting more for votes. That obviously also would help in this case, and similarly might other ideas discussed here.)

[ssbarnea]

IMHO, the only way to make discussions more inclusive is to ensure that decisions are not made during the meeting and that there is an issue/pr/discussion thread open for at least 48h before a decision is made.

I personally missed several meetings due to hours and I am sure that there is no time frame that suits everyone' normal working hours.

[Andersson007]

Random thoughts to consider as possible options:

1. Rotate the meetings. one at 6 pm UTC, next at 6 am UTC, next at 6 pm UTC, etc. Though it would require more discipline from participants to track the schedule. Doesn't fee as a perfect solution but, imo, is worth considering anyway.
2. Asynchronous discussion as was suggested. In the meetings we will basically decide if chosen topics are ready for voting, voting options, and vote. If we have time after voting we can preliminary briefly discuss next possible topics.

To make p.2 efficient, we could develop (yes, yes again) a policy:), aka protocol, to formalize the process (as any good, predictable, and stable system should have rules for inner and outer interactions):

• In addition to the chairman, another post, say, meeting leader, committee leader, or something like that. I see @felixfontein as the best candidate.

This person:

• Will be choosing possible topics for discussion.
• Will CC the steering committee members there.
• Will revise topics periodically. If he/she finds the topic discussed enough, will CC the committee and label the issue ready_to_vote or something a week / several days before voting suggesting options.
• On the meetings the committee will vote or discuss and choose possible options for voting based on comments in topics.
• If there's free time after voting, we can discuss something in real time.
• We'll add to the steering committee policy a note that this is a responsibility of a member to add something to the topic. E.g. a) I'm in favor of the proposal because... or b) I'm abstain as I'm not a specialist in the area, etc. so that the meeting leader will be sure everyone looked at the topic.

It sounds like a hard work and will require more time and effort than now.
There also can be two persons: 1. Committee / meeting leader (who leads the meetings) and 2., say, Agenda leader who will do the things described above and interact with Committee / meeting leader.

We can experiment with different ways.

3. Now folks from areas to the east of Europe cannot take part in the meetings and become the steering committee members respectively. If they can't discuss things and vote in real time, it doesn't mean they can't provide great feedback commenting the topics.

We could make an exception for such folks to discuss and vote asynchronously in the topics. It wouldn't increase participation in the meetings but it can increase involvement in the discussions. If we choose the only-voting-on-meetings approach, a leading person can count their votes as well.

[ssbarnea]

I am against rotating meeting hours. Based on my experience unpredictable times does reduce number of people joining. I do still have problems remembering which trash bin to put out each week and they are only two alternating colors. IMHO, even an inconvenient hour is better than variant one. If agenda is sent with 24h lead time, those interested will find a way to attend or express their opinion by email. -- that worked fined for openstack for years.

[Andersson007]

I am against rotating meeting hours. Based on my experience unpredictable times does reduce number of people joining. I do still have problems remembering which trash bin to put out each week and they are only two alternating colors. IMHO, even an inconvenient hour is better than variant one. If agenda is sent with 24h lead time, those interested will find a way to attend or express their opinion by email. -- that worked fined for openstack for years.

Sounds sensible. I didn't think it's a good idea but put it to have more options to compare and choose from.

FYI I also added p. 3 to #38 (comment)

[ganeshrn]

@felixfontein Thank you for raising this discussion topic and trying to make the community process more inclusive.

I have not sat through community meetings for a while but AFAIK if someone wants to discuss a topic in the meeting they have to post it as a comment in agenda topic and be present during the meeting timing or else it will be passed on, this IMO doesn't work well for folks in different timezones and this expectation itself might prevent folks to put things they have to discuss on the agenda list.

For items that have a wider community impact, the process of coming up with different solutions for a given discussion item and voting on which solution to pick can happen asynchronously. I agree that it will slow down the decision-making process but in turn, it provides a level playing field for all the stakeholders involved.

[tadeboro]

The sad truth is that there was little to no offline discussion on most topics we opened thus far. I am also guilty of not responding because it is easier for me to discuss things "live" during the meeting. And the only way to change this is to make async discussions mandatory in some way.

A good start would be a rule like "topics need to be discussed offline before we can talk about it in the meeting," coupled with another rule that specifies the time frame in which steering committee members must respond. And if we manage to add voting to this async schema, we could have community meetings mostly reserved for throwing ideas against the wall. The ones that stick should then be converted to the proper topic and discussed in an async fashion.

My lazy side already hates this proposal, but I feel something like this will be needed to make the processes more inclusive.

[samccann]

This is more work for the community lead, but since each community topic in a meeting needs an issue here - perhaps after a meeting, 'someone' copies the relevant meeting minutes into the related issue, as well as any subsequent 'vote' results. Then the issue is left open for xx days for community async discussion and final voting? How long it stays open depends on the importance of the issue.

We could also have a VOTE comment in here where each person give the vote a thumbs up or down or.. erm.. something we decide is neutral/abstain.

[pabelanger]

https://governance.openstack.org/tc/#how-to-propose-governance-changes should offer a good example of how to handle voting. The votes are recorded in gerrit (code review system) where the user proposed git patch. Then elected members vote with the technical chair being responsible for enforcing the house rules: https://governance.openstack.org/tc/reference/house-rules.html

This allows everyone a time window to discuss / review and vote.

[gundalow]

Added as a topic to Contributors Summit which is taking place on Friday 1st October.
https://hackmd.io/AcI9TZf_SZqi7NG3ZyplnA#Increasing-asynchronous-discussion

[GregSutcliffe]

Hello all! I have been promising to update this for some time - now is that time! 😁

As ever, this is kinda long, so here is my short version - I'm proposing that we stop the regular meeting and move to an "RFC-lite" style of proposal discussion, based on GitHub (because I think introducing yet more tools at this stage is a bad idea). My reasons are laid out below, and I'll be happy to discuss them at any time in the community room. This would be driven from the new spreadsheet-style project boards in GitHub, and I have started a prototype here

Note that this is not the final/formal wording, it's an outline. The next step would be to discuss this, and if agreed in principle, I will write up a formal text on how the process works for us to ratify.

---

Outline for async community development

Goals

1. We want to be more inclusive in our decision making - both in terms of timezone/geographical diversity, but also across a range of types-of-user. Real-time meetings do not facilitate this at all. However, we also recognise that these have a place in resolving difficult discussion points.
2. We need a way to resolve discussions - in many cases we are stuck with open discussions because we have no formal way to resolve them.

Difficulties

This proposal is a big change to how we work, and that's deliberate. Humans are interesting creatures. One thing I have noticed across many environments is a wish to avoid duplication, which is to be applauded. However, in this context, it causes a problem:

1. I have a topic to discuss.
2. I could go post about it in an async manner right now.
3. But there is a meeting in 2 days.
4. So I don't post it, I wait for the meeting.

In other words, the sync part of our process is actively interfering with the async part - and this is why I believe we cannot make incremental moves towards async (and why such efforts have failed before).

Thus, we (the current community working group) will need to make an effort to adjust our own actions while we get used to whatever we do next.

Requirements

Given the notes above, I think we need:

1. A big change to async as the first, default, and most common option
2. An official place to chat is inevitably needed for initial thoughts, refinement, etc
3. A formal process to resolve proposals

This is nothing new - it's an RFC process, as used by many communities. Much of what I write below is modelled on other communities such as Rust, Matrix, Fedora, etc - but made lighter because we aren't ready for that level of process yet (it'll crush us, and we'll go back to meetings).

Technologies

Async

The obvious choice for async discussion is GitHub - as contributors we are present there already. We also already have the Community Topics repo as a place to file proposals. We could look at new tools, but these will suffice to move to an async workflow, I think, and have a low overhead.

Using a repo also covers the needs around historical records, verifiability, etc.

Sync

Matrix (or IRC) will work well here. We have the Community Working Group which seems the natural place to discuss things if needed - more on that below.

Process

Here's an example of how a process might flow. I'm deliberately going to make this complex so we can see how it works - many proposals may be simpler in practice (largely because of mass agreement up-front):

To put this in words:

1. Person has an idea, and she talks through it with the community in chat.
2. Once she is satisfied with the idea, she writes up an issue in the repo
   • That issue will state the proposal, the perceived benefits and any necessary tradeoffs/negatives.
3. The issue is debated asynchronously on GitHub for some time. During this time, consensus is sought as the primary goal, and tradeoffs/compromises may be expected.
4. If there are blockers, complications, confusion, or impasses, it is acceptable to use real-time chat and/or video to discuss in higher bandwidth. Reports of these chats are expected to be posted back on GitHub (Matrix is useful here, since links can be generated to the appropriate parts of the chatlog).
5. When there appears to be some consensus (75% say?) among those who can vote (see below) then a "Community Team" (see below) member (and not the author) moves the issue to Final Comment Period (FCP), with an end date (say 2 weeks) and a default position based on the current partial consensus
6. The FCP gives a defined time for speaking out from those who still have concerns, and substantial deviations mean FCP is cancelled and discussion resumes in full
7. Otherwise the default dispoition is used at the end of the FCP period if there is no further significant discussion.

"Community Team"

I have referenced the "Community Team" several times - let me define that. There will need to be a group of people who shepard this process and are responsible for it. That group needs to be defined, and might be the Steering Committee, the Red Hat Community team, some mix of both, or something else - we need to define it. I would suggest the Steering Committee as a start (although I assume I will also be involved 😛). I am open to better names for this group 😁

Voting

Moving async means we can no longer use "those present can vote" (which is a bad model anyway). We will need to decide on who can vote - that could be "Community Team" (per above), or "everyone who wants to", or anything in between. However, without a defined group, it will be hard to evaluate when to move to the FCP, so I would propose that even if we use "anyone can vote", it is the votes of the Community Team that must reach 75% to trigger the FCP.

Assistance

It is quite acceptable for a proposal author to ask for assistance from the Community Team in building discussion, in which case a neutral Community Team member will help with setting up meetings between people for real time discussion, etc. Exact duties here need to be defined, the point is that the team should be available to help in a neutral manner

Tracking

With all this extra process, we will need a tool. I have created https://github.com/orgs/ansible-community/projects/2/views/1 using the new GH spreadsheet-style Project board, which seems suitable in the first instance - I will work on populating that with more of the open topics.

Outreach

With a defined async process and a good overview (i.e the project board) then it becomes easier to ask for input from the wider community too - something we identified in our goals. For example, we could summarise the project board on another website, call out proposals in the Bullhorn / Reddit, and so forth.

Considerations

I've avoided more onerous duties like writing a PR for merging as proof of acceptance, as I think this will harm adoption. We can of course revisit whether we need such written records later on, but for now, I think the log of discussion & voting on the GH Issue will suffice for most things.

I haven't talked about things like agendas - because if there's no regular meeting (see "duplication" above) then there is de facto no agenda either. Much of our frustration with the current process will go away with the meeting, in fact, we just need to avoid adding too many new frustrations.

---

That's all! I think the key point is that of duplication - this cannot be incremental. This must be a full switch to "async-first and sync-only-if-needed" if we're going to make this work. Please do come chat in the community room any time, I'll be happy to discuss (my handle is @gwmngilfen:ansible.im for those who aren't aware).

(By the way if you want to see some of my rough notes, research & thoughts, you're welcome to look at https://hackmd.io/o5r6XcDeTheMGeosKfN1Tw)

[Andersson007]

@GregSutcliffe thanks for the great work on the proposal!

I'm a bit worried about eliminating regular meetings (not against but worried).
Our current situation feels a bit fragile to me but I believe regular meetings should
discipline people somehow as other people expect to see them there and rely on their presence.
Also this is a social thing - I'm not a social psychologist but IMO if people don't hang out together from time to time,
the sense of community can be lost.

I think we should try the proposal, i.e. experiment.

How about keeping the meetings but having a ban on discussing the topics posted in community-topics and making any decisions resp.? Like the Open-Flor format?
They could be also not mandatory for the steering committee.

The goals of such meetings could be:

• Announcements (and discussing them - this is important! Maybe also announcing decisions made asynchronously)
• Raising concerns
• Discussing things before raising corresponding topics in community-topics (i.e. "Hey, folks, do you think this idea is worthwhile making a decision on?")
• Discussing random issues worthwhile discussing by Community and Steering Committee (except things raised in community-topics).

It's just a brainstorming.

[tadeboro]

I think the process proposed by @GregSutcliffe is almost perfect for the current maturity state of the Ansible community. Still, I have the same concern as @Andersson007: that removing regular meetings will harm the community.

I do not mind banning the decision-making from the meetings. I like this part of the proposal. But I feel that having a regular appointment can still be helpful for other things. These are examples that come to mind:

1. Having a fixed interval when individuals can interact "live" with the broader Ansible community and put their ideas to the test against a more extensive audience than just asking things in the chat at random.
2. Having a time slot for scheduled socialization. We do that at work (we call with "wasting company's money by drinking coffee" ;)), and it makes all the difference when it comes to building the "team spirit."

So, I think we should move forward with the drastic change to async-first but leave the meeting in place and just change its intention from decision making to throwing ideas against the wall and seeing what sticks and should be converted to a new async issue.

[GregSutcliffe]

I see where you're coming from, however:

1. We have the Social room now (and I see most of the "Morning" etc happening there now)
2. This then fails the inclusivity test that was on the goals to start with. Starting with me - that time does not work for me, so how can I come and develop that community spirit?

Thinking about @tadeboro's (1), that feels like the thing that @dmsimard is working on (not sure if you're ready to say more about that!). For (2), I have done that virtually, and it is hit/miss as it tends to be dominated by loud voices (frequently mine, the Foreman virtual coffee got renamed the "30min Greg Show").

I do agree with some kind of "office hours" in principle, but I think it would need very careful thinking about - and certainly a rotation across at least 2, if not 3, timeslots.

[ssbarnea]

+1 on @GregSutcliffe proposal, he already stated why so I would not need to repeat myself.

[tadeboro]

For (2), I have done that virtually, and it is hit/miss as it tends to be dominated by loud voices (frequently mine, the Foreman virtual coffee got renamed the "30min Greg Show").

This is something we can solve. I had the same "problem", but then I forced myself to listen before I talk and only allow myself one response per round of responses so that other members of the team had the opportunity to speak.

I do agree with some kind of "office hours" in principle, but I think it would need very careful thinking about - and certainly a rotation across at least 2, if not 3, timeslots.

We can be as flexible as we want here, but I still feel that having some kind of "fixed" schedule is a must. It is the obligation and responsibility of the community members to make at least some of the slots work for them. And from my experience, this responsibility is what makes the real difference when it comes to community building.

And I will stop now because I spent my tokens for this current discussion ;)

[Andersson007]

We can be as flexible as we want here, but I still feel that having some kind of "fixed" schedule is a must.

+1

[GregSutcliffe]

@tadeboro agreed on both points. This is what, for example, Fedora do with their social hour - it has a repeating early/late pattern. I'd be OK with that, coupled with a strict "no-business" policy :)

Also agree that we've found our positions, lets see what others say.

[jillr]

Thanks for writing this up @GregSutcliffe, I like the idea of a radical shift to async first. I won't rehash the conversation about having an office hours / coffee hour except to agree that something like that (on a rotating time) could be a great way to bring more people into the community, as long as it didn't become a revival of the current meeting with voting and such.

[felixfontein]

I'm happy with forbidding votes in the meetings - if someone wants to vote during a meeting, they can go to the corresponding issue and write their vote there. Having some form of meetings would be great, since they often allow quicker brainstorming / exploration of ideas than the asynchronous discussions. Maybe we could shift the meeting by 8 hours every week?

[GregSutcliffe]

Seems this was discussed on Wed, thanks for that :)

It feels like we have some consensus so far on the shift to async, and I'm happy with the ideal of social meetings - to be honest I would have suggested it as a separate proposal anyway, I think it's worthwhile so long as we don't detract from the "official" async discussions. So we're largely agreeing, so far.

In keeping with the rough process above, I will leave this for a while longer before taking action - I'd like to see some more votes or discussion before we consider a Final Comment Period. However, unless anyone objects, I will start drafting the formal text of the process so we can ratify it.

[cybette]

+1 for moving to async and voting in corresponding issues instead of during meetings.

I think it would make sense to have a fixed rotating time (oxymoron?) for meetings/social hour, as in, 2 fixed time slots alternating every week. for example, I have a CoP meeting with 2 sessions, I lead the "Atlantic" one for people in US east coast + EMEA, plus there's a "Pacific" session for those in US west coast + APAC. We then sync up over chat asynchronously 😄 Most people are able to join at least one of the timeslots, and a few even join both. This has worked quite well for about half a year now. For most people, that will mean one meeting time to remember, that happens every 2 weeks.

[felixfontein]

Just wanted to mention that right now, we have already (at least) two topics which expect an async vote: #51 and #55.

One more thing about the meeting: the meeting will also be useful to shine more light on what are the current discussion topics. It's less easy to forget about a topic if you listen to others discussing it in a meeting :)

And as I wrote in #55: I think it makes sense to usually have a period of 1-2 weeks for voting, depending on how urgently an answer is needed. I guess there are some topics where an answer is needed even faster, in which case the deadline can be even just 1-2 days (like the recent discussion whether 5.0.0 should be yanked), but that really should be an exception. Also when it is clear that a lot of people won't be around in the next weeks (because of seasonal/regional holidays like christmas/new year/thanksgiving/...), it is better to extend the voting period (assuming the result isn't needed that urgently). For #55 I suggested a period of four weeks, since the two week period would have ended on January 1st :)

[Andersson007]

As practical feedback regarding the workflow described by @GregSutcliffe, I would suggest the following changes:

1. Using the The Steering Committee term instead of Community Team.
2. Engrave in the workflow something like:

• A person from the Steering Committee formulates vote options based on the prior discussion
  and gives participants reasonable amount of time to propose changes to the options (2-3 days). The person
  summarizes the options in a comment and also establishes a date when the vote begins if there are no objections about the options / date.
• ~~In that date, the vote starts with the comment of a Steering committee person which opens the vote
  and establishes a date when the vote ends ($CURRENT_DATE + ~14 days).~~
• The person labels the topic with the active-vote label and moves the topic to the Active Vote column on the projects board (See the suggestion in the next paragraph).
• The person adds [Vote ends on $yyyy-mm-dd] to the beginning of the topic's description.
• After the vote ends, at least two Steering Committee members count votes and summarize the result in comments.
• The vote's results and the final decision are announced in the next community meeting.
• A steering committee person closes the topic OR
• If the topic implies some actions, the person assigned removes all irrelevant labes (like acitve-vote, in discussion, etc.) and puts the being_implemented label on the topic.
• After the topic is implemented, the assignee comments on the topic, removes the being_implemented label, add the implemented label, and closes the topic.

Instead, I could develop a set of instructions describing the whole process as a concrete implementation of @GregSutcliffe's workflow (i.e. a checklist which we'll copy-paste to every topic as we do in the collection inclusion repo).

UPDATED: P.2 above lives in #62 in a form of async workflow checklist.

==============================================================
About the board.
In the classic board we now have the following columns: Fresh, In Discussion, Final Comments, Resolved.

How about:

1. Renaming Fresh to Backlog? Currently we have a lot of topics about which
   it is hard to say that they are actually fresh:)
   Moreover, later we could move topics, say,
   from the In Discussion columnt to Backlog if a topic needs revision / rework / reformulation, etc.
   Also we might have a need to reopen topics sometimes, for example, when there are some unexpected
   things have appeared during its implementation and the topic needs to be re-discussed / corrected / re-voted.
   The term Fresh would not be relevant in many cases.

2. Renaming the Final Comments column to Active Vote?

3. Sometimes topics imply some work after a decision is made.
   Adding one more column called Being Implemented (or just WIP maybe)?
   Alternatively we could move topics to Resolved and use the being implemented label which already exists.

4. In the spreadsheet view I've failed
   to find a way to customize the blocks order (I would move Final Comments/Active Vote and In Discussion to the top.

What do you think?

[GregSutcliffe]

Hi all, sorry for my silence here, things have been busy :)

Firstly huge thanks to @Andersson007 for his work on the supporting documentation, it's a good thing.

I have 3 questions on where we're at with this topic:

1. I note the workflow doc makes no mention of the "action disposition" I originally suggested - I feel this is key to avoiding stalemates on votes, because then all participants know what the end result will be if nothing changes. Was this omitted from the workflow deliberately (in which, I'm very happy to debate the point :P) or by accident (in which case I can happily raise a PR).

2. Earlier (much, much earlier, sigh) I offered to write up a formal document for this process. Is this still desired, or are we happy to evolve on the workflow doc from @Andersson007 for now? I'm happy either way, just clarifying the current position.

3. We suggested moving the existing meetings to a more social and flexible format once the async process was working. Do we feel we're ready for that yet?

[Andersson007]

Hi @GregSutcliffe and thank you for the feedback!

1. I'm not sure what the term disposition means in this context. Is it a decision, i.e. a written statement describing the meaning of the decision? So default disposition is the original proposal (i.e. if no objections/suggestions, we'll use this statement for the following vote), right? So adding the default disposition to a topic's description is what you're suggesting, right? If yes, sounds very good to me:) Feel free to raise a PR (I'm also gonna simplify the workflow a bit soon, so I could do it along the way).
2. Not sure, it would be nice to hear opinions from other folks. For me personally, the workflow alone would be enough, though having some visual representation (as in your comment) would probably be helpful, especially, for newcomers to better imagine the process.
3. In my opinion, we are ready as the async workflow seems to work pretty well so far. UPDATED: changed my mind, i'm for keeping the meeting time as is, otherwise i think we can break the fragile equilibrium and end up losing the current regular attendees (people usually tend to love scheduled/predictable things). It's not necessary anyway. People interested in hanging out at another time, can easily organize another community meeting(s) working in parallel. Anyway, decisions are made async in community-topics

[GregSutcliffe]

@Andersson007 - moving to headers because lists can't have paragraphs :P

1. Disposition

disposition refers to the action that will happen at the end of the voting period, if no significant concerns or blockers are raised. Importantly, this does not have to be the acceptance of the proposal - rather, it should reflect the current voting result. So that might be a disposition to accept, reject, or perhaps defer for more discussion.

For a great example of this in action, look here - this repo uses this approach, and you can see the labels for "final comment period", "disposition-merge", "disposition-close", etc. I think it's a great way to avoid arguments about what should happen at the end of a voting round. I got the idea from here and that does a great job of explaining it:

When a member of the Spec Core Team believes that no new discussion points are being made, and the proposal has suitable evidence of working (see implementing a proposal below), they will propose a motion for a final comment period (FCP), along with a disposition of either merge, close or postpone. This FCP is provided to allow a short period of time for any invested party to provide a final objection before a major decision is made.

2. Existing doc

Comparing to your workflow notes - you may want to read through section 3 of that doc in particular. It's very similar in content, but I think it's quite precise in it's language, and I like the crisp clarity of the definitions it uses around voting, when different pahses start, etc

For visual representation - GitHub just added support for MermaidJS this week. Since that's what I wrote the original diagram in, we can add it to this repo and maintain it with standard code-review practice. I will send a PR.

3. Chat Meetings

Sounds good. I will propose a new topic for moving the existing meeting to a moving timeslot :)

Thanks everyone, it's great to see progress on this!

[Andersson007]

@GregSutcliffe thanks for the explanation!

1. Disposition - it sounds sensible though it would be good to see in it action

2. Final Comments period - I think since the vote is open we should just vote for or against and that's it. Folks will have enough time to raise concerns / suggest changes before the vote is open. Of course, if there are any blockers, people can bring them at any moment even during votes and after decisions are made. I'm personally not against but is this additional stage really needed at the moment? If we have the FC stage and someone misses this and bring a blocker later, will we ignore the blocker?

3. Visual representation - thanks for the PR! Looks very good.

4. Chat Meetings - i would suggest having as many options there as possible in the topic's description. Among other things:

• Having only the current meeting at the same time (i.e. keeping things as they are at the moment)
• Not having the meeting at all
• Having 2 meetings for different time zones
• Keeping the current meeting but making it moving
• ...

For options implying the moving meeting / additional meeting we could suggest possible options. It should also ask folks to provide their options.

@GregSutcliffe it can be a great opportunity (i mean the new-meeting-format topic) to show the folks how the "default dispositon" and other things can be used:) We're experimenting now and the workflow is rough and it's not a policy. Thanks for arranging this!

[felixfontein]

I think we're on a good track, though the general amount of discussion here is still not optimal. Anyway, since there are other / more current discussions on very similar / related topics (like creating a forum), let's close this one.