Thanks for the clarification. In which way are you blocked? I don't quite get that yet.
Open question for me are: Accepted vs. Triaged? I'm in favor of Accepted, it's the easier word (for non natives at least) Do we want a state "In progress"? (Asking because the Mesos flow has that which was Senses original suggestion) I'm against it as it's information that can go stale. Attaching a patch/PR or commenting is enough in my opinion. Cheers, Lars On Mon, Mar 11, 2019, 18:23 Kenneth Knowles <k...@apache.org> wrote: > 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 > > >
