Description

• Candidates
• Requirements
  • Must Have
  • Nice to have
• Evaluation Criteria
• Migration
• OpenProject
  • Nice to have
  • Evaluation Criteria

Atlassian announced the end of self-hosted JIRA:

 On February 2, 2021 PT, we will stop selling new licenses for our server products and cease new feature development in our server product line. Server customers will have access to maintenance and support for an additional three years, ending February 2, 2024 PT. 

This means that we'll need to migrate from JIRA to some other solution or jira.xwiki.org before 2024 since at that time, no more security issues or bug fixes will be released.

Candidates

We're gathering below a list of possible alternatives for the future that will need to be evaluated to take an educated decision:

• Move to JIRA Cloud (OSS software are eligible. We would need to check the limitations).
• GitHub Issues (Note: XWiki is currently on GitHub)
• GitLab Issues (open source)
• Focalboard (open source)
• Taiga (open source)
• JetBrains Space (includes an issue tracker) (not open source)
• Pachno (open source)
• XWiki app
• OpenProject
• youtrack (not open source and XWiki not eligible for an open source license)
• Plane. Open source at https://github.com/makeplane/plane
  • The main problem is that we need the Pro features (paying). The open source dev seems to be for basic features only.

Requirements

Must Have

• Vincent: Be able to issue queries to find issues (JQL), including global search in all projects. It's used in lots of places, including on hundreds of pages on xwiki.org
• Vincent: Be able to label issues. We're using the following labels
• Vincent: Be able to have several resolutions for issues (Won't fix, Fixed, Duplicate, Solved By, etc.)
• Vincent: Be able to have categories (components in Jira parlance)
• Vincent: Be able to automatically link GitHub commits with Jira issues (i.e., links from Jira to the commits)
• Vincent: Be able to have several issue types
• Vincent: Be able to have graphs to follow, for example, the number of bugs created vs resolved
• Vincent: Be able to have REST endpoints to create XWiki macros (e.g., the JIRA macro) or scripting in xwiki pages
• Vincent: Be able to have several projects (one for each repo)
• Vincent: Be able to have several groups (categories in Jira parlance), see https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000
• Vincent: Be able to mass refactor issues (select issues with a query and then apply changes to all of them: add a fix version, etc.)
• Vincent: Be able to set permissions/groups/roles for authorization
• Thomas: Must be publicly accessible
• Thomas: Anyone should be able to register and create issues
• Vincent: Be able to have shared schemes to share configs between projects (permission scheme, workflow scheme, etc.)
• Vincent: Be able to define custom fields (we use that for documentation and flickering tests for example)
• Vincent: Be able to receive notifications (individual or to a notification list)
• Vincent: Be able to import existing issues from Jira and not loose metadata ideally
• Vincent: Be able to move issues (and not have to close and copy issues)
• Thomas: links between issues (“depends on”, “is related to”, etc.)
• Lucas: Store a detailed history of the issue state
• Lucas: Be able to add attachments and display pictures/video integrations
• Vincent: Be able to have priorities, including a Blocker priority.

Nice to have

• Vincent: Be able to have dashboards for releases. Example: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=15691
• Vincent: Be able to see similar issues when creating new Jira to avoid duplicating existing issues
• Vincent: Be able to execute scripts inside the issue tracker to query issues and perform changes
• Thomas: links issues with issues from an external bug tracker (Apache Jira instance, etc.)
• Vincent: Be able to sponsor issues (e.g we used to use FreedomSponsors in the past)

Evaluation Criteria

List of criteria beyond the requirements need. Possible ideas:

• Large community
• Established product
• Frequent releases
• Open source

Migration

Some ideas for migration:

• To preserve Jira macros on xwiki.org, we could:
  1. execute all pages on xwiki.org to obtain all JQL queries used
  2. download the issues for all queries and store the responses somewhere (e.g., in a database table)
  3. replace the Jira macro by one that reads responses from the stored responses
• Keep a snapshot of the machine that hosts Jira around in case we notice we missed something.
• Create redirects under the old URLs for individual issues and dashboards as they are linked frequently.
• Find out which other URLs are frequently accessed on jira.xwiki.org and create redirects for them
• We have a parser for CQL which is basically the same as JQL which we could use to parse used JQL queries and map at least some of them to whatever query system the new system uses.

OpenProject

OpenProject is a great OSS project that checks many points mentioned above. XWiki SAS is also actively working with their team, and plan to provide an integration between XWiki & OpenProject.
Let's review the previous points in order :

• > Vincent: Be able to issue queries to find issues (JQL), including global search in all projects. It's used in lots of places, including on hundreds of pages on xwiki.org 
  • No Jira Query Language, but a REST endpoint. No advanced search. Advanced filtering in a root project can be done.
  • Need to structure the projects with a root one (for example XWiki Standard Flavor, XWiki Contributed Projects — Recommended, XWiki Contributed Projects — Others, …) and with the subprojects on top.
  • Search is limited overall, for example when searching from a top level project, you can't filter by versions that are present in child projects.
  • Search is filter based, and re-creating the URL from the filter is non-trivial.
• > Vincent: Be able to label issues. We're using the following labels  
  • Yes, ability to create a "Labels" custom field (of type "List"), searchable, can assign more than one label per “work package”.
  • Limitation: The allowed values for a custom List field are fixed. This prevents users from creating new labels. OTOH, this is good and avoid explosions of labels.
• > Vincent: Be able to have several resolutions for issues (Won't fix, Fixed, Duplicate, Solved By, etc.)
  • Yes, built-in options and possibility to create “closing statuses”.
• > Vincent: Be able to have categories (components in Jira parlance)
  • Use the existing "work package categories". The available categories are configurable, per project.
• > Vincent: Be able to automatically link GitHub commits with Jira issues (i.e., links from Jira to the commits)
  • Yes, see extension, works in practice.
• > Vincent: Be able to have several issue types
  • Yes, built-in list plus possibility to add custom types.
• > Vincent: Be able to have graphs to follow, for example, the number of bugs created vs resolved
  • No, graphs options are very limited in OpenProject.
• > Vincent: Be able to have REST endpoints to create XWiki macros (e.g., the JIRA macro) or scripting in xwiki pages
  • Yes, see previous. Uses basic auth, generate a token in your account's settings. One token per account.
  • Generic Accounts should be created for tokens.
• > Vincent: Be able to have many projects (one for each repo)
  • Yes, multiple projects with subprojects are possible, with inheritance rules & templates (for subprojects).
• > Vincent: Be able to have many groups (categories in Jira parlance), see https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000
  • No. You can create multiple levels projects, with one “encapsulating” multiple others, but can't properly display this information in a dashboard.
• > Vincent: Be able to mass refactor issues (select issues with a query and then apply changes to all of them: add a fix version, etc.)
  • Yes, with the use of a filter then bulk edit the issues returned. Important limitation : only propose to replace fields, can't add / multi-select options in a field.
• > Vincent: Be able to set permissions/groups/roles for authorization
  • Yes, permissions based on roles / groups / projects
• > Thomas: Must be publicly accessible
  • Yes.
• > Thomas: Anyone should be able to register and create issues
  • Yes. Possibility to use OIDC on OpenProject with XWiki org as a provider.
• > Vincent: Be able to have shared schemes to share configs between projects (permission scheme, workflow scheme, etc.)
  • Yes, can select a project to be a template. When creating a new project, the template will be proposed, with choices on the content to copy (work packages / issues, …).
• > Vincent: Be able to define custom fields (we use that for documentation and flickering tests for example)
  • Yes, easily
• > Vincent: Be able to receive notifications (individual or to a notification list)
  • Yes, for individuals, yes for mailing lists with fake user.
• > Vincent: Be able to import existing issues from Jira and not loose metadata ideally
  • Yes, a custom Excel macro exists (export Jira issues in a CSV form, then use the macro to import them into OpenProject).
  • OpenProject could be working soon on an official migrator for Jira.
• > Vincent: Be able to move issues (and not have to close and copy issues)
  • Yes, can switch issues between projects and subprojects
• > Thomas: links between issues (depends on, is related to, etc.)
  • Yes, for relation, duplicates, blocked by, precedes, follows, includes, part of, requires, required by. Solved By done as an Issue Status.
• > Lucas: Store a detailed history of the issue state
  • Yes, through the activity tab, access to a complete history
• > Lucas: Be able to add attachments and display pictures/video integrations
  • Yes, supported in app and with a Nextcloud extension.
• > Vincent: Be able to have priorities, including a Blocker priority.
  • There's a default "Priority" field that exist and the values are configurable (A Blocker value can be added).

Nice to have

• > Vincent: Be able to have dashboards for releases. Example: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=15691
  • No, the proposed graphs options don't allow for such customizations. Only one basic dashboard per project.
  • For a release, only can display the list of issues related to the version.
• > Vincent: Be able to see similar issues when creating new Jira to avoid duplicating existing issues
  • No, still at the IDEA stage.
• > Thomas: links with issues from an external bug tracker (Apache Jira instance, etc.)
  • No. Only GitHub / GitLab / OneDrive / Nextcloud / Excel integrations exists (integration FAQ).
• > Vincent: Be able to execute scripts inside the issue tracker to query issues and perform changes
  • Rest API is accessible, but scripting is only possible client side. No server side scripting options.

Evaluation Criteria

List of criteria beyond the requirements need. Possible ideas:

• > Large community
  • Good,
  • Contributors : https://github.com/opf/openproject/graphs/contributorshttps://community.openproject.org/
• > Established product
  • Yes.
• > Frequent releases
  • Yes, https://www.openproject.org/docs/release-notes/
• > Open source
  • Yes : GitHub Organization : https://github.com/opf/