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 <[email protected]>: > 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 <[email protected]>: >> >>> -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 >>> [email protected]. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/jenkinsci-dev/a835c953-65a4-44a7-b1f0-55384d0498e9%40goo >>> glegroups.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 > [email protected]. > 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. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLARfzKV-PSZL1kKEUJDUO%2BiYiD%2BL36SUnL_mQJ9Fi8vPA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
