TBH I think fewer states gives a less noisy signal and has lower housekeeping cost. I like three fundamental states: Needs Review -> Open -> Closed
- Needs Review is really helpful, so that you can actually process all incoming Jira. You can also do it as a "triaged" tag that you add after review and remove when it needs re-review. - Open vs Accepted/In Progress doesn't add much, and folks tend to not use it. - Patch Available is not needed. GitHub Jira integration automatically links a PR with the issue. - Resolved vs Closed makes sense but almost no one seems to use it. It is most valuable in a contractor/client or customer service relationship where the customer owns saying whether they are satisfied. Infra has to make such changes. For example https://issues.apache.org/jira/browse/INFRA-17628 Kenn On Mon, Mar 4, 2019 at 3:04 AM Sönke Liebau <[email protected]> wrote: > Thanks Mirko! > > For me there are three main questions that we should consider around > the workflow. If I am missing something, please shout out, I am by no > means an expert on this! > > 1. Do we want an "accepted" state that means someone looked at this > ticket and it has merit and is not just a user question that is better > placed on the mailing list/far too broad/... ? > 2. Do we want a "reviewable" state? > 3. Do we want an explicit "closed" state? The current workflow has > "resolved" which means something has been committed to address this > issue and now the original reporter should check whether the issue > itself has been fixed and transition the issue to either "closed" or > "reopened". > > I do like the idea of 1, as it gives us a better option of keeping > track of whether or not a ticket has been triaged already. If you have > some time on your hands and want to fix an issue picking from > "accepted" is easier than potentially sifting through 10 "open" ones > until you find an actionable one. > > I think 2 is really useful and we should definitely have that. > > 3 I'm on the fence about, personally I think if the commit doesn't > meet what the ticket was about then this should have been addressed > during review. I think this workflow is more suited for a > customer-service provider situation where the customer needs to sign > off on a solution. > > Any thoughts? > > Best regards, > Sönke > > > On Mon, Mar 4, 2019 at 11:38 AM Mirko Kämpf <[email protected]> > wrote: > > > > Hello Sönke, > > > > I like the proposal to use a workflow with an explicit state for > > "reviewable" issues. > > Unfortunately, I do not know how to set it up or how to request this > change. > > > > +1 ---> Mesos Workflow: https://imgur.com/a/6zWFK4e > > > > > > > > Am Mo., 4. März 2019 um 11:33 Uhr schrieb Sönke Liebau > > <[email protected]>: > > > > > Bumping to see if really no one has an opinion on this :) > > > > > > On Wed, Feb 27, 2019 at 3:53 PM Sönke Liebau < > [email protected]> > > > wrote: > > > > > > > > Ah, apologies, wasn't aware of that. > > > > > > > > Default Workflow: https://imgur.com/a/EfKcOfL > > > > Mesos Workflow: https://imgur.com/a/6zWFK4e > > > > > > > > Best regards, > > > > Sönke > > > > > > > > On Wed, Feb 27, 2019 at 3:48 PM Lars Francke <[email protected] > > > > > wrote: > > > > > > > > > > (Mailing list swallows attachments Sönke, can you host them > > > externally?) > > > > > > > > > > On Wed, Feb 27, 2019 at 3:33 PM Sönke Liebau > > > > > <[email protected]> wrote: > > > > > > > > > > > Our Jira currently is still operating with the default workflow > (see > > > > > > 1_default_workflow.png) which is fairly basic. > > > > > > > > > > > > Personally I'd like something along the lines of "reviewable" or > > > > > > "patch available" to symbolize that this is waiting for someone > to > > > > > > take a look at. > > > > > > Also, it might be an option to triage issues up front, i.e. have > > > > > > someone look at it and evaluate whether this actually is an > issue or > > > > > > not appropriate. Granted, this can also be covered by closing > issues > > > > > > after looking at them, but that misses the explicit information > > > > > > whether someone already looked at it, if it is still open. > > > > > > > > > > > > Looking through workflows that other projects adopted, the Mesos > > > > > > workflow closely resembles what I wrote above (see > > > > > > 2_mesos_workflow.png) > > > > > > > > > > > > Looking through some other projects the "patch available-reopen > > > > > > possible" workflow seems to be fairly common. A lot of > variations > > > > > > just differ by the way they name the "patch available" state. > > > > > > > > > > > > Any thoughts on the route we want to take? > > > > > > > > > > > > Best regards, > > > > > > Sönke > > > > > > > > > > > > > > > > > > > > > > -- > > > > Sönke Liebau > > > > Partner > > > > Tel. +49 179 7940878 > > > > OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany > > > > > > > > > > > > -- > > > Sönke Liebau > > > Partner > > > Tel. +49 179 7940878 > > > OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany > > > > > > > > > -- > > > > Dr. rer. nat. Mirko Kämpf > > Müchelner Str. 23 > > 06259 Frankleben > > > > -- > Sönke Liebau > Partner > Tel. +49 179 7940878 > OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany >
