I concur. Not fussy whether we implement triage needed as tag or an extra state, it's the thought that counts :)
It might be more consistent to have it as a state and potentially make some statistics easier, but that is pure conjecture on my part. Best, Sönke On Mon, Mar 11, 2019 at 3:27 PM Lars Francke <lars.fran...@gmail.com> wrote: > > Hi, > > this is more complicated than I thought initially :) > > I agree that fewer states is better for understanding and maintenance. We > should definitely have a "state diagram" of our flow on the Wiki. We > currently have five states. > > * I also like to have the state "Patch available" or more generally "Review > needed" (noting that Kenneth understands review = triage). I don't think > that Github PR is enough when people submit simple patches > > * I also like to distinguish triaged from untriaged (accepted vs. > unaccepted) issues, whether tag or state based I don't know. Tag is easy to > forget, state is implicit so I lean towards that but Kenneth was against it > I believe? > > * I'm against a separation of CLOSED and RESOLVED > > * I don't think we need a REOPENED state. I've never really seen the point, > when we reopen we can just go back to the normal "open" state. > > I could live with a workflow like this: > TRIAGE NEEDED -> OPEN -> PATCH AVAILABLE -> CLOSED > > That'd be four states so even one fewer than we have today. > > Cheers, > Lars > > > On Thu, Mar 7, 2019 at 8:39 AM Dmitriy Pavlov <dpav...@apache.org> wrote: > > > Hi, > > > > IMO we need some sort of Patch Available/Review Needed state because the > > presence of PR does not imply of its state and quality. > > > > Open->...validate...->Open(triaged)->... actual work..->Patch > > Available->...review... ->Closed. > > > > Patch Available indicates patch is there and it is ready for review, it is > > in a state when it could be merged. > > > > What if review fails, then we can use backward transition Patch > > Available->Open (cancel patch). > > What if PR there has conflicts or outdated. What if contributor became > > unresponsive and don't updater his or her PR. > > > > PA state or Review Needed state is needed for a number of cases. > > > > Sincerely, > > Dmitriy Pavlov? > > > > чт, 7 мар. 2019 г. в 07:34, Kenneth Knowles <k...@apache.org>: > > > > > On Wed, Mar 6, 2019 at 3:19 PM Sönke Liebau > > > <soenke.lie...@opencore.com.invalid> wrote: > > > > > > > Hey all, > > > > > > > > just to pick this up again, we have a suggestion for a fairly simple > > > > workflow by Kenn, which I'd like to briefly summarize to ensure that I > > > > understood everything correctly :) > > > > > > > > The workflow will have three states: > > > > Open > > > > Review Needed > > > > Closed > > > > > > > > Additionally, we have a tag "triaged" that is applied to Open tickets > > > > when it is decided that they have merit. If during review of an open > > > > ticket it is decided that this is not necessary/not a bug/... then it > > > > will be closed instead of receiving the triaged tag. > > > > > > > > So any work should be done on tickets in the state open with the tag > > > > "triaged". Once a pull request or a patch is submitted the ticket > > > > moves to "review needed". Based on the outcome of the review it then > > > > either moves back to open or to closed when something is committed. > > > > > > > > Did I get that right, Kenn? > > > > > > > > > > Almost :-) > > > > > > - What I meant by "Review Needed" was actually "Triage Needed". This is > > > the initial state of all tickets, because users may not know where to put > > > them or who to ping. > > > - Once it is triaged, you move to "Open". > > > - When done, goes to "Closed" and you can make a comment about why, or > > > Jira has some statuses. > > > > > > The workaround in Beam right now is: > > > > > > - Initial state is "Open", and we subscribe to a "does not have > > `triaged` > > > tag" saved search. (simulates "Needs Triage" state) > > > - Once it is looked at, moved to the right component, has right > > priority, > > > pinged right people, add `triaged` tag > > > - Close as usual > > > > > > So I just watch for all non-triaged Jiras and all open pull requests in > > LRU > > > order. > > > > > > We really don't need separate state for noting there is a PR available. > > If > > > you put "[TRAINING-12345] this fixes a thing" in the pull request title, > > it > > > links automatically with the named Jira if set up the way most projects > > > are. You can probably even do an advance Jira search for these if you > > > prefer to work in Jira instead of GitHub to find open PRs. > > > > > > Kenn > > > > > > > > > > Best regards, > > > > Sönke > > > > > > > > > > > > On Mon, Mar 4, 2019 at 10:50 PM Sharan Foga <sha...@apache.org> wrote: > > > > > > > > > > > > > > > > > > > > On 2019/03/04 17:47:33, Dmitriy Pavlov <dpav...@apache.org> wrote: > > > > > > Hi > > > > > > = JIRA workflow > > > > > > I've checked JIRA admin interface and there is no option to edit > > > Issue > > > > > > Workflow. So I guess only Infra can edit Workflows. > > > > > > > > > > Hi Dimitry > > > > > > > > > > Yes - I think someone else has shown that we need to request the > > change > > > > of flow through Infra, so once we agree then we can create the request. > > > > > > > > > > > > > > > > > AFAIK Apache JIRA has a number of pre-defined workflows, and > > probably > > > > we > > > > > > need somehow to point to some option. > > > > > > > > > > > > = Wiki pages > > > > > > As for the wiki, Confluence has a number of permissions to be > > defined > > > > for > > > > > > each user, and I'm not sure Apache wiki has convenient groups in > > it. > > > > > > > > > > There is a default anonymous user with view access only. I think this > > > is > > > > a safeguard against spam. As far as I know, I didn't think setting the > > > user > > > > permissions were a problem and I've generally added people once they > > have > > > > requested access.( BTW I've added you to the wiki with edit access.) > > > > > > > > > > Thanks > > > > > Sharan > > > > > > > > > > > > > > > > > (P)PMCs, please grant me admin access to the wiki and I could > > > > setup/edit > > > > > > user permissions. username=dpavlov > > > > > > > > > > > > Sincerely, > > > > > > Dmitriy Pavlov > > > > > > > > > > > > пн, 4 мар. 2019 г. в 20:27, Mirko Kämpf <mirko.kae...@gmail.com>: > > > > > > > > > > > > > Hi Sönke, > > > > > > > > > > > > > > I registered and logged in to the Wiki (for adding the report > > > > template) > > > > > > > but I can't find the page editor. > > > > > > > Are there any permission issues which give me read-only access? > > > > > > > > > > > > > > Best regards, > > > > > > > Mirko > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am Mo., 4. März 2019 um 12:04 Uhr schrieb Sönke Liebau > > > > > > > <soenke.lie...@opencore.com.invalid>: > > > > > > > > > > > > > > > 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 < > > > > mirko.kae...@gmail.com> > > > > > > > > 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 > > > > > > > > > <soenke.lie...@opencore.com.invalid>: > > > > > > > > > > > > > > > > > > > Bumping to see if really no one has an opinion on this :) > > > > > > > > > > > > > > > > > > > > On Wed, Feb 27, 2019 at 3:53 PM Sönke Liebau < > > > > > > > > soenke.lie...@opencore.com> > > > > > > > > > > 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 < > > > > > > > lars.fran...@gmail.com > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > (Mailing list swallows attachments Sönke, can you host > > > them > > > > > > > > > > externally?) > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 27, 2019 at 3:33 PM Sönke Liebau > > > > > > > > > > > > <soenke.lie...@opencore.com.invalid> 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 > > > < > > https://maps.google.com/?q=%3E+%3E+%3E+%3E+%3E+%3E+%3E+%3E+%22patch+available%22+to+symbolize&entry=gmail&source=g > > > > > > 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 evalua > > > < > > https://maps.google.com/?q=%3E+%3E+%3E+%3E+%3E+%3E+%3E+%3E+someone+look+at+it+and+evalua&entry=gmail&source=g > > >te > > > 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 t > > > < > > https://maps.google.com/?q=%3E+%3E+after+looking+at+them,+but+that+misses+t&entry=gmail&source=g > > >he > > > 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 ab > > > > > > > < > > > > > > > > > https://maps.google.com/?q=%3E+workflow+closely+resembles+what+I+wrote+ab&entry=gmail&source=g > > > > >ove > > > > > > > (see > > > > > > > > > > > > > 2_mesos_workflow.png) > > > > > > > > > > > > > > > > > > > > > > > > > > Looking through some other projects the "patch > > > > available-reop > > > > > > > < > > > > > > > > > https://maps.google.com/?q=some+other+projects+the+%22patch+available-reop&entry=gmail&source=g > > > > > > > > > > > > en > > > > > > > > > > > > > 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 <+49%20179%207940878> > > > <+49%20179%207940878> > > > > > > > > > > > OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 > > > Wedel - > > > > > > > Germany > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Sönke Liebau > > > > > > > > > > Partner > > > > > > > > > > Tel. +49 179 7940878 <+49%20179%207940878> > > > <+49%20179%207940878> > > > > > > > > > > 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 <+49%20179%207940878> > > <+49%20179%207940878> > > > > > > > > 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 <+49%20179%207940878> > > > > 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
