Rich Text Feedback On Research Modules

Currently the inline commenting functionality on the research modules only supports plain text, which can be a problem when, for instance, illustrations may be necessary, and the format is not conducive to per-issue comment threading. I talked about this a little bit in my comment here: https://discord.com/channels/586676777334865928/1086332488693076058/1109621508743102484 But one thing that may help could be integrating with GitHub or Gitlab "Issue" tickets (which can in turn be bridged to Discourse, which could make them easier to find).

7:22 PM

On the one hand, it could be possible to use a bot of some sort to create git repositories for each approved research module, so that each one could have an Issue Tracker. I'm not sure how this would integrate with existing comments, but both GitHub and Gitlab have APIs you could take a look at: • GitHub Issues API: https://docs.github.com/en/rest/issues?apiVersion=2022-11-28 • Gitlab Issues API: https://docs.gitlab.com/ee/api/issues.html • Discourse Code Review: https://meta.discourse.org/t/discourse-code-review/103142

Issues - GitHub Docs

Issues API | GitLab

Discourse Code Review

:discourse2: Summary Discourse Code Review allows the ability to review GitHub commits on Discourse.

Repository Link https://github.com/discourse/discourse-code-review

Install Guide How to install plugins in Discourse Features What it is? The Discourse Code Review plugin provides 2 way integration with GitHub code repositories. It...

7:22 PM

On the other hand, if you wanted deeper integration, you could consider using git as a data backend for the research modules, with each research module backed by its own git repository, and with a human-readable on-disk data representation. (Of course you could still use front-end caching.) The two big issues I could foresee with using git as a backend are: 1. Even with GitHub or Gitlab, the process of forking/branching and pulling/merging is not particularly user-friendly, and non-software-engineer contributers may find it impossibly difficult to use. This would not necessarily be a problem with Issue tickets, though, and for simple patches the web interface for Pull Requests is a lot easier to use. 2. Git is not particularly conducive to large binary files, as any change to a binary file creates a full-size duplicate, and the disk size of a repository can balloon rapidly. And machine-generated text-based formats can be a mess to work with, as well (see, for instance, SVG or STEP). In the case of things like Fusion 360 files, it may work better to integrate directly with first-party collaboration tools.

7:22 PM

Does anyone else have ideas for how to facilitate richer, more structured feedback around the research modules (ideally without reinventing the wheel)? Thanks!

Thanks for the feedback and ideas

There's a community platform meetup in a few weeks where we'll be looking at current functionality, perceived gaps, new requirements etc. and I know that facilitating dialog in the best way possible will be a key part of that so watch this space.

Oh, cool!