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