Trying out GitHub Discussions

[cbeams]

@bisq-network/dao, I've enabled the new (beta) GitHub Discussions feature here in the main Bisq repository to experiment with it and see if we'd like to use it. This is the first such discussion—please feel free to respond to it.

Note that this feature is different than GitHub's existing Team Discussions feature. We've tried with mixed success to use them, but for the most part they haven't worked very well. The team-based structure makes things too complicated and it's impossible to make discussions truly public. In the end, it just hasn't caught on.

I think this new Discussions feature could be a better fit, especially as a place to more casually discuss ideas around the project. I believe we currently over-use the proposals repository for this purpose. With Discussions, we can more comfortably share ideas and get a sense about whether a more formal proposal is even worth putting together. I hope this can save some time and generally increase engagement.

Have a look at BTCPay Server's repository for an example of what well-managed Discussions can look like: https://github.com/btcpayserver/btcpayserver/discussions.

Relationship to the existing forum at https://bisq.community. I would expect the forum to stay as-is for now, continuing to serve primarily as an end-user support resource. The Discussions here in GitHub would, at least to begin with, be more focused on development, new feature ideas, and so on.

Relationship to existing Compensation Request announcements. One place where we've been successfully using the older Team Discussions feature is for Compensation Request announcements, e.g. this one announcing Cycle 21. I would expect that process to stay the same for now, and I would leave it to the @bisq-network/compensation-maintainers to propose any changes if they'd prefer to use these this new Discussions feature for that purpose instead.

Regarding notifications. I mentioned @bisq-network/dao above to make sure that active contributors will see this discussion, but in general, you'll get notified about discussions the same way you get notified about issues and pull requests. As far as I can tell, Discussion notifications conform to your "Watch" settings on this repository. So maybe double-check those settings to be sure you're happy with them.

I'll leave it there for now. Have a look around and feel free to experiment. Please react, respond to and/or upvote this discussion and let's see if this feature is a good fit for Bisq. Thanks!

[m52go]

I like that they're public by default. The other discussions are limited to those who are signed in to GitHub and part of the Bisq GitHub organization, which limit their overall usefulness.

[Conza88]

Nice. Issues gets over-used possibly as well, and proposals less used than it should be I suspect.

[cbeams]

Issues gets over-used possibly as well

Note that issues can be converted to discussions where this is the case.

[Conza88]

Right. Doesn't look like I can edit my own and convert, only others 'maintainer' can etc.

[pazza83]

Here is a link to the new discussions area https://github.com/bisq-network/bisq/discussions

[Conza88]

Would be good if they 'counted' the discussions being had, like they show for issues and pulls (little grey icon)

EDIT: submitted feedback to this effect.

[wiz]

Cool, seems like this could replace the Bisq forums, but how is the moderation I wonder?

[chimp1984]

I think the feature is getting used already and seems to have been accepted by the contributors.
I am wondering if there is a tool / way to limit noise. A general problem not only at Bisq is that too much content gets produced and it becomes difficult to find the valuable out of the noise, and of course everyone will have a different opinion about that. Twitter does it well with making each user his own "censor"/filter by following those who have built up reputation from the users perspective.
I never really used the "Follow" feature in Github and I assume that is not the right solution here.

One option could be that we use a moderator who closes discussions when they reach a certain number of down-votes from contributors who have earned some reputation. We could use the DAO merits but that is not accessible here, but I think the moderator would know which contributors are around the project since long and have earned some considerable amount of BSQ by adding value to Bisq. Is not a perfect solution and makes the moderator a problematic role, but Github is not decentralized anyway, mergeing code is also based on similar reputation based authority. But it would help to keep the Discussions panel clean and new potential contributors don't get lost in noise and get a bad impression of low-quality input/discussions.
I see this a real problem in all our channels. GH issues are a mess, proposals are better but still too polluted and I think the same will happen here. Maybe we can make it a time-limited experiment to choose one moderator who is responsible to keep the panel clean. I would avoid to define too much formal rules here, as those can always be circumverted and do not serve as quality filter (see past projects, where some followed the formal requirements but content was pretty poor and has shown lack of understanding of how Bisq works). I think a reputation based approach is more effective.
Just my 5 cents, not 100% clear idea how to get the solved best...

[MwithM]

Another concern I have is the centralized nature of Github. I think Bisq depends too much on it.

[cd2357]

Trying to open a feature request in GH (Bisq repo > Create issue > Feature Request) takes the user to the Discussions section.

Not a big fan of this, because we lose the ability to track an issue (as in, moving from an idea to Done). This includes labels, ability to categorize by section (GUI, API, network, etc), ability to point new devs to "good first issues", and so on.

@bisq-network/admin please change this back, let the GH > new issue > feature requests button create a normal GH issue.

[cbeams]

Looks like this change was made by @huey735 and merged by @ripcurlx in #5348. Agree it should probably be a more simple distinction between Issues and Discussions. Moving all feature requests to Discussions is probably a step too far for the reasons stated above.

@huey735 could you follow up with a proposed revision to the template that takes these concerns into account?

[huey735]

The sentiment I got from devs was that it made sense to move the feature request to Discussions.
@ripcurlx @chimp1984 @sqrrm @jmacxx what do you think?

[ripcurlx]

I think the idea was that it seems like GitHub discussion is a more vivid space to discuss new ideas before they are added as an issue to the repository. It is true that it looks like as only Bug reports should be added to GitHub issues right now. I don't have a strong opinion about this, but maybe we should link the feature request to a feature template in the repository issues again and only leave the community support chat external link.