Opinion: development focus should shift towards improving LogSeq's partially unstable core

Paid user here (I ranked 8th on the all-time donation leaderboard). Big +1, all the replies resonate with me.

Overall, logseq is a lot more stable than it was one or two years ago. OTOH, tiny bugs still appear from time to time.

I do see most commits being bug fixes, which I appreciate. But as other people have mentioned, enhancement of the “core” feature seems stopped or at least not being given a lot of resources. If you look at the feature request list, the highest voted requests have been there for a long time, but no one seems to be addressing them, or at least put them on the roadmap where everyone can see.

That’s not to say that Logseq should not invest in new features. I do think AI writing will be very useful, just as someone else might feel the same for whiteboard. But they should NOT be the only focus.

Final thought: as I said on Twitter, I hope the Logseq core team still has control over what to do, and not the investors:
https://twitter.com/laike9m/status/1657422768407973890

6 Likes

Hey there,
I’m the contributor responsible for creating the list, but I haven’t received a response to my question yet. It seems that the limited bandwidth made it more of a hindrance than a help. I am no longer able to manage issues.

2 Likes

I wish to say that I agree with the general sentiment presented in this post. I use LogSeq on a daily basis and I can’t praise enough its combination of ingenuity and ease of use at the same time. I changed several PKM systems and eventually settled on LogSeq. I don’t want to go any further because LogSeq seems to resonate with the way I take notes and think perfectly well. However, I share beforementioned concerns. Endless stream of annoying regressions with each new release is often frustrating. There are longstanding bugs which are not addressed. Adding new features is cool, but for heavy LogSeq user like me, personally, stability of the core product is the most important feature. I understand that dev team is small and that they have their priorities but I believe that communication between users and developers could be improved on issues that matter the most for majority of users.

1 Like

To me it also feels that development is not focused on the core enough. Now, I only test/experiment with LS for now, and check the repo occasionally, so I might be wrong here. Personally I haven’t encountered any serious bugs/deal breaking issues (my limited usage might be the reasons). But still adding things like whiteboards and AI features seems strange for application that doesn’t support some basics like tabs ([Partial Done] Add tabbed windows to desktop client / Multiple instances of Logseq) or even replace (Find and replace a word in multiple occurrences).

As I said I don’t follow the application closely enough to speculate why is that the case, or if it’s reasonable. But I prefer software that focuses on its core first, and adds trinkets only when it is done.

enhancement of the “core” feature seems stopped

We definitely need more enhancements, but personally, the last several months had brought more enhancements that I consider major and benefited me greatly, than what I got out of year 2022.

  • one is “enabling backlinks for block references in properties”
  • the other is “showing page names in default query tables”

both of these I had been asking since 2021 and I am so so happy they got implemented.
(this year also had the query builder, which didn’t benefit me but I think many people appreciated it.)
but if I’m asked what’s the highlight for me in 2022, it would be the enhancement on backlink filtering… and maybe another something, too, that I can’t think of off the top of my head.

so my perception is that the pace of “great enhancements” implementation has been more or less the same, if not faster. — however, I didn’t write this to object your point or defend the team, not at all. rather, I want to use this opportunity to give examples of the kind of enhancements I consider crucial — more than any shiny new features — and would like to see more resources go into. For example the next big enhancement I’m looking forward to is the query builder for advanced queries.

I want to emphasize that the point is polishing (stability) and QoL improvements rather than “community requests”, because a few people (including elsewhere like reddit) have said something like “look at the Feature Requests here, why is the team doing whiteboards and AI instead of these top FR?” which I actually disagree with, because EPUB annotation is just as “new feature” and “big project” as whiteboards and AI; those are things of the same nature. The examples I gave are enhancements and actual pain points. EPUB annotation isn’t. It’s a new feature that has already been handled by other software (not only is calibre also open-source, it allows annotation links that can be very easily dragged into logseq) — the lack of unison of being able to do everything in logseq is “some pain”, but the same can be said for a lack of any non-existing feature, like AI.
Of course, there are many top FR here that are actual enhancements. I just don’t want the team to get the wrong idea from this thread so I’m being pedantic.

anyways, my opinion is this pace of enhancement implementation needs to quicken still, and I agree with all the sentiments in this thread. but I can also understand why the team prioritized what they prioritized:

  • whiteboards:
    • it was part of the founder’s vision from the beginning; so I really can’t blame it. it’s good to have a vision and actually work towards your vision.
    • obsidian also released canvas in the same time frame so on hindsight the timing worked out for them
  • sync and logseq pro: they need to materialize the business model, understandable too
  • ai: I can imagine they’re under a lot of pressure from the competition; this feature is also quite desired, to be fair
  • database: also to materialize their business model because they need to get collaboration working

