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