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