Bidirectional sync between Discourse Topics/Categories and GitHub/Gitlab Issue Trackers

I’m replying here rather than starting a new Topic. Other related Topics are here, here, here and here. (This Topic thread in particular is just both relatively recent and relatively long.)

I asked on the Topic for Discourse Code Review about whether it had any support for GitHub Issues:

tl;dr some degree of bidirectional sync of GitHub Issues and Discourse Topics as a feature of Discourse Code Review could be helpful for projects that currently have some ambiguity and redundancy between the two.

Cross-posting here because the other thread auto-deletes replies after a month.

1 Like

Hi Elsie! I do think you want a new #feature topic here because the github plugin you are referring to is not the code review plugin.

I can see you are super keen. I believe adding support for issues to Discourse Code Review is PR welcome, but am not sure. If you could lay out here in some more detail what you have in mind, maybe someone in the community can pick it up. If you have a budget for it, you can also post it to #marketplace.

2 Likes

Hi @tobiaseigen—thanks for your response. I’m not an administrator on any Discourse forums, and my suggestion is mainly based on a recurring experience I’ve had as a user and sometimes contributor on a variety of projects.

The reason I picked out Discourse Code Review is that it seems to be de facto the sole Discourse GitHub integration, unless there are other currently maintained projects I’m not aware of. Regardless, I’m going to rename this Topic to make it a little more generalized.

Basically the problem is triage: usually projects that have both a Discourse instance and a public GitHub issue tracker tend to have their users concentrated more on the Discourse instance, and when a user Topic is more properly a GitHub Issue, sometimes there will be friction in the process of the Topic finding its way to the people responsible for handling it.

Another way of looking at this is as inboxes or buckets: if end users are more active on the Discourse instance, and the developers are more active on the GitHub repository, essentially the developers or someone tasked with triage has to keep track of multiple redundant places for people to post their problems and figure out a consistent way of migrating Issues and Topics when necessary.

What I’m imagining with GitHub Issue sync is something like the Discourse WordPress plugin, where the Issue tracker and a corresponding Discourse Category are, to the end user, different views for the same underlying set of conversations.

Again, I’m not in a position to spend money on this feature. I’m posting here based on my experience and frustration with it being unclear where to post different types of feedback on certain projects and the tendency of misplaced feedback to fall through the cracks.

(Oh, and preferably there would be exactly the same functionality for Gitlab as for GitHub…)

Yet another way of framing this is that Issue trackers are just forums (or, to use older parlance, “bulletin board services”) with a thick layer of Agile project management slathered on top. Weirdly, they’re also kind of mailing lists, because people can interact with them entirely via email. Discourse is in the unique, central position of tying these superficially different (but in many ways functionally similar) services together in order to reduce fragmentation.

Thanks for explaining all this. Really it sounds like you need to ask the projects you are contributing to that are using Discourse to work on this. Right now it’s not even clear to me how many projects are making use of Discourse Code Review and how it’s working out for them. Feel free to PM me with some details so we can get specific.

That plugin is different… the discussions live only in Discourse and are embedded at the bottom of WordPress posts. They are not synced.

Right, yes, the fact that WordPress is so much more modular would facilitate that in a way that GitHub wouldn’t.