-
Notifications
You must be signed in to change notification settings - Fork 22.4k
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
Conversation
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
9. [Create an issue](/en-US/docs/MDN/Community/Issues) with the final plan for implementing the resolution and put it into action. | ||
10. Close the discussion. | ||
|
||
If the discussion involves reaching out to and receiving feedback from experts, the timeline above can be extended as needed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be nice to add a checklist section at the end that a discussion owner can copy/paste in and then checkoff as each step is complete.
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
|
||
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. | ||
|
||
2. Each topic of discussion needs a driver. The driver is responsible for: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer the term owner to driver.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i prefer the term too, but the driver may not be the owner. The person driving the discussion (the driver) to a resolution may not be the same person who opened the discussion (the owner).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When a discussion is initiated by maintainers, is it okay to go with the assumption that the author is the driver? How will community determine a driver? Also, the question of selecting a driver would arise only if a discussion hasn't progressed.
In the timeline section, we need to define the period of inactivity or non-resolution beyond which a discussion can be considered as stalled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is why this was originally called "resolving". Discussions only need drivers, guidelines, and timelines if they need help being resolved. This is expressed in the intro.
Generally, the initiator may be the driver, but sometimes people start discussions but aren't invested in the outcome, while someone else may be more passionate about it. I want to provide guidelines open to interpretation, not rules... but someone might be more vested than me in this discussion ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The person driving the discussion (the driver) to a resolution may not be the same person who opened the discussion (the owner).
The person who cares is the owner, whoever posted it :-). The author is likely to be the owner.
But that's just semantics. The point here is that it is possible to look at this text and say "you mean the owner, or the author right". So perhaps a definition is needed.
How does the driver get picked - it's obvious who the author is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The driver will generally be the author and owner, but doesn't have to be. Defining it to that person limits it. Leaving it undefined allows for anyone with the energy to move the discussion forward to take on that responsibility.
I guess we could just write what I just said if required.
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
THanks @estelle . I'm fine with the broad picture, but the discussion thread doesn't tell me if the result of the community call. I'll add some more reviewers.
Co-authored-by: Hamish Willee <[email protected]>
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
…dex.md Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Brian Thomas Smith <[email protected]> Co-authored-by: Vadim Makeev <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving a few thoughts and plenty of questions
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
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. | ||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll not know beforehand the discussions that will get stalled. Do these steps need to be done for every discussion opened? Folks in the community will not know who the drivers, stakeholders, and approvers are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the intro explains when this guide, and therefore these steps , are relevant
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
|
||
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. | ||
|
||
2. Each topic of discussion needs a driver. The driver is responsible for: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When a discussion is initiated by maintainers, is it okay to go with the assumption that the author is the driver? How will community determine a driver? Also, the question of selecting a driver would arise only if a discussion hasn't progressed.
In the timeline section, we need to define the period of inactivity or non-resolution beyond which a discussion can be considered as stalled.
files/en-us/mdn/community/discussions/Resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Dipika Bhattacharya <[email protected]>
Preview URLs
Flaws (1)Note! 1 document with no flaws that don't need to be listed. 🎉 URL:
External URLs (1)URL:
(comment last updated: 2024-03-25 21:09:46) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm marking as approved because I see this as advice for people with a stalled discussion that they really want to progress. There are very few cases where I see a discussion actually needs to be resolved, but if someone cares enough then this will be helpful.
What's missing for me in the whole picture around discussions is triage - looking at the discussions and deciding whether their resolution would actually make a real difference vs the cost of chasing it up. But that's a job for community management to evaluate. This is a helpful guideline on possible approaches to move things forward.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarifications, @estelle. I've relooked at the page from the perspective of targeting only stalled discussions.
files/en-us/mdn/community/discussions/managing_and_resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
files/en-us/mdn/community/discussions/managing_and_resolving_discussions/index.md
Outdated
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. |
There was a problem hiding this comment.
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?
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. |
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. |
There was a problem hiding this comment.
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?
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. |
9. [Create an issue](/en-US/docs/MDN/Community/Issues) with the final plan for implementing the resolution and put it into action. | ||
10. Close the discussion. |
There was a problem hiding this comment.
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".
files/en-us/mdn/community/discussions/managing_and_resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
files/en-us/mdn/community/discussions/managing_and_resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
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. | ||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about linking this to https://developer.mozilla.org/en-US/docs/MDN/Community/Issues#guidelines_for_reporting_an_issue?
files/en-us/mdn/community/discussions/managing_and_resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
…iscussions/index.md Co-authored-by: Dipika Bhattacharya <[email protected]>
This is for all discussions (where a resolution is wanted); to prevent them from getting stalled. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, @estelle, for putting these guidelines/doc together. Appreciate your patience in addressing my comments and questions.
files/en-us/mdn/community/discussions/managing_and_resolving_discussions/index.md
Outdated
Show resolved
Hide resolved
…iscussions/index.md Co-authored-by: Dipika Bhattacharya <[email protected]>
Nicely done |
Based on this discussion: https://github.com/orgs/mdn/discussions/634