A new RFC discussion model

Problems with our current model

  • The current discussion model prioritises volume and frequency. People think that their feedback will be lost if they don’t repeat themselves or receive a direct response.
  • The current model does not provide enough context for people to feel that they are informed on the discussion. Summary comments are quickly lost in the discussion.
  • Author’s have no way to handle feedback in an efficient manner, and the response to feedback is not visible enough to prevent duplicate feedback.
  • Discussion is directionless. Comments ordered by time, there’s no way to group a discussion around a single topic. As a result people tend to write “My 2¢” and group their feedback around themselves. These posts are quite detrimental to the discussion as it encourages authors spend their time giving feedback to a specific participant  and not responding to larger discussion of the individual topics in those posts.

What discussion model do we want?

  • A priority placed on direct feedback over general commentary.
  • Feedback that can be easily managed at higher volumes, for both authors and readers.
  • That allows for new participants to join, while reducing duplication.
  • That provides complete history of the discussion.

Proposed Solution to this model

  • Instead of writing a comment on the thread, a participant will ask a question. Where a comment previously was a flat block of markdown, a question is split between the header, body, and feedback sections.
  • A header can either be a “Summary” header which is a character limited (e.g. twitter) summary of their question, or a “Quote” header which is a quote from the RFC. A question must have a header.
  • This change encourages participant’s to provide much more directed feedback.
  • The body would be the same as GitHub’s comments is today. A body is optional when you have a summary header.
  • Each question has a feedback section, allowing other participants to reply to a specific question.
  • Questions can be categorised (e.g. #syntax, #nll), this allows for questions to be easily filtered into their respective topics. Allowing people to easily see their specific area of interest.
  • A question can be resolved. The author, asking participant, or moderators can resolve a question and provide a comment as their decision on the topic. When a question is resolved the rest of the comment section is elided so that people see just the question and the decision, while being able to expand the comments in order to see the full context.
  • This moves how we think about feedback more closely to how we think about GitHub issues, where there is a much more clearer start, middle, and end, and we can handle duplicate or similar feedback in the same way we handle duplicate or similar issues.
  • A participant will have access to more fine grained notification controls, and better defaults. Commenting on a question will by default only give you notifications for the question itself. People will be able to see and process comments about their areas of interest of a topic without being overwhelmed by the surrounding discussion.
  • Moderators will be able to highlight questions which will appear before other questions.
  • Having questions be highlight-able allows the moderators to showcase and encourage good discussion in the community.
  • Highlighting provides a way to show questions that are important to understanding the context of the current RFC status. 
  • Highlighted questions provides a better entry point for people who are new to the discussion and/or Rust itself, and lower the barrier of entry to participate.