Discussions and resolutions

[estelle]

The is a meta discussion for the topic of "how to have discussions".
The goal of this discussion is to agree on how we address "discussions" and add the process to MDN writing guidelines at https://developer.mozilla.org/en-US/docs/MDN/Community/Discussions.

Proposal:

1. Each discussion is held / rooted in a https://github.com/orgs/mdn/discussions, which is the “source of truth” for the topic.

2. Each topic of discussion needs a driver. The driver is responsible for:

• Guiding the conversation
• Making people aware that the discussion exists
• Setting the timeline, informing people of it, changing the timeline as necessary, and sticking to the timeline as appropriate
• Informing all the appropriate channels - slack, discord, and other channels if appropriate - of needed feedback by specific dates
• Organizing face-to-face if required (if there is disagreement). Face-to-face meetings should be rare and only if required.
• Summarizing face-to-face conclusions in the /discussion/ on https://github.com/orgs/mdn/discussions
• Guiding the implementation of the discussion results or working with the appropriate team lead to ensure that the results are implemented.

3. Face-to-face meetings regarding a discussion should only be called if there is disagreement.

• The f-2-f must be announced in all communication channels (slack, discord, /discussions/)
• Conclusions of the f-2-f must be entered into the /discussion, which remains as the source of truth for the topic
• Driver is responsible for calling the meeting, informing all parties, reporting results back into the /discussion

Edit: This was copied into a Google Doc. Edits are welcome there.

[OnkarRuikar]

Setting the timeline, informing people of it, changing the timeline as necessary, and sticking to the timeline as appropriate

Can we set duration to not more than two months? We can negotiate conclusions in MDN community calls twice in this period.

It'll speed up the process if Mozilla team discusses the topics in their internal calls and OWD in their weekly calls. And unified views on both sides can be presented in community calls or in GitHub comments.

[chrisdavidmills]

@OnkarRuikar touches on something important here — the discussion guidelines should include a template for a typical discussion timeline/process that all discussions should stick to, unless there is a really good reason why not.

For example:

1. Post discussion, assign driver and approvers/essential voices (folks who we need to weigh in on the topic and give their approval, or whatever). Ask the approvers/essential voices for their input.
2. After 2 weeks, ping the approvers for their input, if they have not already given it. Do this again after 3 weeks if needed.
3. After one month, make sure all the feedback is sorted through, discussions had, and agreements made. Make updates to the plan in light of these. Arrange a face to face to discuss anything that we can't seem to get agreement on in the discussion thread.
4. Keep any remaining discussion threads alive as you work towards the final conclusion.
5. After two at the latest, close the discussion and announce the resolution. Write a plan for implementing the resolution and put it into action.

Or something like that.

[Rumyra]

Thanks for starting this convo @estelle - we've been discussing a very similar thing - 'what is the process for specific proposal discussions when they get to a descision', which maybe wasn't very clear when we initiated discussions. I've had a few initial thoughts and we've already decided to put it on the agenda for the next community call. (None of these conflict with your suggestions btw just noting for the record)

• We should keep the process inclusive for all contributors (not just core & partners)
• Not all discussions need this process, in fact most of them are questions/feedback etc - I think it's quite easy to define which ones do, but worth a note
• We already have a proposal process and whilst not all of these types of dicsussions will end with a proposal, we should build upon that
• It's hard for all folks to keep on top of all discussions (I've been trying to triage since NY and I've got through the first two pages) we maybe gravitate to those we have opinions about, but that doesn't mean we don't care about the conclusion
• (Unrelated) There is a Yoshi hair in my tea this morning 🐶 🍵

[estelle]

I added a Google Doc where interested parties can contribute directly to the MDN discussion guidelines

I included the following intro (feel free to edit in the doc as well):

If you are proposing new content or features, please open a new issue. If you are suggesting changes to processes or other changes that would benefit from or need input from our partners and the wider community, please start a discussion..
Most discussions do not need a formal resolution process. These MDN discussion guidelines are here for the discussions that aren’t moving forward toward a conclusion or would otherwise benefit from a formal process:

[chrisdavidmills]

I think the proposal so far is really good; my two main feedback points are:

• Include a timeline template that people can follow to action a discussion (see above my response to Onkar's comment)
• https://developer.mozilla.org/en-US/docs/MDN/Community/Issues/Content_suggestions_feature_proposals already includes a section on participating in a discussion when a new feature is proposed. I'm thinking you should also update this page to point to the other guideline page on discussions, and make it clear when a discussion might be needed (e.g. say something about changes to processes as well, an make it clear that new features might also warrant a discussion)

[estelle]

1. A suggested timeline is good, likely with a "range" for every step in the process as internal discussions are expected to be much quicker than ones requiring feedback from external experts not active in the MDN community.

2. I always link back ;) that page is linked in the intro i added, and i would link the start a discussion to this new page. (or, this "page" may end up living within the content_suggestions_feature_proposals page.

[estelle]

Hi everyone. Please take a look at the google doc. Please provide feedback.

Any objections to merging this into the MDN guidelines?

[estelle]

PR to add this to the MDN guidelines: mdn/content#32620

[hamishwillee]

@OnkarRuikar @chrisdavidmills @Rumyra I have looked at the PR posted by @estelle . It seems broadly as discussed, but I didn't go to the community call, so I don't know the resolution of any discussions there. Can you please also confirm you are happy with the amended docs.