[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:26:02 UTC 2017


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/
>>>>> topic/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-65a4-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/
>>> topic/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/
>>> msgid/jenkinsci-dev/61e48fa9-5b59-4ee8-8e2c-227376c251b7%
>>> 40googlegroups.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/7cc402c7/attachment.html>


More information about the Jenkins-infra mailing list