Roadmap locations for Extensions

Hi devs,

Currently we do roadmaps for XS at https://www.xwiki.org/xwiki/bin/view/Roadmaps/. And we do XS release notes at https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/. For “largish” extensions we also put Release notes on https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ (we did it only once so far for Activity Pub).

So we need to define a recommended location for roadmap for Extensions which want to have a roadmap (such as for GSOC work for example).

My proposal is to have the roadmap done on the design page on design.xwiki.org. The rationales are:

  • It shouldn’t go on the exo page since that page is about results not development
  • The design page is mandatory for GSOC and for any largish extension that will require a roadmap
  • The design page has a state (in prgogress, done, dormant, etc) so that also provides a status about the roadmap when in the future you land on it. So that’s good.

I also propose to update the README template for GitHub extension repos to add optional design page link + optional roadmap page link at https://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HREADME.mdTemplate

The goal is to have the README link to all places.

The https://www.xwiki.org/xwiki/bin/view/Roadmaps/ should also be modified to mention this, similar to what we have on https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/.

Last, the https://contrib.xwiki.org/xwiki/bin/view/Main/WebHome page should be modified to mention this too.

WDYT?

Thanks

1 Like

Hi,

Another option would be to use GitHub more and let contrib extensions handle their roadmaps on the GitHub project’s wiki pages and, building on this (since it would make more sense), to handle their issues on the GitHub issues section.

The https://www.xwiki.org/xwiki/bin/view/Roadmaps/ should also be modified to mention this, similar to what we have on https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/.

Not sure what you are suggesting here. Should we have a Roadmaps application like we have a Release Notes app and use them both for various (including contrib) projects? If so, then it would conflict with the previous proposal of using design.xwiki.org for roadmaps of (contrib) extensions.

I tend to see 2 directions:

  1. Push (contrib) extensions even more towards xwiki.org (+ jira + etc)
  2. Push them more out of xwiki.org (and suggest to use more GitHub).

A gut feeling tells me that option 2 might be much more developer-friendly than forcing them to use the tools that we use to develop XS/the platform.

1 Like

Yet another option would be to actually use contrib.xwiki.org, since it’s a dedicated wiki that just holds a single page (AFAIK). We could have a Roadmaps Application (that I mentioned above, if really needed) and install that on that wiki or come up with a better way of using the contrib wiki for the contrib devs/extensions.

I’m very against this. We already discussed it several times and every time we said no. The idea is to have consistency in the xwiki.org projects. They either all use JIRA or none use it. It would also be very bad IMO to not eat our own dog food and use GH’s wiki instead of XWiki’s wiki. So I’m really against this idea :slight_smile:

Over time we should definitely have one but that’s not what I’m saying. Just editing the text at https://www.xwiki.org/xwiki/bin/view/Roadmaps/ to explain where to find roadmaps. Same as on https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/

I don’t understand the “even more” part of option 1. It’s already the case and what we agreed and voted on.

Yes we discussed this in the past and in the end we said we didn’t need it since we had the design.xwiki.org page + the exo page.

You didn’t mention in all your replies what you don’t like with roadmaps on design.xwiki.org :slight_smile:

What I don’t like about using design.xwiki.org for Roadmaps is that it would be hijacking something that currently works, is relatively clean enough and is quite clear on its purpose.

Pages on design tend to be (by design, no pun intended :slight_smile: ) very feature-oriented and with a limited lifecycle in mind (i.e. the feature is proposed, analyzed, refined, implemented and, finally, done and only kept for reference). It also targets mostly new features and, at most, improvements, but not bugs (which can also be part of roadmaps).

Roadmaps, on the other hand, are “living things”. You handle roadmaps for products/extensions which are made of multiple new features, improvements and/or bug fixes. You track the evolution (i.e. not its design, since that is pretty short lived and happens only at the beginning) and, when it’s done, it’s not really done, because you start again with the new version/iteration. Sure, you can break it in per-version roadmap pages (e.g. “Extension-X-v11.5-Roadmap” page), but that would just be a workaround.

In my mind, “Roadmap” is more related to “Development” (e.g. “dev” wiki which would not only contain dev tools, API and process, but also the progress; the example is “valid” because on dev we also declare the process of developing XS itself, not only how extension devs should develop work with the platform) than to “Design” (which is not really a concept that includes “progress of execution”, since that part usually comes - if, for argument’s sake, you think at the Waterfall model - after the design/analysis step :slight_smile: ).

I also get that we can look at Roadmaps as something that covers all aspects of the development process (design, implementation, testing, etc.), for each iteration so it should be somewhere above all that, but, in any case, not mixed (location-wise) with one of the steps which it contains (in this case, the design step).

It probably does make sense from a purely pragmatic pov to have roadmap pages in the design wiki, but, to me at least, it just does not sound right to mix the 2 concepts.

After thinking a bit more on it, maybe the better alternative (potentially a bit more costly, but maybe cleaner, in the end) would be to look into some dedicated project management/planning tool that would allow us to nicely aggregate all the steps of the dev process and manage them more easily and maybe in a more modern approach than by writing something on a peace of paper (i.e. wiki page) :).

AFAIR, even Jira is supposed to be pretty good at managing Roadmaps (with/without plugins) for each project (so it would work for both XS and each individual extension) as it would technically make the most sense in our current situation (roadmaps are usually just an ordered list of jira issues and it would also enforce us to create jira issues for each task) and since we already heavily use it. I know this has been discussed before as well.

Other tools more dedicated than Jira (and possibly allowing to easily integrate the issue tracker) exist. Why not consider this approach instead of us coming up with our own custom solution (again) to a relatively common (and simple?) problem?

Hope the input is useful :slight_smile:

1 Like

Yes, JIRA could be good for roadmaps (JIRA Agile probably) , I agree completely, and so could be Trello (belongs to Atlassian too). I’d prefer JIRA because that’s what we use already and it avoid duplicating issues since we need them in jira in the end.

We should investigate it. The main question in my head is whether it allows to put contextual info in it that are not tasks. See https://www.atlassian.com/agile/product-management/product-roadmaps & https://www.atlassian.com/software/jira/features/roadmaps

It is :slight_smile:

FWIW, seems Trello has a “power-up” feature that links jira and trello: https://trello.com/power-ups/586be36326cc4c7e9f70beb3/jira Now trello is not free and we would probably hit limitations.

JIRA standard roadmap is only avail in jira online. And JIRA advanced roadmap is most likely not free for open source.

Now a simple xwiki roadmap app is also a good option :wink: I don’t think we need/want any complex roadmap feature and it allows continuing our integration with jira, which is interesting.

Can be a GSoC project for 2021 :slight_smile:

yeah… :slight_smile: except that it’s too small… it’s a 1/2 day job IMO (maybe 1 day).