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

Tue Aug 15 21:06:20 UTC 2017

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/20170815/6722d51e/attachment-0001.html>