For the difference between tag FR & Enhancements, it doesn’t matter that much to the Devs, as they are treated as the same. In most cases, it only reflects a guess on the workload to implement the requested stuff. So in recent days, we also introduced the estimation tags to avoid confusion.
rather than asking us if we have advice on making issue management more efficient or direct, you need to address how you would make more strategic decisions on resources allocation.
For FRs & Enhancements, basically it’s a mixed decision based on ((Impelentation difficulty)), votes, UX impact & the personal interest of EACH dev. I may rate ((Impelentation difficulty)) as the top consideration, as Logseq is really a much more complex software than most of the competitors in this field. It’s making a “context switch cost” so high that devs can only focus on a field of the Logseq to work on in a given period of time.
Also refer to About the Feature Requests category for how the FR vote works.
I’m open to any advises on making this “allocation process” be more transparent. Adding estimation tag was one result of such the suggestion. But some case-by-case blaming is not that constructive. It’s having more effect on negating the team’s and contributors’ efforts on running this open-source project.
Also we highly appreciate those contributors who submit PRs to the codebase for the features they want. It’s providing an extra development dimension for Logseq.
To maximize the bandwidth proficiency, I will append this peer-to-peer reply to the Logseq - development strategy and quality control