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.
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).
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.
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.
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.
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)
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.
So, to sum up and to try to progress on this topic:
JIRA is a tool to list tasks needed for a given release. It’s not supposed to be related to source code changes only. JIRA has a roadmap feature to list all issues needed or fixed for a given roadmap. Thus it’s normal and expected to mix issues with different outcomes (code outcome, doc outcome, design.xwiki.org outcome, etc).
We already have a component named “Development issues only” used for issues that are for development and not interesting for end users (ie that should not appear in our release notes)
JIRA offers a plugin to link jira issues with code commits (and we use it). There’s even the ability to use JQL to list issues with code commits or not in case we want to query that.
It’s not because an issue doesn’t lead to a commit that it cannot have a fix version. Any issue needs to be organized and target a given release. That’s what a roadmap is for.
I hope that this addresses the comments from @tmortagne and @surli in this thread.
In view of this, could we come up with an agreement:
A) about Allow creating JIRA issues not related to code in any JIRA project (please reply there)
B) that we’re ok to use the existing Development issue only component + existing labels, even for development issues that don’t need a commit in the source repo? And to use that for issues for design work.
-0 on this: I’m still not a big fan of reusing dev issue only component, and using the label ui sounds like it could bring false positive. If we want to discriminate the issues related to a real commit in the code it will be a pain to actually filter them. Now if we have more specific labels for those tickets that don’t bring code why not.
“Dev issue only” component is already about any issue needed during development (“for all tasks that are used for development and are not supposed to be seen by our users in the RN”). Maybe the ambiguity is development vs coding? Coding is about code changes but Development in software engineering is not about code only, it’s about design, tests (can be manual), code, quality checks, etc. See Programming VS Coding VS Development – What's the Difference?
Do we have a need/use case for this?
Knowing that if we need to separate issues that have commits from others, we know how to do it (e.g. component = "Development Issues only" and issue.property[development].commits > 0).
Nothing prevent us to add more labels, like a design one in addition to ui for UI design for example. It’s just a bit more constraining when creating the issues (and there’s more risks to forget it), and I don’t see the need ATM, but I’m not against it at all.