The conclusion is that it’s pretty good on features. The only downside is the migration from JIRA (which still needs to be tested By ClementC).
Thus we need to discuss what would be the next steps. I have the following questions/ideas:
Are you ok that we continue evaluating OpenProject (OP) or do you have a better idea?
If we’re ok, I’d propose that we start by doing the following:
Ask XWiki SAS kindly if they could provide a hosted instance of openproject for us to use
Whenever there’s a next contrib project created, ask the leader if he/she’d be ok to try out using openproject for that project. I’m volunteering to help set up the project according to our best practices.
Learn from that project and define a template for XWiki.org projects
Wait for ClementC’s info on importing from jira to know how well or badly that works. My guess is that we’ll need to keep a readonly jira.xwiki.org web site for the foreseeable future (and write for admins), use openproject to create new issues and slowly migrate issues to it somehow (at worst, when a dev takes an issue to implement and that issue is on jira.xwiki.org, manually recreate it on OP & close it on jira).
Create OP projects for commons, rendering and platform and more generally for any jira project from the XWiki github org.
The items in red are blockers and the ones in warning are not blockers but we’ll need to work differently in OP, possibly loosing some features but they’re not showstoppers.
I’ve now done a first configuration pass for https://op.xwiki.org/ and created some test project there. The next step is for me to work with the next person needing an issue tracker for a contrib project and propose to use OP.
I’m 100% sure we need to keep jira read-only since it’ll take a very long time to migrate the thousands of jira macros and JQL queries found on xwiki.org.
Not done yet, I’d prefer to wait a bit and start with a contrib project first.