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 <jdu...@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...@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...@googlegroups.com. >>> 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 > jenkinsci-dev+unsubscr...@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. > -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. 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.
