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