Clarification: I am in favor of accepted / not accepted as a state. Beam is just currently using a tag because we are blocked on the issue. In the shared Jira install, it is also bad that "triaged" "triage" "Triaged" are all separate tags.
Kenn On Mon, Mar 11, 2019 at 8:05 AM Sönke Liebau <soenke.lie...@opencore.com.invalid> wrote: > 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 >
