Scope of discussions

[mbwhite]

Hello:

Just spotted the discussions feature is enabled - not that this is a bad thing - but what's the scope of this discussion channel, vs Rocket Chat/Mailing List/JIRA/StackOverflow

(I know there was discussion of RocketChat moving to Matrix?)

This may have been mentioned on a community call for which I apologise, but I've not be able to attend for scheduling reasons recently.

Thanks Matthew

[lindluni]

Great question! And one I think needs answered, I'd like to give my take on this.

When I originally discussed with Dave his thoughts on migrating from Azure Pipelines to GitHub Actions, we discussed how to best communicate this. One of the things that bothered me was the last time we migrated CI platforms (though it was more invasive) Matt Sykes and I spent 9 months in calls, mailing lists, RocketChat, private emails, presenting to the TSC and on Community Calls making decisions with Hyperledger and the CI Working Group. So much of that decision process and the thinking behind it has been lost to history.

At the time (a month or so ago), I mentioned that there was a new Discussions feature that we could use to communicate it and solicit feedback, but more importantly create something for the record that lives near the code. The problem with the mailing list is that it serves as a technical dumping ground for community generated issues and decisions quickly become lost in it. I suggested we try out using a discussion for CI and see how it goes, we communicate the discussion on CI to the mailing list and see how it goes, and then we could see if we felt it was something we wanted to keep around.

My thoughts on what we can use discussions for, aren't to replace Stack Overflow (which I see a few posts in here modeling), but instead to provide a forum for discussing technical features that don't require something as robust as the RFC process, so discussions can serve as a history of the decision process for less invasive changes, or things that just don't fit the RFC process.

To prevent us having to curate it like we do for Jira's, my thoughts were we create a pinned post for what discussions are and the expectations, and then we can create a GitHub action that automatically comments on new discussions with the guidelines (essentially this is not RocketChat or StackOverflow). We can then use some form of automation, like the CNCF projects use to manage CI, such as a maintainer commenting /accept one time, and once a day/week an Action goes through and flags posts to the maintainers by commenting something like @hyperledger/fabric-core-maintainers, it has been 7 days since this discussion was started if you want to maintain it, please comment /accept in the next 7 days for posts that are older than say 7 days, and haven't yet been marked /accept and then say after 30 days they are automatically locked, and then after 90 days if they are both locked and not /accept automation removes them.

I'll be blunt about my reasoning for all of this, in the last month, I've tried making contact with several Fabric maintainers in public forums and they've been unsuccessful. I can personally say that since Fabric is no longer part of my day-to-day job, I frequently forget to login to RocketChat, and the chat format is not conducive to preserving history. I view this as a way to get technical discussions closer to the developers and easier to search and curate.

Just my thought, I know other will have their own opinions.

[denyeart]

The best discussion forum among maintainers and contributors is the one that people will actually use.

• There has clearly been a shift away from RocketChat (and chat in general, even if Rocket is replaced). For good reason I think - an ever-growing stream of consciousness never seemed like a good idea for important discussions.
• The mailing list is dominated by user questions.
• I think some maintainers/contributors are hesitant to engage in a space dominated by users.

I see two options:

1. Create a second mailing list for Fabric developers, while keeping the current mailing list for Fabric users.
2. Use GitHub discussions

My preference would be GitHub discussions for the following reasons:

• Integrated with GitHub, where most of us work anyways. Ability to convert Issues to Discussions, etc
• Since it is GitHub, it is more likely to be developer focused than user focused, which potentially encourages maintainers/developers to engage more and speak more freely.
• Discussions can be categorized, moderated, marked as answered, etc, potentially solving the issue of the noise drowning out the important discussions.
• GitHub is actively investing in this area and is becoming the de facto place for open source communities.
• Markdown support
• Plus everything Brett said

The use of GitHub Actions and GitHub Issues are separate but related questions. Related in that if we shift everything to GitHub, it will be THE place for maintainers/developers to congregate and we may get more engagement with everything under one roof (the whole is greater than the sum of the parts).

[yacovm]

* Integrated with GitHub, where most of us work anyways. Ability to convert Issues to Discussions, etc

