Checking the result, as a discovery, I found that one can still file a JIRA with "blocker" priority.
IIRC someone in this thread once mentioned that "Don't allow contributors to set a blocker priority." Chesnay, Thanks for the clarification. Best, tison. Chesnay Schepler <ches...@apache.org> 于2019年7月18日周四 下午6:40写道： > We haven't wiped the set of contributors yet. Not sure if there's an > easy way to remove the permissions for all of them; someone from the PMC > may have to bite the bullet and click 600 times in a row :) > > On 18/07/2019 12:32, Zili Chen wrote: > > Robert, > > > > Thanks for your effort. Rejecting contributor permission request > > with a nice message and pointing them to the announcement sounds > > reasonable. Just to be clear, we now have no person with contributor > > role, right? > > > > Chesnay, > > > > https://flink.apache.org/contributing/contribute-code.html has been > > updated and mentions that "Only committers can assign a Jira ticket." > > > > I think the corresponding update has been done. > > > > Best, > > tison. > > > > > > Chesnay Schepler <ches...@apache.org> 于2019年7月18日周四 下午6:25写道： > > > >> Do our contribution guidelines contain anything that should be updated? > >> > >> On 18/07/2019 12:24, Chesnay Schepler wrote: > >>> Sounds good to me. > >>> > >>> On 18/07/2019 12:07, Robert Metzger wrote: > >>>> Infra has finally changed the permissions. I just announced the > >>>> change in a > >>>> separate email [1]. > >>>> > >>>> One thing I wanted to discuss here is, how do we want to handle all > the > >>>> "contributor permissions" requests? > >>>> > >>>> My proposal is to basically reject them with a nice message, pointing > >>>> them > >>>> to my announcement. > >>>> > >>>> What do you think? > >>>> > >>>> > >>>> > >>>> [1] > >>>> > >> > https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E > >>>> > >>>> > >>>> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <rmetz...@apache.org> > >>>> wrote: > >>>> > >>>>> This is the Jira ticket I opened > >>>>> https://issues.apache.org/jira/browse/INFRA-18644 a long time ago :) > >>>>> > >>>>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <ches...@apache.org > > > >>>>> wrote: > >>>>> > >>>>>> @Robert what's the state here? > >>>>>> > >>>>>> On 24/06/2019 16:16, Robert Metzger wrote: > >>>>>>> Hey all, > >>>>>>> > >>>>>>> I would like to drive this discussion to an end soon. > >>>>>>> I've just merged the updated contribution guide to the Flink > website: > >>>>>>> https://flink.apache.org/contributing/contribute-code.html > >>>>>>> > >>>>>>> I will now ask Apache IINFRA to change the permissions in our Jira. > >>>>>>> > >>>>>>> Here's the updated TODO list: > >>>>>>> > >>>>>>> 1. I update the contribution guide DONE > >>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs > >>>>>>> with > >>>>>>> unassigned JIRAs IN PROGRESS > >>>>>>> 3. We ask Infra to change the permissions of our JIRA so that: IN > >>>>>> PROGRESS > >>>>>>> a) only committers can assign users to tickets > >>>>>>> b) contributors can't assign users to tickets > >>>>>>> c) Every registered JIRA user is an assignable user in FLINK > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger < > rmetz...@apache.org> > >>>>>> wrote: > >>>>>>>> Hey, > >>>>>>>> > >>>>>>>> I started working on step 1 and proposed some changes to the Flink > >>>>>>>> website: https://github.com/apache/flink-web/pull/217 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger < > rmetz...@apache.org > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Hi Fabian, > >>>>>>>>> You are right, I made a mistake. I don't think it makes sense to > >>>>>>>>> introduce a new permission class. This will make the life of JIRA > >>>>>> admins > >>>>>>>>> unnecessarily complicated. > >>>>>>>>> I updated the task list: > >>>>>>>>> > >>>>>>>>> 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 > >>>>>>>>> c) Every registered JIRA user is an assignable user in FLINK > >>>>>>>>> 4. We remove all existing contributors > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske < > fhue...@gmail.com> > >>>>>> wrote: > >>>>>>>>>> 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) > >>>>>>>>>>>>>>>>>>> > >>> > >> > >
