[Discussion] Roadmap Clarification

[amitnovick]

Hello friends,

Xournal++ is an amazing application which I use every day, and is an outstanding FOSS project.
In attempting to spark some enthusiasm towards further improving Xournal++ in ways that I would like (and I think fellow users and developers would like too), and in lack of a visible roadmap list, I think it's a good time to take a look at where this project is at and where we could take it.

The good

Xournal++ has grown tremendously over the past few years.

The star-increase-statistics, if any indication (usually is), support this:

All the while, the project is far from being frozen in time, with many new features being introduced.

Surprisingly, the additions of features appears to have been under control such as to keep code accretion to a minimum.

Indeed, this can be seen by the following code base source code size comparison between two snapshots in time:

Current (September 2023, post release of v1.2.1 - 9k stars) C++ code size under src directory: 57334 LOC (git commit: 718e57b)
Old (Feb 2020, release of v1.0.17 - 1k stars) C++ code size under src directory: 60778 LOC (git commit: 12febf7)

(src directory's C++ code size is probably a good proxy for this measure, as it's where most changes in the code base have occurred during that time frame)

The bad

Technical debt is a phenomenon that impacts every successful evolving software project.
It is quite obvious this project is impacted by it.

Some dry statistics :

• 900+ open issues
• 60+ open pull requests

Most prominently, the occurrence of catastrophic failures has increased and this should be of the highest importance for obvious reasons (see: crashes, segfaults).

Right behind that, performance characteristics of main user interactions are less-than-optimal in many scenario (see: rendering lag, zooming lag).

And trailing behind those glaring issues,, implementing major features has been out of reach for quite a long time (see: infinite canvas, mobile/web app).

Status quo

In my view, the way things are currently done, is things are implemented on a it-itches-me-too-much basis (not saying it's necessarily bad, clearly it's working).
That is to say, development is focused on solving specific itches one at a time, each corresponding to individual developers most concerned by it/most willing and able to push it forward.

There are some problems with this.
The biggest issue is that it's not obvious what the highest priority thing to work on is.
This leads to confusion.
A person comes in wishing to solve problem X/add feature X, but work on X cannot start before task Y is completed first (e.g. work on infinite canvas cannot start before the overhaul of the rendering engine task is completed, work on crashes/segfaults can't start before some research into the causes of these problems is completed)

A path forward

I propose that we work on identifying goals we want to prioritize and list them somewhere visible (e.g. a ROADMAP.md file in the root directory, and create one main issue for every goal to try to focus all discussions on it in one place, whether it's a maintenance goal or a feature goal). All work that depends on these goals can then refer to them directly by issue number.

This solves a lot of confusion/lack of information:
Goals don't just exist in some issues buried in the issues tracker.
Everybody coming in can be referred to the one place where the goals are listed (e.g. the ROADMAP.md file, and the corresponding issue for it).

This also helps us track progress on these goals. Blocking goals that stagnate can receive the attention they deserve.

Thoughts?

Please let me know what you think about this.
Amit

[bhennion]

Overall, I think there are well-identified long-term objectives the devs sort of agree on:

1. The view refactor and the MVC pattern (View refactor #4051 and issues linked therein). The longstanding performance issue is in big part due to our very rigid rendering system. Some progress have been made towards this, but this is a lot of very difficult work. The next steps are the refactor of EditSelection/EditSelectionContent into an actual MVC pattern - I have a draft branch somewhere about this. After that, we will finally be able to split PageView into View/Controller.
2. The new file format New Fileformat - basic steps #937: that one is a bit elusiv, but some progress has been made by @eldipa recently. Again, it has some performance implication.
3. More as a latent objective: porting to GTK4 GTK4 preparation #2722. This will require a lot of refactoring. It is happening, slowly.

It is still true that some better advertising of those goals would help.

[eldipa]

Some better advertising can help indeed. Not only for giving visibility from the developers to the users but also between the developers.

I thought ways to give visibility about my progress on #937 and I tried a few things like creating a Github Project, writing a Github Discussion and writing directly to the issue #937. Not sure how much effective I was :D
Perhaps we could choose a place to write periodically (every n months?) a summary of where we are and what are the next steps for each main initiative and a link to the Issue where most of the details are. This could also help to identify which initiatives became orphaned/stale or if some X reason we decided to put it on hold.