Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MDN Community: Discussion guidelines #32620

Merged
merged 15 commits into from
Mar 25, 2024
Merged
8 changes: 5 additions & 3 deletions files/en-us/mdn/community/discussions/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,9 +12,11 @@ On MDN Web Docs, we encourage our community to start and/or engage in discussion
If you see something wrong on MDN Web Docs, it's best to open a GitHub issue in the [relevant MDN GitHub repository](https://github.com/mdn/).
If you're not sure whether to open an issue or start discussion, consider the following guidelines:

- Issues are for reporting a bug or a work item with clearly defined and actionable tasks and outcomes.
- Discussions are the right place if an issue needs a discussion to agree upon a course of action or define an actionable piece of work.
heck out the subject of each discussion category below so that you can start your discussion in the proper place.
- Issues should be used for reporting a bug or a work item with clearly defined and actionable tasks and outcomes.
- Use Discussions when an issue requires a dialogue to agree upon a course of action or define an actionable piece of work.
- If your discussion doesn't progress or you're unsure of the next steps, refer to the [Guidelines for managing and resolving discussions](/en-US/docs/MDN/Community/Discussions/Managing_and_resolving_discussions) for advice on moving forward, including expectations on timelines.

Check out the subject of each discussion category below so that you can start your discussion in the proper place.

<table>
<thead>
Expand Down
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general I think we're describing an RFC process which might be good to compare:

Astro’s RFC process is forked from the Vue RFC process which itself owes inspiration to the React RFC process, Rust RFC process and Ember RFC process.

Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
---
title: Managing and resolving discussions
slug: MDN/Community/Discussions/Managing_and_resolving_discussions
page-type: mdn-community-guide
---

{{MDNSidebar}}

The MDN community is encouraged to [initiate, engage in, and resolve discussions](/en-US/docs/MDN/Community/Discussions) related to the MDN Web Docs documentation.

While most discussions reach a broad agreement quickly, some may stall due to an unclear path to a resolution, often because of differing opinions. This document outlines the process and strategies to move discussions toward a resolution within a reasonable timeframe (we'll define what's an acceptable timeline later in this document).
estelle marked this conversation as resolved.
Show resolved Hide resolved

## Moving a discussion to a resolution

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:

