JIRA rules for architecture/design-only issue

[vmassol]

Hi devs,

In the context of Cristal Manuel and I discussed a few JIRA rule and we thought it would be nice to discuss them for XWiki too so that we have the same dev practices everywhere:

• Design-only issue (no code change) should use a “Task” issue type in JIRA and the condition to close these issues is that a proposal has been made on the forum and an up to date design page on design.xwiki.org exists. When closing the “documentation” field must point to an updated design page on design.xwiki.org
  • The rationale is that we cannot wait till the discussion is over before closing the issue as this can take forever and thus there’s no guarantee the issue can be closed for the release it’s meant to be finished for.

WDYT?

Thanks

[tmortagne]

Are you talking about issues located in Loading... project ?

[vmassol]

No, I’m referring to any design issue for any jira project. For example:

• Loading...
• Loading...

Note that the examples are about UI design but this discussion is more generic and meant for any design or architecture topics (ie issues that won’t produce code).

[tmortagne]

An issue in Loading... which is only about design does not make much sense to me since it’s impossible to indicate a fix version when you close it (it would not really correspond to anything).

[vmassol]

@tmortagne

An issue in Loading… which is only about design does not make much sense to me since it’s impossible to indicate a fix version when you close it (it would not really correspond to anything).

Everything we do is based on development timeframes. A fix version of, say, 16.1.0 means everything done during the development timeframe of 16.1.0. Including designs. We’ve always done this so nothing new here. What’s new is the rule to close design issues.

Thx

[tmortagne]

@vmassol

We’ve always done this so nothing new here.

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

[vmassol]

@tmortagne

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

I’ve opened Allow creating JIRA issues not related to code in any JIRA project

Thanks

[surli]

@vmassol

Design-only issue (no code change) should use a “Task” issue type in JIRA

Here you’re talking about Design issue only but when checking the tickets you linked it’s Development issue only. Personally I’m not in favor or using Task + Dev issue only, as we already use that for dependency upgrades that only concerns test, see: Loading... so it’s mixing very different stuff IMO.

I feel like it would be better to have a new issue type for this: so that we could reuse the components that the design targets.

[vmassol]

@surli

Here you’re talking about Design issue only but when checking the tickets you linked it’s Development issue only.

I’m not proposing to add a new component. We already have one for all tasks that are used for development and are not supposed to be seen by our users in the RN and it’s Development Issues Only.

@surli

Personally I’m not in favor or using Task + Dev issue only, as we already use that for dependency upgrades that only concerns test, see: Loading… so it’s mixing very different stuff IMO.

It’s exactly the same thing, and what you say is not accurate: Development Issue Only is NOT for dep upgrades for tests! Its definition is “for all tasks that are used for development and are not supposed to be seen by our users in the RN”. This includes a lot of things: dep upgrades for tests, build improvements, flickering issues, etc.

Thx

[surli]

@vmassol

@surli

Personally I’m not in favor or using Task + Dev issue only, as we already use that for dependency upgrades that only concerns test, see: Loading… so it’s mixing very different stuff IMO.

It’s exactly the same thing, and what you say is not accurate: Development Issue Only is NOT for dep upgrades for tests! Its definition is “for all tasks that are used for development and are not supposed to be seen by our users in the RN”. This includes a lot of things: dep upgrades for tests, build improvements, flickering issues, etc.

I didn’t mean that it was only used for that, was just an example. But yes that’s exactly my point: it’s used for lots of things, and I don’t think it’s good to mix up things that will be pushed in the code and things that are related to artifacts not pushed in code (in relation with what’s discussed in Allow creating JIRA issues not related to code in any JIRA project)

[vmassol]

Again the reason for creating the “Development Issue Only” was exactly for this: to have a component for issues that are related to the development of XWiki but that shouldn’t be seen in the RN. Design issues fall exactly in this category, and I really don’t see what’s the problem of having a single category for this topic.

We should always do YAGNI until proven that we need something different. In short, do simple things (adding a new issue type is too complex since there’s no immediate need). I don’t see a single problem that would be caused by using the existing Development Issue Only component. Additionally if, for some reasons, we want to list only UI Designs issues (and I don’t think we have that need), we already have labels for issues related to UI: ui.

Last, issue types must not be about a domain. They’re supposed to be applicable to all domains, which would’t be the case. We had this discussion for Security BTW. If you want to quality an issue, labels are there for that.

Thx