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