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