Hi Robert, If I understood the decision correctly, we also need to ask Infra to make everybody an assignable user, right? Or do we want to add a new permission class "Assignable User" such that everyone still needs to ask for the right Jira permissions?
Fabian Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <twal...@apache.org >: > Hi Robert, > > thanks for taking care of this. +1 to your suggested steps. > > Regards, > Timo > > > Am 30.04.19 um 10:42 schrieb Robert Metzger: > > @Stephan: I agree. Auto-closing PRs is quite aggressive. > > I will only do that for PRs without JIRA ID or "[hotfix]" in the title. > > We can always revisit this at a later stage. > > > > > > I'm proposing the following steps: > > > > 1. I update the contribution guide > > 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with > > unassigned JIRAs > > 3. We ask Infra to change the permissions of our JIRA so that: > > a) only committers can assign users to tickets > > b) contributors can't assign users to tickets > > 4. We remove all existing contributors > > > > > > > > > > On Wed, Apr 24, 2019 at 11:17 AM vino yang <yanghua1...@gmail.com> > wrote: > > > >> also +1 for option 2. > >> > >> I think auto-close a PR sometimes a bit impertinency. > >> The reasons just like Stephan mentioned. > >> > >> Stephan Ewen <se...@apache.org> 于2019年4月24日周三 下午4:08写道： > >> > >>> About auto-closing PRs from unassigned issues, consider the following > >> case > >>> that has happened quite a bit. > >>> > >>> - a user reports a small bug and immediately wants to provide a fix > for > >>> it > >>> - it makes sense to not stall the user for a few days until a > committer > >>> assigned the issue > >>> - not auto-closing the PR would at least allow the user to provide > >> their > >>> patch. > >>> > >>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen <se...@apache.org> > wrote: > >>> > >>>> +1 for option #2 > >>>> > >>>> Seems to me that this does not contradict option #1, it only extends > >> this > >>>> a bit. I think there is a good case for that, to help frequent > >>> contributors > >>>> on a way to committership. > >>>> > >>>> @Konstantin: Trivial fixes (typos, docs, javadocs, ...) should still > be > >>>> possible as "hotfixes". > >>>> > >>>> On Mon, Apr 15, 2019 at 3:14 PM Timo Walther <twal...@apache.org> > >> wrote: > >>>>> I think this really depends on the contribution. > >>>>> > >>>>> Sometimes "triviality" means that people just want to fix a typo in > >> some > >>>>> docs. For this, a hotfix PR is sufficient and does not need a JIRA > >>> issue. > >>>>> However, sometimes "triviality" is only trivial at first glance but > >>>>> introduces side effects. In any case, any contribution needs to be > >>>>> reviewed and merged by a committer so follow-up responses and > >> follow-up > >>>>> work might always be required. But you are right, committers need to > >>>>> respond quicker in any case. > >>>>> > >>>>> Timo > >>>>> > >>>>> > >>>>> Am 15.04.19 um 14:54 schrieb Konstantin Knauf: > >>>>>> Hi everyone, > >>>>>> > >>>>>> just my two cents: as a non-committer I appreciate a lightweight, > >>>>>> frictionless process for trivial changes or small fixes without the > >>>>> need to > >>>>>> approach a committer beforehand. If it takes 5 days, so that I can > >>> start > >>>>>> with a triviality, I might not bother in the first place. So, in > >> order > >>>>> for > >>>>>> this not to backfire by making the community more exclusive, we need > >>>>> more > >>>>>> timely responses & follow ups by committers after the change to the > >>>>>> workflow. Having said that, I am slightly leaning towards Andrey's > >>>>>> interpretation of option 2. > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> Konstantin > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Mon, Apr 15, 2019 at 1:39 PM Andrey Zagrebin < > >> and...@ververica.com > >>>>>> wrote: > >>>>>> > >>>>>>> @Robert thanks for pointing out and sorry for confusion. The > >> correct > >>>>> text: > >>>>>>> +1 for option 1. > >>>>>>> > >>>>>>> I also do not mind option 2, after 1-2 contributions, any > >> contributor > >>>>> could > >>>>>>> just ask the committer (who merged those contributions) about > >>>>> contributor > >>>>>>> permissions. > >>>>>>> > >>>>>>> Best, > >>>>>>> Andrey > >>>>>>> > >>>>>>> On Mon, Apr 15, 2019 at 10:34 AM Feng LI <nemoking...@gmail.com> > >>>>> wrote: > >>>>>>>> Hello there, > >>>>>>>> > >>>>>>>> New to the community. Just thought you might want some inputs from > >>> new > >>>>>>>> comers too. > >>>>>>>> > >>>>>>>> I prefer option 2, where you need to prove the ability and > >>> commitment > >>>>>>> with > >>>>>>>> commits before contributor permission is assigned. > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> Feng > >>>>>>>> > >>>>>>>> Le lun. 15 avr. 2019 à 09:17, Robert Metzger <rmetz...@apache.org > >>> a > >>>>>>>> écrit : > >>>>>>>> > >>>>>>>>> @Andrey: You mention "option 2" two times, I guess one of the two > >>>>> uses > >>>>>>> of > >>>>>>>>> "option 2" contains a typo? > >>>>>>>>> > >>>>>>>>> On Wed, Apr 10, 2019 at 10:33 AM Andrey Zagrebin < > >>>>> and...@ververica.com > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>> +1 for option 2. > >>>>>>>>>> > >>>>>>>>>> I also do not mind option 2, after 1-2 contributions, any > >>>>> contributor > >>>>>>>>> could > >>>>>>>>>> just ask the committer (who merged those contributions) about > >>>>>>>> contributor > >>>>>>>>>> permissions. > >>>>>>>>>> > >>>>>>>>>> Best, > >>>>>>>>>> Andrey > >>>>>>>>>> > >>>>>>>>>> On Wed, Apr 10, 2019 at 3:58 AM Robert Metzger < > >>> rmetz...@apache.org > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> I'm +1 on option 1. > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther < > >> twal...@apache.org> > >>>>>>>>> wrote: > >>>>>>>>>>>> Hi everyone, > >>>>>>>>>>>> > >>>>>>>>>>>> I'd like to bring up this discussion thread again. In > >> summary, I > >>>>>>>>> think > >>>>>>>>>>>> we all agreed on improving the JIRA workflow to move > >>>>>>>> design/consensus > >>>>>>>>>>>> discussions from PRs to the issues first, before implementing > >>>>>>> them. > >>>>>>>>>>>> Two options have been proposed: > >>>>>>>>>>>> 1. Only committers can assign people to issues. PRs of > >>> unassigned > >>>>>>>>>> issues > >>>>>>>>>>>> are closed automatically. > >>>>>>>>>>>> 2. Committers upgrade assignable users to contributors as an > >>>>>>>>>>>> intermediate step towards committership. > >>>>>>>>>>>> > >>>>>>>>>>>> I would prefer option 1 as some people also mentioned that > >>>>>>> option 2 > >>>>>>>>>>>> requires some standadized processes otherwise it would be > >>>>>>> difficult > >>>>>>>>> to > >>>>>>>>>>>> communicate why somebody is a contributor and some somebody is > >>>>>>> not. > >>>>>>>>>>>> What do you think? > >>>>>>>>>>>> > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> Timo > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Am 18.03.19 um 14:25 schrieb Robert Metzger: > >>>>>>>>>>>>> @Fabian: I don't think this is a big problem. Moving away > >> from > >>>>>>>>>> "giving > >>>>>>>>>>>>> everybody contributor permissions" to "giving it to some > >>>>>>> people" > >>>>>>>> is > >>>>>>>>>> not > >>>>>>>>>>>>> risky. > >>>>>>>>>>>>> I would leave this decision to the committers who are working > >>>>>>>> with > >>>>>>>>> a > >>>>>>>>>>>> person. > >>>>>>>>>>>>> We should bring this discussion to a conclusion and implement > >>>>>>> the > >>>>>>>>>>> changes > >>>>>>>>>>>>> to JIRA. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Nobody has raised any objections to the overall idea. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Points raised: > >>>>>>>>>>>>> 1. We need to update the contribution guide and describe the > >>>>>>>>>> workflow. > >>>>>>>>>>>>> 2. I brought up changing Flinkbot so that it auto-closes PRs > >>>>>>>>> without > >>>>>>>>>>>>> somebody assigned in JIRA. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Who wants to work on an update of the contribution guide? > >>>>>>>>>>>>> If there's no volunteers, I'm happy to take care of this. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Fri, Mar 15, 2019 at 9:20 AM Fabian Hueske < > >>>>>>> fhue...@gmail.com > >>>>>>>>>>> wrote: > >>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I'm not sure about adding an additional stage. > >>>>>>>>>>>>>> Who's going to decide when to "promote" a user to a > >>>>>>> contributor, > >>>>>>>>>> i.e., > >>>>>>>>>>>>>> grant assigning permission? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Best, Fabian > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Am Do., 14. März 2019 um 13:50 Uhr schrieb Timo Walther < > >>>>>>>>>>>>>> twal...@apache.org > >>>>>>>>>>>>>>> : > >>>>>>>>>>>>>>> Hi Robert, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I also like the idea of making every Jira user an > >> "Assignable > >>>>>>>>>> User", > >>>>>>>>>>>> but > >>>>>>>>>>>>>>> restrict assigning a ticket to people with committer > >>>>>>>> permissions. > >>>>>>>>>>>>>>> Instead of giving contributor permissions to everyone, we > >>>>>>> could > >>>>>>>>>> have > >>>>>>>>>>> a > >>>>>>>>>>>>>>> more staged approach from user, to contributor, and finally > >>>>>>> to > >>>>>>>>>>>> committer. > >>>>>>>>>>>>>>> Once people worked on a couple of JIRA issues, we can make > >>>>>>> them > >>>>>>>>>>>>>>> contributors. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> What do you think? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>> Timo > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Am 06.03.19 um 12:33 schrieb Robert Metzger: > >>>>>>>>>>>>>>>> Hi Tison, > >>>>>>>>>>>>>>>> I also thought about this. > >>>>>>>>>>>>>>>> Making a person a "Contributor" is required for being an > >>>>>>>>>> "Assignable > >>>>>>>>>>>>>>> User", > >>>>>>>>>>>>>>>> so normal Jira accounts can't be assigned to a ticket. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> We could make every Jira user an "Assignable User", but > >>>>>>>> restrict > >>>>>>>>>>>>>>> assigning > >>>>>>>>>>>>>>>> a ticket to people with committer permissions. > >>>>>>>>>>>>>>>> There are some other permissions attached to the > >>>>>>> "Contributor" > >>>>>>>>>> role, > >>>>>>>>>>>>>> such > >>>>>>>>>>>>>>>> as "Closing" and "Editing" (including "Transition", > >> "Logging > >>>>>>>>>> work", > >>>>>>>>>>>>>>> etc.). > >>>>>>>>>>>>>>>> I think we should keep the "Contributor" role, but we > >> could > >>>>>>> be > >>>>>>>>> (as > >>>>>>>>>>> you > >>>>>>>>>>>>>>>> propose) make it more restrictive. Maybe "invite only" for > >>>>>>>>> people > >>>>>>>>>>> who > >>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>> apparently active in our Jira. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Best, > >>>>>>>>>>>>>>>> Robert > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 11:02 AM ZiLi Chen < > >>>>>>>> wander4...@gmail.com > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> Hi devs, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Just now I find that one not a contributor can file issue > >>>>>>> and > >>>>>>>>>>>>>>> participant > >>>>>>>>>>>>>>>>> discussion. > >>>>>>>>>>>>>>>>> One becomes contributor can additionally assign an issue > >>>>>>> to a > >>>>>>>>>>> person > >>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>> modify fields of any issues. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> For a more restrictive JIRA workflow, maybe we achieve it > >>>>>>> by > >>>>>>>>>> making > >>>>>>>>>>>>>> it a > >>>>>>>>>>>>>>>>> bit more > >>>>>>>>>>>>>>>>> restrictive granting contributor permission? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Best, > >>>>>>>>>>>>>>>>> tison. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Robert Metzger <rmetz...@apache.org> 于2019年2月27日周三 > >>>>>>> 下午9:53写道： > >>>>>>>>>>>>>>>>>> I like this idea and I would like to try it to see if it > >>>>>>>>> solves > >>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> problem. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I can also offer to add a functionality to the Flinkbot > >> to > >>>>>>>>>>>>>>> automatically > >>>>>>>>>>>>>>>>>> close pull requests which have been opened against a > >>>>>>>>> unassigned > >>>>>>>>>>> JIRA > >>>>>>>>>>>>>>>>>> ticket. > >>>>>>>>>>>>>>>>>> Being rejected by an automated system, which just > >> applies > >>>>>>> a > >>>>>>>>> rule > >>>>>>>>>>> is > >>>>>>>>>>>>>>> nicer > >>>>>>>>>>>>>>>>>> than being rejected by a person. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 1:45 PM Stephan Ewen < > >>>>>>>>> se...@apache.org> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to infra. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen < > >>>>>>>>>> wander4...@gmail.com > >>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> @Hequn > >>>>>>>>>>>>>>>>>>>> It might be hard to separate JIRAs into conditional > >> and > >>>>>>>>>>>>>> unconditional > >>>>>>>>>>>>>>>>>>> ones. > >>>>>>>>>>>>>>>>>>>> Even if INFRA supports such separation, we meet the > >>>>>>>> problem > >>>>>>>>>> that > >>>>>>>>>>>>>>>>>> whether > >>>>>>>>>>>>>>>>>>>> a contributor is granted to decide the type of a JIRA. > >>>>>>> If > >>>>>>>>> so, > >>>>>>>>>>> then > >>>>>>>>>>>>>>>>>>>> contributors might > >>>>>>>>>>>>>>>>>>>> tend to create JIRAs as unconditional; and if not, we > >>>>>>>>> fallback > >>>>>>>>>>>>>> that a > >>>>>>>>>>>>>>>>>>>> contributor > >>>>>>>>>>>>>>>>>>>> ask a committer for setting the JIRA as unconditional, > >>>>>>>> which > >>>>>>>>>> is > >>>>>>>>>>> no > >>>>>>>>>>>>>>>>>> better > >>>>>>>>>>>>>>>>>>>> than > >>>>>>>>>>>>>>>>>>>> ask a committer for assigning to the contributor. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> @Timo > >>>>>>>>>>>>>>>>>>>> "More discussion before opening a PR" sounds good. > >>>>>>>> However, > >>>>>>>>> it > >>>>>>>>>>>>>>>>> requires > >>>>>>>>>>>>>>>>>>>> more > >>>>>>>>>>>>>>>>>>>> effort/participation from committer's side. From my > >> own > >>>>>>>>> side, > >>>>>>>>>>> it's > >>>>>>>>>>>>>>>>>>> exciting > >>>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>> see our committers become more active :-) > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Best, > >>>>>>>>>>>>>>>>>>>> tison. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Chesnay Schepler <ches...@apache.org> 于2019年2月27日周三 > >>>>>>>>> 下午5:06写道： > >>>>>>>>>>>>>>>>>>>>> We currently cannot change the JIRA permissions. Have > >>>>>>> you > >>>>>>>>>> asked > >>>>>>>>>>>>>>>>> INFRA > >>>>>>>>>>>>>>>>>>>>> whether it is possible to setup a Flink-specific > >>>>>>>> permission > >>>>>>>>>>>>>> scheme? > >>>>>>>>>>>>>>>>>>>>> On 25.02.2019 14:23, Timo Walther wrote: > >>>>>>>>>>>>>>>>>>>>>> Hi everyone, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> as some of you might have noticed during the last > >>>>>>> weeks, > >>>>>>>>> the > >>>>>>>>>>>>>>>>> Flink > >>>>>>>>>>>>>>>>>>>>>> community grew quite a bit. A lot of people have > >>>>>>> applied > >>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>>> contributor permissions and started working on > >> issues, > >>>>>>>>> which > >>>>>>>>>>> is > >>>>>>>>>>>>>>>>>> great > >>>>>>>>>>>>>>>>>>>>>> for the growth of Flink! > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> However, we've also observed that managing JIRA and > >>>>>>>>>> coordinate > >>>>>>>>>>>>>>>>> work > >>>>>>>>>>>>>>>>>>>>>> and responsibilities becomes more complex as more > >>>>>>> people > >>>>>>>>> are > >>>>>>>>>>>>>>>>>> joining. > >>>>>>>>>>>>>>>>>>>>>> Here are some observations to examplify the current > >>>>>>>>>>> challenges: > >>>>>>>>>>>>>>>>>>>>>> - There is a high number of concurrent discussion > >>>>>>> about > >>>>>>>>> new > >>>>>>>>>>>>>>>>>> features > >>>>>>>>>>>>>>>>>>>>>> or important refactorings. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> - JIRA issues are being created for components to: > >>>>>>>>>>>>>>>>>>>>>> - represent an implementation plan (e.g. of a > >>>>>>> FLIP) > >>>>>>>>>>>>>>>>>>>>>> - track progress of the feature by splitting > it > >>>>>>>> into a > >>>>>>>>>>> finer > >>>>>>>>>>>>>>>>>>>>>> granularity > >>>>>>>>>>>>>>>>>>>>>> - coordinate work between > >>> contributors/contributor > >>>>>>>>> teams > >>>>>>>>>>>>>>>>>>>>>> - Lack of guidance for new contributors: > >> Contributors > >>>>>>>>> don't > >>>>>>>>>>> know > >>>>>>>>>>>>>>>>>>> which > >>>>>>>>>>>>>>>>>>>>>> issues to pick but are motivated to work on > >> something. > >>>>>>>>>>>>>>>>>>>>>> - Contributors pick issues that: > >>>>>>>>>>>>>>>>>>>>>> - require very good (historical) knowledge of > a > >>>>>>>>>> component > >>>>>>>>>>>>>>>>>>>>>> - need to be implemented in a timely fashion > as > >>>>>>> they > >>>>>>>>>> block > >>>>>>>>>>>>>>>>> other > >>>>>>>>>>>>>>>>>>>>>> contributors or a Flink release > >>>>>>>>>>>>>>>>>>>>>> - have implicit dependencies on other changes > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> - Contributors open pull requests with a bad > >>>>>>>> description, > >>>>>>>>>>>> without > >>>>>>>>>>>>>>>>>>>>>> consensus, or an unsatisfactory architecture. > >>>>>>>> Shortcomings > >>>>>>>>>>> that > >>>>>>>>>>>>>>>>>> could > >>>>>>>>>>>>>>>>>>>>>> have been solved in JIRA before. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> - Committers don't open issues because they fear > >> that > >>>>>>>> some > >>>>>>>>>>>>>>>>> "random" > >>>>>>>>>>>>>>>>>>>>>> contributor picks it up or assign many issues to > >>>>>>>>> themselves > >>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>> "protect" them. Even though they don't have the > >>>>>>> capacity > >>>>>>>>> to > >>>>>>>>>>>> solve > >>>>>>>>>>>>>>>>>> all > >>>>>>>>>>>>>>>>>>>>>> of them. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> I propose to make our JIRA a bit more restrictive: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> - Don't allow contributors to assign issues to > >>>>>>>> themselves. > >>>>>>>>>>> This > >>>>>>>>>>>>>>>>>>> forces > >>>>>>>>>>>>>>>>>>>>>> them to find supporters first. As mentioned in the > >>>>>>>>>>> contribution > >>>>>>>>>>>>>>>>>>>>>> guidelines [1]: "reach consensus with the > >> community". > >>>>>>>> Only > >>>>>>>>>>>>>>>>>> committers > >>>>>>>>>>>>>>>>>>>>>> can assign people to issues. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> - Don't allow contributors to set a fixed version or > >>>>>>>>> release > >>>>>>>>>>>>>>>>> notes. > >>>>>>>>>>>>>>>>>>>>>> Only committers should do that after merging the > >>>>>>>>>> contribution. > >>>>>>>>>>>>>>>>>>>>>> - Don't allow contributors to set a blocker > >> priority. > >>>>>>>> The > >>>>>>>>>>>> release > >>>>>>>>>>>>>>>>>>>>>> manager should decide about that. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> As a nice side-effect, it might also impact the > >> number > >>>>>>>> of > >>>>>>>>>>> stale > >>>>>>>>>>>>>>>>>> pull > >>>>>>>>>>>>>>>>>>>>>> requests by moving the consensus and design > >> discussion > >>>>>>>> to > >>>>>>>>> an > >>>>>>>>>>>>>>>>>> earlier > >>>>>>>>>>>>>>>>>>>>>> phase in the process. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> What do you think? Feel free to propose more > >> workflow > >>>>>>>>>>>>>>>>> improvements. > >>>>>>>>>>>>>>>>>>> Of > >>>>>>>>>>>>>>>>>>>>>> course we need to check with INFRA if this can be > >>>>>>>>>> represented > >>>>>>>>>>> in > >>>>>>>>>>>>>>>>>> our > >>>>>>>>>>>>>>>>>>>>>> JIRA. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>> Timo > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> [1] https://flink.apache.org/contribute-code.html > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> -- > >>>>>>>> Feng (Sent from my phone) > >>>>>>>> > >>>>> > >
