Rework roadmap

[birkskyum]

Initial pass at making the roadmap more useful. Breaking it down to each project. Before, when it was together, i.e. the globe on GL JS was made, but did it then move the ticket to done, when it's not in Native yet?

This is easily resolved here by splitting into projects, so now Native can have an "under consideration" Globe/Terrain entries and GL JS have a "released" Globe/Terrain entries.

Main roadmap page

Each projects roadmap pages also have tab navigation

[CommanderStorm]

You are the best.
Please give me 1-2 days to add a roadmap for martin.

Lets also move the MLT under general and duplicate it under gl-js and native. This way, it is much more visible

[CommanderStorm]

Okay, I added the roadmap items for martin.

A few of the items:

• should we either split the MLT roadmap item into the project level (general, gl-js, native) or into the encoder/decoder level? One roadmap item does defintively not represent the level of effort that this is.
• who do we communicate our different level of support (professional maintainers vs volunteer based) and

I would also like a very blunt messaging around:

Missing a feature? Please open an issue, contrinbute a feature or sponsor us!

[birkskyum]

Okay, I added the roadmap items for martin.

A few of the items:

• should we either split the MLT roadmap item into the project level (general, gl-js, native) or into the encoder/decoder level? One roadmap item does defintively not represent the level of effort that this is.
• who do we communicate our different level of support (professional maintainers vs volunteer based) and

I would also like a very blunt messaging around:

Missing a feature? Please open an issue, contrinbute a feature or sponsor us!

Yeah, I wasn't sure how to tackle it either. I think the most important is that each ticket is correspond to a specific piece of work, that can be declared resolved. If we currently have MLT encoder in java in place already, we can maybe put a decoder entry in each renderer (in progress in native, under-consideration in gl js, and the MLT Spec entry in progress in the General to be resolved imminently?

[birkskyum]

Also, this the "under consideration" status, it might be more accurate to replace it with a Backlog, and/or Planned status, to align with a kind of Scrum/Kanban board?

[HarelM]

Are we reimplementing GitHub?
I would recommend finding a more automated/semi automated way to handle this using github labels maybe or anything that doesn't require a change here everytime something updates in one of the projects.
Even a CI action that can update this based on some heuristics...
Even a link to a relevant dashboard or milestone in GitHub would be better I think than a stale page in maplibre.org...
Just my 2 cents, I think this looks great, but keeping it up to date is, well, complicated...

[birkskyum]

Trying not to implement github - just provide an "at a glance" kind of overview, but it's a good point that maybe we can pull it. I think as long as it's just the "big ticket" items, rather than hundreds of github tickets, we'll be able to keep up somewhat with manual entry - but there'll always be a bit of have a delay of course. For instance in Native (SDKs aside) the past few years can almost be roughly summed up as Modularization -> Metal -> Vulkan, and now a Plugin system, and some other high level milestones. But, as you point to, those milestones could actually just be select large GitHub Issues (like harfbuzz), or GitHub Milestones. In general I think it would be good for us to use the github milestones more, to show people what's coming up and how far new release cuts are away, so would be cool if we can pull from there.

Maybe we can land the current rework as manual entry, because it's effectively there now, and then figure how to automate in the next iteration?

[CommanderStorm]

Building the automation for tracking this on GitHub would be much more work than just changing the labels once something is done.

At least for most things, you would want to touch up/ revise the issue once it gets marked as done anyhow.
Example:
https://github.com/maplibre/maplibre.github.io/blob/9cac85630bfed291d22f69130c326d33c0fe0292/src/content/roadmap/martin/frontend/index.mdx

[CommanderStorm]

To clarify above, nothing is blocking merging.

This is an improvement already, the things that I marked as TODO are just items where we need to make a decision.
We can move them to issues as well.