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 > > >
