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