But we are currently tracking issues with JIRA.
I don't see how we can migrate from JIRA unless there is a way to export it and import it into github issues.
There are tons of technical discussions about past decisions, design and planning in JIRA and if we lose that then we essentially forget our past, and a project that forgets its past, has no future. At worst, we need a way to archive JIRA if we are to move away from it.

[lindluni]

This is another thread we need to visit soon, currently we use a version (self-serve on-prem) of Jira that has been sunset, early next year we have to migrate either to Jira Cloud, GitHub Issues, or some other platform. Migrating to Jira Cloud is going to kill all of our links that are floating around on the web anyway, as we can't use our custom domain on Jira Cloud, so the URL format is different.

So the question is a migration: Jira has an API that allows us to pull all of the data, and I've experimented with migrating it into GitHub, capturing components, labels, and chat history. In an effort to preserve who made the post the authors ID (and name if we choose) is attached to the start of each message. You can see an example here of a doc Jira Pam opened that I exported and reimported into GitHub with the issue title being the FAB number and the original "summary": https://github.com/lindluni/fabric/issues/132. Simply extending the crawler to add individual comments as well is easy enough. Obviously we can debate formatting and whatnot, but you get the idea.

But the net-net of it is, all of our existing links are dead in the next year anyway.

[C0rWin]

Given that Jira will be sunset, I think it makes sense to migrate into Github issues, as pointed out by @lindluni. The links are going to be eventually broken anyway. But I see a lot of value in cohesively managing code, issues, pull-requests, and discussions in one place.

[mbwhite]

Agree with @C0rWin; if we need to move away from jira, and the replacement Jira offering has a different URL format... a move to Github issues would be positive.

[bestbeforetoday]

GitHub issues would also be my preference. Since all the code and PRs etc. are there, I would find it easier.

And I think @lindluni volunteered to automate the migration for all the repositories. 😉

[jyellick]

I'll be the first to criticize our existing suite of communications infrastructure, and moving to a system closer to the code, with better support for code formatting, labeling, etc. seems like a good thing. But what I'd be very wary of is simply adding 1 more place to check. If we want to use github discussions, let's ensure that we're sunsetting usage of something else -- Rocketchat seems like an obvious choice -- though given its nature, github discussions seems much more analogous to mailing list communication than to realtime chat.

[lindluni]

And hopefully Matrix serves us better than RocketChat ever did, it looks promising, but really anything is better than RC in my opinion.

[mastersingh24]

Ever since I learned about GH discussions, I've been wondering if we should at least try it out. I'm not saying it will solve all problems, but having discussion closer to the code itself seems like a good thing to me. I'd suggest we also take a look at big-name projects which are using them and see how they organize things as well.

I gave up on RC because it's just does not scale well. Mailing list and SO are great for answering user questions. Some do go unanswered, but at least you can search through and see the questions whereas with all of the RC channels and DMs questions just go into a blackhole.

[C0rWin]

I think it can be nice if Github will have something equivalent (cough cough @lindluni ).

In fact, there is something very similar you can achieve with gitter.im, you can integrate chat room with Github project.

[lindluni]

Ever since I learned about GH discussions, I've been wondering if we should at least try it out. I'm not saying it will solve all problems, but having discussion closer to the code itself seems like a good thing to me. I'd suggest we also take a look at big-name projects which are using them and see how they organize things as well.

I gave up on RC because it's just does not scale well. Mailing list and SO are great for answering user questions. Some do go unanswered, but at least you can search through and see the questions whereas with all of the RC channels and DMs questions just go into a blackhole.

There is a "What is Discussions" here which also includes a highlight of some projects currently using discussions: https://docs.github.com/en/discussions

The Node.js project pins this message as their "What is the purpose of Discussions": nodejs/node#35662

There are even more features for Discussions in the pipeline, such as tags, and custom categories coming as well that would make some automation for curating discussions easier from a maintainer PoV.

[guoger]

I do like the idea of pushing things closer to the code (discussion, issue tracking), although I'm not sure it could completely replace realtime chat platform, which IMO is still needed.