Allow creating JIRA issues not related to code in any JIRA project

Development
#1

Hi devs,

I’ve started JIRA rules for architecture/design-only issue but Thomas raised the following point when referring to the XWiki Platform JIRA project:

It’s the first time I see a jira issue closed as fixed with no change associated to it.

It’s true that there have not been many JIRA issues for the XWiki Platform JIRA project that were not code-related in the past (found a few but not many).

For me it’s always been the case that we allow creating jira issues that are not code-related, in any jira project and in this case “Affects” is the latest released version for that project (or LTS) and “Fix Version” means fixing the issue before the mentioned release version.

I’m thus sending this proposal to make sure we agree about this, collectively.

FTR, we’ve started a few weeks ago to create UI design-only issues in XWiki Platform for Thiago and Adina. For ex: Loading... . If we don’t agree about this proposal we’ll need to do something about these issues or stop using this strategy.

I think it makes it easier to organize whatever is needed for the development of a given version by putting it as JIRA issues (of type “Task” and with “Development Issue Only” component, see the other proposal). Also makes it easier for the roadmap page and for follow-up.

Note that I’m not suggesting that we force ourselves to materialize any task as JIRA issues but only that we allow doing it.

Let me know what you think.

Thanks

JIRA rules for architecture/design-only issue
JIRA rules for architecture/design-only issue
#2

I’m really not a fan of reusing jira issues for things that don’t really actually end up in any way in the version indicated in the jira issue. It’s very misleading.

I don’t really see why we need jira issues to follow a design task, to me that’s what https://design.xwiki.org is for.

#3

It’s definitely not what design.xwiki.org is for! That wiki is not a roadmap tool… The need here is to define the list of tasks to do in a given timeframe/for a given version, and the follow up on that.

Regarding the release notes, we already have release notes separated from the list of jira issues and I don’t see what real problems it would cause.

#4

So I’m not strongly against using JIRA issues for things not related to code, now as I mentioned in JIRA rules for architecture/design-only issue - #10 by surli IMO we should have a clear way of viewing that those tickets are not related to code so that there’s no wtf effect if we see a close ticket and don’t find related commits.

Ideally I’d probably go for a new issue type so that we use same things in old project: components are project-specific so it makes it less consistent.

#5

+1 to allow for the creation of tasks that are not directly leading to commits (though tasks should lead to tangible results somewhere of course).
Also, +1 for making it clear which tasks are code related and which are not. Task type + some new label sounds enough to me, for instance label “Design Issue Only”.

#6

You don’t need a complex label name, design or ui (which we already have) would be good enough. For the component we already have Development Issue Only (see discussion at JIRA rules for architecture/design-only issue - #11 by vmassol ).

Thx