[Jenkins-infra] Proposal: Add optional "Released as" and "Stage Release" states to JIRA

Oleg Nenashev o.v.nenashev at gmail.com
Wed Aug 16 06:28:54 UTC 2017 

Seems the thread now has separate heads in the DEV and INFRA lists. I
should not have added both lists.

Thread in dev list is here:
https://groups.google.com/forum/#!topic/jenkinsci-dev/wzc4VLplHvs


2017-08-16 8:26 GMT+02:00 Oleg Nenashev <o.v.nenashev at gmail.com>:

> Hi Michael,
>
> It's a most unusual way of using JIRA. You can hold a knife by the blade
>> and use it as a hammer, sure, it will work. Sort of. Jira is flexible but
>> to a point. It was designed with this exact use case in mind, yet not in
>> this way. Imagine someone using software you built in a awkward way when
>> there was a much more natural way to use it...
>
>
> Yes, in Jenkins project we use JIRA in a quite strange way. It has not
> only disadvantages, but also has some advantages:
>
>    - JENKINS project applies to all components, hence users can submit
>    issues for triage to multiple components
>    - When a fix is required in multiple components, you can still have a
>    single issue
>
> *This proposa*l is not about the JIRA rework. It's a proposal about a *particular
> change* in the *existing process*. As I said to James Dumay above,
> concerns about the project structure can and should be discussed in another
> thread.
>
> BR, Oleg
>
>
>
>
> 2017-08-15 23:06 GMT+02:00 Michael Neale <michael.neale at gmail.com>:
>
>> It's a most unusual way of using JIRA. You can hold a knife by the blade
>> and use it as a hammer, sure, it will work. Sort of.
>>
>> Jira is flexible but to a point. It was designed with this exact use case
>> in mind, yet not in this way.
>>
>> Imagine someone using software you built in a awkward way when there was
>> a much more natural way to use it...
>>
>> On Tue, 15 Aug 2017 at 8:03 pm, Oleg Nenashev <o.v.nenashev at gmail.com>
>> wrote:
>>
>>> Hi James,
>>>
>>>
>>>> I am merely giving a reasonable response to the proposal, which I think
>>>> is fair, given I am the component leader on projects cited as benefiting
>>>> from this change.
>>>>
>>>
>>> Well, in your previous response you gave feedback about the existing
>>> process. Correct me if I am wrong.
>>> In the new feedback I see the response to the proposal, hence please
>>> find my response below:
>>>
>>>
>>> The tool we use already makes provisions for the problems outlined.
>>>> Additional statuses will not add clarity as this is now how JIRA projects
>>>> are usually used which runs contrary to user expectations of this widely
>>>> used tool.
>>>>
>>>
>>> It may be contrary for a manager (sorry, I really do not understand
>>> what's your point in this sentense), but IMHO it's a straighforward
>>> improvement for Jenkins users.
>>>
>>>    - Before: Users were seeing changes as "Resolved", but it was not a
>>>    guarantee that the change is acually delivered
>>>    - After (in core components): When the change is Resolved, the
>>>    version is available for download
>>>
>>> As we discussed with Ulli above, as a plugin maintainer you can stick to
>>> the current flow in your components.
>>>
>>> Secondly, as someone who spends much time in JIRA who would benefit from
>>>> tracking such information, the proposed fields cannot be used in
>>>> conjunction with JIRA reporting functionality such as Created vs Resolved
>>>> charts, which are very beneficial to those who manage triaging and tracking
>>>> the health of sub-projects.
>>>
>>>
>>> They can be used. For such purpose there are meta-statuses like "Open".
>>> If dashboards depend on raw status (e.g. "In Progress"), they may need an
>>> update of course. If the proposal gets approved, I will make sure it's
>>> announced accordingly.
>>> We have also added the "In Review" status according to your request
>>> <https://groups.google.com/forum/#%21searchin/jenkinsci-dev/%22In$20Review%22%7Csort:relevance/jenkinsci-dev/mEqAQmPJ5xM/ezVBBB6tAwAJ>
>>> one year ago, and one could grumble about the same impact on reporting. How
>>> does this request differ from your one in terms of reporting?
>>>
>>> BR, Oleg
>>>
>>>
>>>
>>> 2017-08-15 10:52 GMT+02:00 James Dumay <jdumay at cloudbees.com>:
>>>
>>>> I am merely giving a reasonable response to the proposal, which I think
>>>> is fair, given I am the component leader on projects cited as benefiting
>>>> from this change.
>>>>
>>>> The tool we use already makes provisions for the problems outlined.
>>>> Additional statuses will not add clarity as this is now how JIRA projects
>>>> are usually used which runs contrary to user expectations of this widely
>>>> used tool.
>>>>
>>>> Secondly, as someone who spends much time in JIRA who would benefit
>>>> from tracking such information, the proposed fields cannot be used in
>>>> conjunction with JIRA reporting functionality such as Created vs Resolved
>>>> charts, which are very beneficial to those who manage triaging and tracking
>>>> the health of sub-projects.
>>>>
>>>>
>>>> On Tuesday, August 15, 2017 at 6:34:20 PM UTC+10, Oleg Nenashev wrote:
>>>>>
>>>>> Hi James,
>>>>>
>>>>>
>>>>>> -1 JIRA was designed to have a project per software lifecycle. The
>>>>>> fact that we have 1000 plugins in the same JENKINS project breaks all the
>>>>>> nice things about JIRA, such as the Fixed For field and Versions, which was
>>>>>> designed for this very problem.
>>>>>
>>>>>
>>>>> I know you do not like the current JIRA structure, but I do not see
>>>>> how your comment is related to the proposal. I want to improve the current
>>>>> project structure, not to create a new one.
>>>>>
>>>>> If you want to change the JIRA design and to decouple plugins to
>>>>> projects, feel free to do it in a separate thread
>>>>>
>>>>> BR, Oleg
>>>>>
>>>>>
>>>>> 2017-08-15 9:19 GMT+02:00 James Dumay <jdu... at cloudbees.com>:
>>>>>
>>>>>> -1 JIRA was designed to have a project per software lifecycle. The
>>>>>> fact that we have 1000 plugins in the same JENKINS project breaks all the
>>>>>> nice things about JIRA, such as the Fixed For field and Versions, which was
>>>>>> designed for this very problem.
>>>>>>
>>>>>>
>>>>>> On Monday, August 14, 2017 at 7:45:08 PM UTC+10, Oleg Nenashev wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> As a Jenkins user and contributor, I sometimes have difficulties
>>>>>>> when I need to understand in which release the fix is available. GitHub
>>>>>>> commit links from the bot help much, but it requires extra time to navigate
>>>>>>> across commits and UI. In Jenkins core, Remoting and my plugins I would
>>>>>>> like to make it more explicit:
>>>>>>>
>>>>>>> I propose to...
>>>>>>>
>>>>>>>    1. Modify workflow in the JENKINS project:
>>>>>>>       - Add a "Stage Release" state (or whatever similar name)
>>>>>>>       - Instead of "In Progress" => "Resolved", contributors can
>>>>>>>       move integrated fixed into the "Stage Release" state.
>>>>>>>       - It may be helpful for components which do not release the
>>>>>>>       integrated fixes immediately (e.g. Core, its modules, Remoting, Stapler,
>>>>>>>       Blue Ocean, other plugins)
>>>>>>>       2. Add an optional "Released As" field to JIRA (type=String)
>>>>>>>       - When a contributor moves the issue to "Stage release",
>>>>>>>       "Resolved" or "Closed" state, an optional field appears in the dialog
>>>>>>>       - If the field is non-empty, it will appear in the ticket
>>>>>>>       header, hence users won't need to look into comments and commit histories
>>>>>>>
>>>>>>> This proposal could improve contributor and user experience, but the
>>>>>>> proposed change is opt-in.
>>>>>>>
>>>>>>> It does not make the field/state mandatory, hence the existing flows
>>>>>>> won't be affected if the maintainers do not want to spend time on JIRA
>>>>>>> updates.
>>>>>>>
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>> Oleg
>>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to a topic in
>>>>>> the Google Groups "Jenkins Developers" group.
>>>>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>>>>> pic/jenkinsci-dev/wzc4VLplHvs/unsubscribe.
>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>> jenkinsci-de... at googlegroups.com.
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/a835c953-65a
>>>>>> 4-44a7-b1f0-55384d0498e9%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/a835c953-65a4-44a7-b1f0-55384d0498e9%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>> --
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "Jenkins Developers" group.
>>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>>> pic/jenkinsci-dev/wzc4VLplHvs/unsubscribe.
>>>>
>>> To unsubscribe from this group and all its topics, send an email to
>>>> jenkinsci-dev+unsubscribe at googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/jenkinsci-dev/61e48fa9-5b59-4ee8-8e2c-227376c251b7%40goo
>>>> glegroups.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/61e48fa9-5b59-4ee8-8e2c-227376c251b7%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>
>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jenkins-ci.org/pipermail/jenkins-infra/attachments/20170816/a9d834ed/attachment-0001.html>

More information about the Jenkins-infra mailing list