Discussion for users, issues for devs

Tue, May 25, 2021 ❝Exploring the idea of having discussions among users for primary project communication, and issues managed by developers only.❞

Contents

This post is a write-up of the ideas that came to mind after reading “It doesn’t work” by Frank DENIS and comparing the circumstances of the present to past years. Most noticeably, and you undoubtedly have run into these discussions and blog posts yourself, the many discussions on whether IRC should disappear and/or how IRC is better/worse than other chat platforms. Or the way the old “forums” have all but disappeared to be replaced with issue trackers and other variants of discussion boards.

In summary, the blog post itself talks about how negatively-framed interaction is dominant on development platforms, due to the format in which it is offered. This is an important observation. You do not hear from the people that are perfectly happy, but that isn’t all there is to it. Such platforms are very much a platform for development, directed at developers. It is publicly accessible, but on careful observation you will find that most features are developer-oriented. This includes the “issues” that are managed, the pull requests that exist to accept prepared contributions to the project, etc.

There is a disconnect between the functions provided to project developers, and the functions needed by the project users. Notice how there is no real place to discuss things. To discuss, because no qualification is given yet. Something that is as-of-yet unclear needs triaging before we can determine whether it is something negative (bug, unsupported use case, improvement), or positive (working correctly) or neutral (question, clarification). In short, a community that is not centered around the developers, but instead is centered around the multiple, interacting users.

It has become common practice to use the issue tracker for asking questions or discussion. The same list of issues that is also the developer’s to-do list. Tags can be applied to distinguish between types, but in the end that does not cut it.

A few ideas that come to mind after some consideration:

1. Distinguish between users and developers.

   • Users will not always need a developer. They will need a platform for discussion.
   • The user will talk about their problem, which is not guaranteed to be a problem of the product, or a concern for a developer.
   • Users would want to see their problem solved, which may mean an improvement request, but sometimes a workaround is sufficient.

2. Issues as list of “work items”.

   • [managed] Managed by developers.
   • [development] By their very nature, require attention of developers.
   • [present/future] “closed” status means done and can be “forgotten”, whether the task is executed or rejected.
   • [clarified/triaged/primarily information] Content is (in-depth) analysis of a single topic.
   • [informed preference] Priority based on relevance/planning.
   • [correct/accurate] Their presence, count, metrics represent the state of the product accurately.

3. Discussions for interaction between users and as first point of interaction and support.
   Note that users can help each other out. Developers are mainly relevant if deep knowledge is required or changes are necessary.

   • [unclear/mixed] Not triaged, possibly mixed concerns, possibly user’s concerns irrelevant to the project, may indicate error of user or developer, still to be analyzed, anyone can add/contribute.
   • [past/present]There is no such thing as “closed”. The information may still be relevant to other users, may need to be closed to further discussion, due to content being outdated.
   • [past/present] Discussion mostly focused on released versions, as opposed to in-progress work.
   • [popular preference] Priority based on most recent activity, “hot” topic/most relevant matters/topics.
   • [primarily discussion] While not clear yet, user-to-user interaction can function as a way to flesh out various ideas for improvements, discuss various (mis)understandings of the application or a singular feature, or an inter-play of features. All before the developer needs to pay any attention.

4. Concerns, why should a development platform offer user-centric features such as discussion:

   • It is the primary location to look for support, i.e. it is where the project lives.
   • Offering the discussion format relieves the need to prematurely create issues: issues that are title-only, irrelevant, incorrect, poorly-written, duplicate, untriaged, etc.
   • It allows for easily transitioning from user discussion to developer support, from discussing to triaging to issue adoption, from help to documentation improvements.

5. Presumed benefits.
   There are some presumed benefits to recognizing the user’s need for a discussion platform.

   • Less curation necessary, therefore less attention from developers.
   • Written from perspective of user asking/enquiring (neutral), instead of reporting of the user’s problem perspective (negative).
   • Prioritize user interaction: discussion, instead of directed message to developers: requests, feedback.
   • Expect more discussion between users than user-to-developer.
   • Will require discussions to be able to branch out: multiple items/topics can come to light, multiple options may be discussed, thus diverging into multiple related concerns.
   • Issues need to be written separately, could refer to discussion branch for context.

Given a development platform and (personal) communication to individual developers, the platform, which is dedicated to the project, is the most reasonable choice. However, it can be a very poor option, not well-suited for questions or impartial discussion.