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