1. Each discussion is held / rooted in a [discussion on Github](https://github.com/orgs/mdn/discussions), which is the "source of truth" for the topic.
dipikabh marked this conversation as resolved.
Show resolved Hide resolved

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

- Guiding the conversation.
- Making people aware 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, tagging people on GitHub, and other channels if appropriate - of needed feedback by specific dates.
- Bring up the topic in community and weekly meetings.
- Organizing a synchronous, online face-to-face meeting if required (if there is disagreement). Face-to-face meetings should be rare and only if required (See #3).
- Summarizing face-to-face conclusions in the relevant discussion on [Discussions](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.
dipikabh marked this conversation as resolved.
Show resolved Hide resolved

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

- Face-to-face meetings must be announced in all relevant [communication channels](/en-US/docs/MDN/Community/Communication_channels), such as Slack, Discord, GitHub discussion, etc.
- Conclusions of each face-to-face meeting must be entered into the GitHub discussion, which remains as the source of truth for the discussion.
- The driver is responsible for calling the meeting, informing all parties, reporting results back into the GitHub discussion.

Once agreement has been achieved, the discussion can be closed, the resolution announced, and the plan for implementing the resolution can be put it into action!
dipikabh marked this conversation as resolved.
Show resolved Hide resolved

## Expected turnaround times for discussions
dipikabh marked this conversation as resolved.
Show resolved Hide resolved

Every discussion will have a different timeline depending on the complexity of the topic and the consensus levels. Ideally, most discussions should be resolved within two months, allowing for the topic to be addressed at various internal meetings. This timeframe ensures diverse viewpoints are considered and everyone interested has the opportunity to contribute to the discussion.

1. Post the discussion and assign a driver.
2. Identify any key stakeholders and needed approvers (the individuals who need to weigh in on the topic and give their approval), if any.
Copy link
Contributor

@dipikabh dipikabh Mar 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry if I'm being pedantic. If I look at the timeline of a discussion as an example: someone opens a discussion, it receives a lot of opinions and ideas and responses, and this happens over say 4 weeks. But then the conversation dies without reaching a conclusion. It's then I would regard the discussion as stalled (for example, https://github.com/orgs/mdn/discussions/426. This one has not reached a conclusion even after async/meeting discussions)

Q - Do we need to define the time or the state when to consider a discussion stalled?

  • If we're focusing only on stalled discussions in this document (which means "Post the discussion" has already happened), when should the drivers and stakeholders be assigned? Are we doing steps 1 and 2 for all discussions or only for stalled discussions? If this is applicable only for stalled, we could add another sentence as a lead-in for the steps (but would that be time-based or the author taking a call that the discussion is in limbo)?

  • From the current wording, it seems that these steps are more to ensure that no discussion is stalled, that is, from the beginning every discussion is assigned a driver and approver and brought up in meetings so that it gets resolved within two months.

  • I am not clear about "driver". How does a community person pick a driver? Echoing @hamishwillee's question here: "How does the driver get picked"? Or does someone invested in the topic assume that role? Similarly, would the community folk know who "key stakeholders and needed approvers" are?

Suggested change
Every discussion will have a different timeline depending on the complexity of the topic and the consensus levels. Ideally, most discussions should be resolved within two months, allowing for the topic to be addressed at various internal meetings. This timeframe ensures diverse viewpoints are considered and everyone interested has the opportunity to contribute to the discussion.
1. Post the discussion and assign a driver.
2. Identify any key stakeholders and needed approvers (the individuals who need to weigh in on the topic and give their approval), if any.
Every discussion has a different timeline depending on the complexity of the topic and the consensus levels. Ideally, most discussions should be resolved within two months, allowing for the topic to be addressed at various internal meetings. This timeframe ensures diverse viewpoints are considered and everyone interested has the opportunity to contribute to the discussion. If your discussion has not reached a conclusion within two months, consider performing some of the following steps:
1. Determine a driver for the discussion topic if it's not the same as the author.
2. Identify any key stakeholders and needed approvers (individuals who need to weigh in on the topic and give their approval), if any.

3. Inform the approvers and other essential voices of the discussion and your proposed timeline. If needed, reach out to them again after 2 weeks, and weekly thereafter, until they provide feedback.
4. Add the discussion topic to the agendas of relevant meetings.
5. After a month, sort through the feedback, discussions, and agreements, and formalate an initial plan merging the feedback into a possible action plan. Re-inform and re-request feedback from all interested parties, including everyone who participated in the discussion in any way.
6. During the second month, keeping reaching out the the community for feedback on the proposed plan, making updates to the plan in light of any new feedback. Rinse. Repeat.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"reaching out to the community" - this assumes that the discussion is initiated by a maintainer?

Suggested change
5. After a month, sort through the feedback, discussions, and agreements, and formalate an initial plan merging the feedback into a possible action plan. Re-inform and re-request feedback from all interested parties, including everyone who participated in the discussion in any way.
6. During the second month, keeping reaching out the the community for feedback on the proposed plan, making updates to the plan in light of any new feedback. Rinse. Repeat.
5. After a month, sort through the feedback, discussions, and agreements, and formulate an initial plan merging the feedback into a possible action plan. Re-inform and re-request feedback from all interested parties, including everyone who participated in the discussion in any way.
6. During the second month, keeping reaching out to the community for feedback on the proposed plan, making updates to the plan in light of any new feedback. Rinse. Repeat.

7. If there are points of contention, arrange an online, synchronous, face-to-face meeting to resolve any remaining disagreements (as captured in the discussion thread).
8. Keep the discussion threads alive during the second month as you work with the community towards the resolution.
9. [Create an issue](/en-US/docs/MDN/Community/Issues) with the final plan for implementing the resolution and put it into action.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

10. Close the discussion.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should also mention that not all discussions will reach a conclusion. Maybe the action/fix required is part of a future year's roadmap. Maybe after two months, the conclusion reached is "can't happen now".


If the discussion involves reaching out to and receiving feedback from experts, the timeline above can be extended as needed.
Loading