How do you know if something should be a feature request or a bug report?

The first thing I do when it seems like something isn’t working as it should is to scour both the documentation and the support community for any reference to the issue. But that doesn’t always unearth the needed info. For most apps, I would rely more or less on documentation, but logseq’s documentation is really sparse in a lot of areas, so it’s hard to tell whether something isn’t mentioned because it’s not available, or because nobody has gotten to writing about it yet.
Example: I noticed today that text alignment in markdown tables does not work in logseq. After looking for more info, I have no idea whether alignment was intentionally left out for some reason, if there’s a logseq bug that is breaking it, or if it is something wonky on my install of the app.
If it should be working, I would like to file a bug report. But there’s a lot of stuff going on here, and I don’t want to waste anyone’s time on something this trivial, if it is, in fact, not an offered feature, rather than it being a bug.

From my experience Logseq devs tend to call almost everything a “feature request”. I reported as a bug that Logseq doesn’t support Markdown syntax to turn images into links and they replied it’s a feature request.

So my advice is to report as “bug” only glitches, data losses and stuff like than. Everything else is a feature request, even better support for Markdown syntax.

1 Like

Thanks for the wisdom won from hard experience! I appreciate it!