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