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