(edited to add)

  • in-app handbook: people have been complaining about onboarding for a long time
  • numbered list: well this one i can’t justify (more on this in my post below)

I just hope from now on they will dial back on new things and look back to improve the old.

5 Likes

Thanks for providing your perspective. I added my reply in a new thread

2 Likes

If you look at the feature request list, the highest voted requests have been there for a long time, but no one seems to be addressing them

Basically we have tags on workload estimation / on roadmap, for highly voted tickets:

Also, I have an article about Logseq’s practice on QA. I may mention more on our bug-fix priority & issue managing.

Feel free to leave your comments.

I just closed some duplicated ones, while leaving those related open

Admittedly, there’s a bandwidth issue - given so many noise and false reports, I may overlook some really important comments. Especially it’s a reply in an old thread. So please ping me (e.g., Discord, as I may have > 100 GitHub notification per day, but I promise I’m trying to check each of them) when there’s something important.

And we need some advises on process enhancement.

4 Likes

I want to emphasize that the point is polishing (stability) …

When you define stability as a polishing point then I am not sure if I can understand the rest of your response. Stability is the main feature … without it using Logseq is pointless as it can not be trusted. It pains me to see it described as polishing :frowning:

1 Like

Absolutely.
But given the Devs are already focusing on doing stability improvement, we should figure out how to make better & how to make the efforts more direct:

English is not my native language. Let’s not focus on the exact wording here as the whole sentence structure should’ve made it clear that I am stressing the importance of stability.

7 Likes

Thank you so much for all the hard work you’ve put into managing issues and engaging with the community. Your unwavering commitment serves as a remarkable model for the rest of the team to emulate.

There is a lot of advice to give the issue is that committing and following through.

1 Like

Upvoted that one too. Thanks for not taking it personally!

My intention was to direct or summarize this post to make clearer requests, as I observed the messages we’re trying to communicate are not fully consistent, for example the following messages have intersections but don’t fully align:

  1. logseq should direct more resources from “feature projects” to bug-fixing and “enhancement projects”
  2. losgeq isn’t working on the top FRs here (implying they should) ( — but many of them are features)

To be clear, I think things like EPUB annotation are valid requests, but in the context of this thread bringing up “Top FR” muddies water a bit. “Message 1” is closer to the core of this thread so I emphasized that.

Another example is this message from View as numbered List - #16 by Joe_Smoe

So I have a question, why would the team focus on implementing this, but not something like Prompt user to confirm deleting block when an existing block reference is linked to the block - #6 by tobid ?, which I think would be a higher priority.

  • For one, it’s an example against “Message 2” because numbered list is a highly-voted community request.
  • Secondly, this mesage implies FR should not be taken according to votes but according to how much it would improve user experience. (Numbered list has 85 votes, the other has 28.)
    This aligns with “Message 1” and my personal opinion.


@Junyi_Du Thank you for being so active in this thread, though I don’t think the core question has been addressed yet. Rather than questioning the amount of bug-fixing the team had been doing (we all appreciate your hard work!), I believe OP and many were asking why some of the bandwidth that could’ve been spent on bug-fixing were used on “feature projects” instead.

In my previous post I outlined the past priorities I could understand, but I left out numbered list, because I could not justify it given the unstable current state of logseq that some resources went into that instead of fixing more bugs, especially because

  1. I don’t think it should take precedence over “parser replacement or improvement” which is on the table and would solve the number list problem in a much better way.
  2. There already is an excellent plugin; and the official implementation is also visual-only so it isn’t better than the plugin (except it works on mobile, but mobile plugin is also on the roadmap — no?)

So 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.



I wanted to show “the pace of enhancement implementation stagnated” is subjective so we do not get into more discussion on that and go off-topic if the team also focused on answering that instead of the main question.
Likewise, while “top requests are not being worked on” is mostly right, I worried someone would extend that to mean “developers are not addressing the FR section as a whole” which is imprecise, especially not for the “non-top but with decent votes” requests.

Here let me speak for the team a little bit so that they don’t do it themselves and make this thread go off-tangent:
If the first 10 requests are taken out, we start to see “done” requests sprinkled in, so devs have been addressing them, though not in the order or at the pace everyone desires.

For most of the unsolved “Top 10”, I could venture a guess why it’s not given a higher priority, so to me it’s not too unfair.

3 Likes

Thanks for pointing this one out, I was worried nobody would see it.

This is a very good point and I think it warrants the discussion of Feature Request vs Enhancements. Feature Requests would be those things that are new features that do not currently exist. Enhancements would be things that enhance existing features. The users can pick and choose what things are Enhancements or a Feature Request, but it’ll ultimately be up to the devs based off their knowledge of the codebase.

