Call for more clarity on Logseq's roadmap

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.


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.

For vision / roadmap:
We are working on a new vision page.
Basically we have some discussion on the Discord:

We do actually have a version field for newly implemented features:

I think one can be improved here is to make the version numbers as references. May start this practice in the next release.

Also it make sense of having more documenting on the roadmap items. But as we are in beta and don’t have a “release candidate” process, it’s hard to expect “what to have in next release”, compared to those with the process of doing rc
Maybe it’s near to the time point to have a rc process.

More details:


Another good example

1 Like

Was this Vision page created?