I start this thread as I see some problems that the ongoing discussion reveals: Logseq users don’t have a full picture of Logseq’s roadmap.
People have different opinions on what Logseq should add next, which we can’t change. But I guess we all agree that it would be beneficial if the dev team can bring more clarify to what they are and will be working on. I vaguely remember seeing a roadmap somewhere, but did some search and can’t find it now (which shows part of the problem…). There’s a kanban, but it’s more dev-team facing instead of end-user facing.
Let me describe what I have in mind:
A strategy/vision doc
- What the dev team see Logseq be in 1 year, 2 year, 5 year, etc
- Reviewed and taken feedbacks from the community, and refined to make sure it has no major conflicts with what the majority of Logseq users want. Community discussion is the key part. Logseq arised from the community, let’s keep it that way. It doesn’t have be agreed by everyone cause that’s impossible.
- Make it the northstar, so that whenever people have different opinions on where Logseq should go, there’s something to refer to to resolve the conflict.
- Publish it somewhere obvious (e.g. link from official website).
- If big changes need to be made to the strategy, an announcement needs to be sent out, just like a new release. If it’s big enough, another round of community discussion is surely required.
A good example is Rust Lang Roadmap for 2024
What’s being worked on, and planned for future releases
It’s very common for a software or programming languages to publish what’s coming for each future releases. Taking Python as an example, every accepted PEP has a “Python-Version” field, which indicates in what future version will this enhancement be added.
We could apply similar things to Logseq. With so much going on in Logseq development, it can’t and shouldn’t include everything – but the major changes (enhancements, new features, breaking changes) should be included.
For example, as of writing, the latest release is 0.9.6
- 0.9.7: add small-feature-foo
- 0.9.8: add small-feature-bar
… - 0.10.0: add some-big-feature
It doesn’t have to be so accurate, the gist is just to let end users know what to expect.
Summary
Logseq team is hard working, for which I’m forever grateful. At this point, it seems what’s lacking is a grounded understanding of what the team is, will, and should be working on. This gap can only be filled by creating a formal communication channel. That’s what this thread for, it’s not about “what” Logseq should build next, but about creating ways so that we (logseq team and users) can have a mutual understanding/agreement of what to build next.
