@Jack >From https://flink.apache.org/contributing/contribute-code.html the community claims
- Only start working on the implementation if there is consensus on the approach (e.g. you are assigned to the ticket) and accurately answer your question, - Pull requests belonging to unassigned Jira tickets will not be reviewed or merged by the community. Best, tison. Jark Wu <imj...@gmail.com> 于2019年7月19日周五 上午11:28写道： > A quick question, what should we do if a developer creates a JIRA issue and > then create a pull request at once without assigning? > > > Regards, > Jark > > On Thu, 18 Jul 2019 at 18:50, Zili Chen <wander4...@gmail.com> wrote: > > > 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) > > > >>>>>>>>>>>>>>>>>>> > > > >>> > > > >> > > > > > > > > >
