Hard to automate (I haven’t dug much, but this is my current understanding)
Hard to replace, I looked into using Jira macros, but this is quite some work, involving improvements of the Jira macros.
In addition, while I don’t have usage statistics, I think this dashboard is really rarely used. For sure by me, but also by colleagues I discussed the matter with.
So my proposal is to remove the dashboard creation steps from the release plan template, and to remove the dashboard line from the release note template.
Of course, we can wait for someone to realize it is missing, and to ask them what exactly they are using the dashboard for. Based on that information, we can decide how to best communicate the missing information to the community.
We want to migrate to OP and it doesn’t have the feature needed for these graphs
If someone is interested by stats, we could probably provide them as part of a more generic dashboard such as Loading... but not just for bugs.
I think that for now, we could still keep the cycle dashboard, once per year (until we move to OP and we’ll look for an equivalence - there are some graphs available).
However, I’m -1 to remove the line from the RN pages as we need to provide a link to all the jira issues fixed by an XWiki release. So rather than removing it, we should replace it with a JQL listing all the fixed jiras for the release.
Thanks all, since we have a general agreement, I propose to apply the decision by:
Update the release note template to replace the dashboard link to " Full list of issues fixed for <final version here even for RC, e.g. 10.5>"
Update the release plan help to:
Mark the dashboard creation step as deprecated as we did for the Update Translations step
Add a new section detailing the url to use for the full list link. A query like component != "Development Issues only" AND project in (XCOMMONS, XRENDERING, XWIKI) AND fixVersion in (18.8.0-rc-1, 18.8.0) producing a link such as Loading...
Update the release plan template to say “Update the link to the full list of issue for the version”
For the URL to the full list I actually see two options:
Option 1: write the query in the url (e.g., Loading...)
Option 2: ask the RM to save the query as a filter, then use the filter ID in the URL (e.g., Loading...)
Option 2 is slightly more work, but allows updating the query while keeping a stable URL.
+1 for option 2 especially because I think we can later automate this step but creating:
Creating the filter programmatically
Saving the URL to the list of all issues in a structured data in the Release Note app (later saving a link to Open Project, once the migration done).
I don’t really understand, what you mean here. Both versions are stable, it’s just that one is explicit and the other is hidden behind an id.
To me, the id based one is just useless work since we can easily generate the right URL in the page (like we do currently in bugfix releases notes for pretty much the same need).
Indeed, I did not have in mind the case of releases notes where you have to exclude some versions.
Still it feels simpler to take care of that directly in the release note page than having to create a jira filter. I don’t think it’s a big problem that the URL changes in the release note if you forgot to put the excludes initially.
I would also prefer to take this opportunity to limit as much as we can dependencies on jira specific things (like issues filters), since we are going to get rid of it.
We shouldn’t burden the RM with this. We know the version already so it’s easy to automate it. As we already do for displaying blockers issues and more.
And yes if there’s a need to update it, it can be updated when editing the page but it should be generated IMO
Edit: I see Thomas said the same thing. I’m in agreement.