# Thoughts on Community Process

Random musings in no particular order on https://github.com/ansible-community/community-topics/issues/38

## Defining the problem

What do we **want**?
- Better engagement with discussion topics
- Feeling like we're getting a rounded view of the community opinion
- Echo chambers are dangerous
- Groupthink etc

What are the blockers?
- Live chat means being present at a specific hour
- Very unfriendly to some timezones
- Also to people with other duties, eg work, parenting etc
- No pre-circulation of agenda
- Some effort to fix this with [community-topics](https://github.com/ansible-community/community-topics/issues) but it's lacklustre
- Out-of-meeting discussion is happening rarely
- Even more emphasis (and thus exclusion) on the meeting
- No highlighting of open discussions
- How do we get wider uptake in the discussion if we don't ask?
- Very little to link to in terms of existing discussion, no showcasing of process

## Themes

I think there's two parts to this:
1. How do we get better discussion of a specific issue?
2. How do we attract more participants to a discussion

These are largely independant, as we can try to attract more participants to the current meetings, as well as improve how the discussions happen.

## Other communities

How do other communities handle this? In no particular order:

- Foreman uses a [Discourse forum](https://community.theforeman.org/c/development/rfcs/18) with an RFC category. RFCs are adopted or not based on the discussions there, sometime with a vote but usually it is an agreed action.
- Matrix uses GitHub for spec change proposals (https://github.com/matrix-org/matrix-doc/pulls?q=is%3Apr+is%3Aopen+MSC)
- https://spec.matrix.org/v1.1/proposals/#lifetime-states
- The Matrix Spec is complex, so changes are carefully reviewed
- A bot handles the grunt work, but essentially a Final Comment Period is used after discussion is done, and the default action (disposition-merge, disposition-close, disposition-postpone) at the end of the period.
- I like this clarity of default-if-no-one-speaks-up
- The MSCs are also highlighted in This Week In Matrix, which we could copy
- Fedora uses a [Discourse Forum](https://discussion.fedoraproject.org/c/sigs/18) along with SIGs
- Rust uses an RFC repo too: https://github.com/rust-lang/rfcs
- I have asked for thoughts from other communities. more to come here

## Sync vs Async

There are procs/cons to both.

### Sync

Real-time chat is definitely better for innovation and clarity. The chance to debate and perhaps fix misconceptions before they take root is valuable. It's also more cohesive for community-building to talk with other contributors. This is probably most valuable to the person making the proposal, since they need to convince a certain quorum of people to back the change.

It's also faster than async, as decisions can be made (potentially) in real time. That's unusual though, it is more common for us to begin an issue one week and then move on to a vote the next week (or later). Time-critical issues do not arise often.

(Thought: where speed is required, does the steering committee have the power to get on with it? That would obviate the need to include speed as a requirement in the more general process. Need to define the committee's role in all this...)

However, it's quite exclusionary - specific timezones will always suck somewhere on the planet, and even when they don't other duties can block a person from attending.

It's also not good for those who like to consider carefully before responding. If the meeting is done in an hour and you've not finished thinking through the consequences, then you've been left out of the process.

Language barriers could be a part here too - if you're not a native-English speaker, keeping up with realtime chat is a barrier.

The logs are also harder to parse than a dedicated discussion forum, although our use of zodbot mitigates this to some degree.

Double all of the above for video calls (which we do not use now) - louder voices win, harder to follow for non-native speakers, not even any logs.

### Async

Pretty much the opposite - far better for inclusiveness, timezones, logs, language etc. Potential to have more automated workflows (tagging, promotion, etc).

Downside - slow. Slooooooooooow. Typically you'd want to allow at least a few "sessions" for comments before calling for a resolution. Needs a way to define "end" or "done", else things will drag on even more than now.

## Other interesting resources

For an anonymous non-profit I'm aware of:


I don't like the videoconference part, but the rest is interesting. The use of "notifications" suggests a persistent chat platform or forum.

# Mermaid code for the flowchart

flowchart TB
  X[START] ==> thoughts
  subgraph thoughts [initial thinking]
    direction TB
    A([Person has an idea]) .-> B
    B([Person discusses the idea in chat]) .->B .-> C
    C([Idea is worth proposing formally?])
  end
  thoughts ===> async
  subgraph async [async discussions]
    direction LR
    D(Issue created in repo) --> E(Async discussion on GitHub)
    E --> F(Discussion continues to resolve concerns) --> F --> G
    F --> J(Majority consensus, maybe 75%?)
  end  
    subgraph sync [optional sync chat]
      direction TB
      G(Discussion impasse) --> H
      H(Schedule realtime discussion between parties)
      H --> I1(Matrix chat) -->I
      H --> I2(Video chat) -->I
      I(Report back to GitHub as a comment) --> F
  end
  subgraph fcp [final comment period]
      direction TB
      K("Core" Team member moves issue to Final Comment Period)
      K --- K1(This is not the author)
      K --> L(Final date is set, 2 weeks default)
      L --> M(Default disposition is set based on consensus so far)
      M --> N(If no further discussion at the end date, disposition is used)
      M --> N1(If new discussion happens, continue process)
    end
    J --> fcp
    N --> Z[END]