For example I considered this request to be an enhancement since it would be extending the existing block-reference feature: (Prompt user to confirm deleting block when an existing block reference is linked to the block - #6 by tobid, and something I would consider an improvement to user experience since it would prevent accidental deletion of existing links.

This would help the dev team get an idea of what things we are struggling the most as users and use this as another go-to list to pick from.

I think it warrants the discussion of Feature Request vs Enhancements.

I think it would be better as its own thread, because —

Feature Requests would be those things that are new features that do not currently exist. Enhancements would be things that enhance existing features.

This is also my criteria when making that screenshot, but even so I hesitated on many FR that extend existing features but the “extension” is a function which doesn’t exist yet. I can see people disagreeing with either so I put “equal parts?” there.

it’ll ultimately be up to the devs based off their knowledge of the codebase.

If using the developers’ definition, then a lot more of those would be features. For example the two examples (backlinks for block ref in properties & pages in query tables) I gave were both considered features, but to differentiate them from the whiteboards & AI kind of stuff I called them enhancements here.

Therefore, if we start the discussion, it’ll just be everyone stating their subjective opinion and demanding the team to find a tricky balance that satisfy most. And I don’t think we need that in this thread. The good thing is the developers are all dailydriving logseq and using it as a collaboration tool, so I trust them to know the pain points and make sound judgments.

I hope this thread wouldn’t get too noisy until a team member replies again because I went for it with

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.

so I want to see it answered :slight_smile:

1 Like

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

6 Likes

Thanks for your time and patience, this is a good answer!

of EACH dev

Thanks for highlighting the individual aspect. This is understandable, relatable and humanizes the developers, which is a reminder we sometimes need. logseq hasn’t left the phase of transitioning from a hobby project (which should remain so for the community contributors, of course) to an optimized business. But even if logseq fully transitioned, personal interest should definitely still play a part in the decision-making process because developers shouldn’t work for logseq like it is a chore. That takes the fun out of it.
But as a startup, logseq needs to be careful at planning, checking if each step fits into the big picture (for example first confirming if there would be a parser change, and if so, how does numbered list fits into the rough plan, and settle on the most efficient path) and it would require more intra-team communication, which could be a challenge for the remote international team.

Secondly, as this whole thread has been saying, the UX impact aspect should probably be moved up higher in the “priority ladder”. Personally I trust y’all to know what matters for UX and am satisfied with the transparency.

My last point comes from another observation, that the implementation difficulty aspect doesn’t only mean bigger projects are postponed (understandable and I’m not upset about it), but the “easiest jobs” are postponed indefinitely too because the team wants to provide opportunities for contributors — which of course is a good thing, and there had been feedback that the good first issue tag is greatly appreciated and has encouraged people to try their hands at a big complex project. But when a “small task” that is crucial for UX is left unnoticed for a time period that is getting unacceptable for mainstream users, then the team really should do it yourselves instead of waiting and forgetting about it — an example would be the removal of formatting tools from the mobile editing toolbar, with the PR welcome tag. It drops the “usability of the mobile app” from like 80 to 50 points, frustrated many users and was left untreated for half year . I have seen people left logseq because of this as they had to use mobile at work. I think for this particular example, the optimal waiting time would be like 2~3 months, then the team should just do it. So it ties into my second point that the UX impact should be the deciding factor most of the time.

But some case-by-case blaming is not that constructive.

I need to apologize about it. I did wonder if it would make @Charlie feel like he did the wrong thing (please don’t, you did a good job) but still decided to go with it. I wanted to use numbered list as an example, but I couldn’t figure out how to say it without implying the blame. But while I could wait for this feature to come out at a later time, one thing I really appreciate about this PR is that it shows the logseq team cares about community feature requests. In fact I was excited I could use it as a counter-example to “logseq doesn’t care about the community”.

1 Like

Obviously this ticket is forgotten. We need a mechanism of re-surfacing the simple but actively requested tickets.
The priority-A tag on GitHub for me to do monthly re-visit but it’s not that flexible.
Any idea?

  • One way is as you said, remind team members via discord as your github inbox is hell. Openly saying so might flood the #feedback channel too, though.
  • As I’ve repeated, I really trust you guys with the “knowing” part (i.e. knowing what’s important). The question is how this ticket went missing from the team’s internal board. I think it needs to be added to your internal kanban the first time you see it, with #priority-A , #enhancement , #could-wait-for-contribution tags.
    • The tasks with both #priority-A and #data-stability takes the highest priority
    • #priority-A + #bug generally takes higher priority than #priority-A + #enhancement , but it’s flexible as personal interest & implementation difficulty need to be factored in. I totally trust you with these.
    • #could-wait-for-contribution lowers the priority, but calls for a monthly review. If a task remains on the board after one or two rounds, and it has a #priority-A on it, then it needs to be done no matter what.

(↑↑ just an example. you guys need to figure it out)

4 Likes