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