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