Support natural flow of discussion (Phases)

async-go / asyncgo

AsyncGo is a collaboration app designed around async/remote team communication.

https://asyncgo.com

MIT License

11 stars 0 forks source link

Support natural flow of discussion (Phases) #210

Closed jyavorska closed 2 years ago

jyavorska commented 3 years ago

Problem to solve

More complicated discussions tend to have a flow: "first start with intent - do we all agree - then start with brainstorming - do we all agree - then a proposal and feedback suggestions - then a final decision - do we all agree". We don't model this at all in the discussions today.

Proposal

Add some kind of state to the discussion to ensure nobody is jumping ahead, and time is being given to the initial phases of the discussion.

Other details

Some ideas at https://get.almanac.io/changelog/structured-approvals

Permissions and Security

N/A

Documentation

N/A

Links / references

N/A

jyavorska commented 3 years ago

@matteeyah do you agree that an MVC of this can be:

New field called State
State can be one of three states (context setting/alignment on goal, proposal alignment/discussion, implementation)
It is toggleable somewhere around where you set due date
Not setting a state is fine
It doesn't actually do anything other than record the state
It's visible from the topic index

We can use Kenny's ideas for how to describe each state:

Create an issue with a proposal, framing and background.
Discuss whether it is important, if the background and framing are accurate.
THEN we discuss the proposal and get agreement on it
THEN we implement it together

If so I think I can probably do it. If not I'd love to hear your ideas.

matteeyah commented 3 years ago

The MVC sounds fine. Our state could be something that's functionally similar to GitLab's issue health status.

As for the next steps, I'm not 100% sure if we should limit editing specific fields based on the state. It forces the process to be waterflow-y, while in reality most modern teams go back and forth and do things in parallel.

jyavorska commented 3 years ago

I had an even simpler idea @matteeyah that I think is better and easier. What if instead of defining phases, any heading (i.e., ###) in the markdown could be indicated as the current "phase". Or, you could just have none marked in that way. This would give you complete control to focus everyone's attention, it would be integrated dynamically with each topic's custom headings.

Thoughts?

matteeyah commented 3 years ago

That's an interesting idea, but sounds somewhat complex to implement.

It might also be hard for new users to pick this up since it's not standard. We should keep our markdown spec as close as possible to the standard spec to avoid going into a situation where our users don't know how to use the product instinctively, but have to invest time into learning it as a tool
We shouldn't build anything on top of our markdown pipeline until we decide if we want to completely get rid of markdown input in favor of a WYSIWYG with proprietary output format

Another alternative to defining phases as a standalone feature is to implement them through tags / labels

Implement tags or labels
Implement scoped labels
Have a scoped tag / label define the phase

The more I think about this, the more I think we should implement phases as part of some other functionality instead of a standalone toggle / feature.

jyavorska commented 3 years ago

I thought about it slightly differently @matteeyah. Something simple like:

Every topic has a free text field called phase
Whenever a description is saved, all the headers are saved in an array in the topic called phases
In the app, you can enter whatever you like in the phase field, or, from a dropdown you can choose one of the current phases to fill it out for you.
There isn't any data relationship between markdown and phases. If the markdown is edited to remove a phase, the phases array is updated but the current value of phase is left alone

A simpler version of this is just a text field that lets you type whatever you want in the phase box, with no magic header dropdown.

A slightly more complicated version does some kind of matching (/\# #{phase}/) to highlight the heading in the description.

matteeyah commented 3 years ago

Ooh, I like this. It's definitely simpler and more flexible than the label approach. I guess we need to figure out if we want to make phases more or less structured 🤔

jyavorska commented 3 years ago

@matteeyah I had the idea while creating templates. It could make them all magically appear if you copy/paste a template. I.e.: https://asyncgo.com/docs/templates#integrative-decision-making-holacracy. Templates would come with their phases "for free"