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