There are many reasons for jira, and one of the most important reasons is that flink varies greatly from version to version. However, I agree that you restrict some rights of developers, including the right to assign and edit.
Robert Metzger <rmetz...@apache.org> 于2019年7月19日周五 下午10:58写道： > Hi all! > > Chesnay wrote: > > > 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 :) > > > I don't think there's an easy way for us. > People with "Contributor" permissions have permissions such as "Closing" > and "Editing" (including "Transition", "Logging work", etc.) issues. > I would propose to either drastically reduce the number of people with > Contributor permissions, leaving just those in, who are helping to keep our > Jira in a clean shape (and this decision would be solely done at the > discretion of the PMC deleting people from the contributor group) > Another option would be to ask Infra to remove all people with Contributor > permissions from Flink (deleting and re-adding the group or so :) ) > Moving forward, the PMC would maintain a list of contributors who are > helping to keep Jira clean and well-organized. > > Tison wrote: > > > IIRC someone in this thread once mentioned that > > "Don't allow contributors to set a blocker priority." > > > Timo wrote this when he kicked off this thread. Sadly, this permission is > not provided by Jira out of the box: > > https://community.atlassian.com/t5/Jira-questions/How-to-restrict-the-setting-of-certain-priorities-to-certain/qaq-p/193230 > We will have to manually monitor tickets with "Blocker" status. > > > Fair enough, we might rephrase as > > "Pull requests belonging to unassigned Jira tickets or not authored by > > assignee will ..." > > > That's a good point. If nobody disagrees, would you like to open PR for > changing it? > > For the action "what should we do", iirc someone in this thread proposed > > closing it via flinkbot. Or leaving without review and merge could be ok > > before we implement automatic reply/reaction. > > > I proposed to automatically close. I believe that this might be too harsh. > I've implemented already an extension to Flinkbot which shows warnings for > a pull request. I just haven't found the time to test the extension and put > it in production. > > > > On Fri, Jul 19, 2019 at 5:51 AM Zili Chen <wander4...@gmail.com> wrote: > > > Fair enough, we might rephrase as > > > > "Pull requests belonging to unassigned Jira tickets or not authored by > > assignee will ..." > > > > For the action "what should we do", iirc someone in this thread proposed > > closing it via flinkbot. Or leaving without review and merge could be ok > > before we implement automatic reply/reaction. > > > > Best, > > tison. > > > > > > Zili Chen <wander4...@gmail.com> 于2019年7月19日周五 上午11:44写道： > > > >> @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) > >>> > > >>>>>>>>>>>>>>>>>>> > >>> > > >>> > >>> > > >> > >>> > > > >>> > > > >>> > > >>> > >> >
