You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Timo Walther <tw...@apache.org> on 2019/02/25 13:23:30 UTC
[DISCUSS] A more restrictive JIRA workflow
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
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Hequn Cheng <ch...@gmail.com>.
Hi, Timo
Thanks for putting this together and bring the discussion. +1 to making our
JIRAs a bit more restrictive!
I think this makes a good point of view. It would be helpful to force the
contributors to think more about the issues rather than take it directly or
maybe rashly.
One little suggestion: In order not to discourage contributors, maybe we
can separate our JIRAs into two categories, the conditional ones and the
unconditional ones. Contributors can take the unconditional ones freely
while need help from committers to take the conditional ones.
Best, Hequn
On Wed, Feb 27, 2019 at 1:36 AM Stephan Ewen <se...@apache.org> wrote:
> I like the idea of pushing more for "discuss before opening a PR", and this
> could help with that part.
> We have to be clear though that this is not meant as a way to discourage
> contributions.
>
> If we decide to switch to that mode, I think we need to
> - Concurrently update the contribution guide and help contributors
> understand the new workflow
> - Have a way to make sure that issues where someone offers help get a
> timely response (whatever the outcome is).
> The latter point is tricky.
>
>
> On Mon, Feb 25, 2019 at 3:54 PM Dawid Wysakowicz <dw...@apache.org>
> wrote:
>
> > Hi,
> >
> > I think this is very valuable discussion and thank you for starting it.
> >
> > In general I am +1 for this proposal. I think though we must make it very
> > clear that this will require a careful handling by committers. There are
> at
> > least two cases that come to my mind that we need to be aware of:
> >
> > - this will require strict handling and good communication on PRs
> > opened without corresponding JIRA/without being assigned on a JIRA,
> this
> > happens quite a lot,
> > - we must make sure this will not increase the number of hotfixes,
> > - committers should be active with mentoring efforts (probably more
> > than we are currently). I agree that currently there are many PRs
> being
> > opened that lack consensus, proper description etc. There is though a
> > number of simpler fixes that are solved and merged quite fast now,
> which
> > might not get enough attention. The new process will require us to
> accept
> > such contribution twice (first allow contributor to work on it,
> second on
> > the PR itself). Right now if we see that this contribution is indeed a
> > simple one it happens only once on already opened PR.
> >
> > As I said I am +1 for those changes, but we should try hard so that this
> > effort improves contributors experience rather than make it harder.
> >
> > Best,
> >
> > Dawid
> > On 25/02/2019 15:31, Kostas Kloudas wrote:
> >
> > Really nice idea Timo,
> >
> > Thanks for taking the initiative to open this discussion.
> >
> > Although a side-effect, I consider it a big argument about my +1
> > the fact that now we create backpressure whenever needed at the
> > JIRA level, rather than at the open PR level.
> >
> > The reason is that not accepting a PR after the contributor has spent
> > cycles working on an issue, it can be a lot more demotivating than
> > just waiting on the JIRA assignment to be completed.
> >
> > +1 from my side,
> > Kostas
> >
> >
> > On Mon, Feb 25, 2019 at 2:23 PM Timo Walther <tw...@apache.org> <
> twalthr@apache.org> 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
> >
> >
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Stephan Ewen <se...@apache.org>.
I like the idea of pushing more for "discuss before opening a PR", and this
could help with that part.
We have to be clear though that this is not meant as a way to discourage
contributions.
If we decide to switch to that mode, I think we need to
- Concurrently update the contribution guide and help contributors
understand the new workflow
- Have a way to make sure that issues where someone offers help get a
timely response (whatever the outcome is).
The latter point is tricky.
On Mon, Feb 25, 2019 at 3:54 PM Dawid Wysakowicz <dw...@apache.org>
wrote:
> Hi,
>
> I think this is very valuable discussion and thank you for starting it.
>
> In general I am +1 for this proposal. I think though we must make it very
> clear that this will require a careful handling by committers. There are at
> least two cases that come to my mind that we need to be aware of:
>
> - this will require strict handling and good communication on PRs
> opened without corresponding JIRA/without being assigned on a JIRA, this
> happens quite a lot,
> - we must make sure this will not increase the number of hotfixes,
> - committers should be active with mentoring efforts (probably more
> than we are currently). I agree that currently there are many PRs being
> opened that lack consensus, proper description etc. There is though a
> number of simpler fixes that are solved and merged quite fast now, which
> might not get enough attention. The new process will require us to accept
> such contribution twice (first allow contributor to work on it, second on
> the PR itself). Right now if we see that this contribution is indeed a
> simple one it happens only once on already opened PR.
>
> As I said I am +1 for those changes, but we should try hard so that this
> effort improves contributors experience rather than make it harder.
>
> Best,
>
> Dawid
> On 25/02/2019 15:31, Kostas Kloudas wrote:
>
> Really nice idea Timo,
>
> Thanks for taking the initiative to open this discussion.
>
> Although a side-effect, I consider it a big argument about my +1
> the fact that now we create backpressure whenever needed at the
> JIRA level, rather than at the open PR level.
>
> The reason is that not accepting a PR after the contributor has spent
> cycles working on an issue, it can be a lot more demotivating than
> just waiting on the JIRA assignment to be completed.
>
> +1 from my side,
> Kostas
>
>
> On Mon, Feb 25, 2019 at 2:23 PM Timo Walther <tw...@apache.org> <tw...@apache.org> 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
>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Dawid Wysakowicz <dw...@apache.org>.
Hi,
I think this is very valuable discussion and thank you for starting it.
In general I am +1 for this proposal. I think though we must make it
very clear that this will require a careful handling by committers.
There are at least two cases that come to my mind that we need to be
aware of:
* this will require strict handling and good communication on PRs
opened without corresponding JIRA/without being assigned on a JIRA,
this happens quite a lot,
* we must make sure this will not increase the number of hotfixes,
* committers should be active with mentoring efforts (probably more
than we are currently). I agree that currently there are many PRs
being opened that lack consensus, proper description etc. There is
though a number of simpler fixes that are solved and merged quite
fast now, which might not get enough attention. The new process will
require us to accept such contribution twice (first allow
contributor to work on it, second on the PR itself). Right now if we
see that this contribution is indeed a simple one it happens only
once on already opened PR.
As I said I am +1 for those changes, but we should try hard so that this
effort improves contributors experience rather than make it harder.
Best,
Dawid
On 25/02/2019 15:31, Kostas Kloudas wrote:
> Really nice idea Timo,
>
> Thanks for taking the initiative to open this discussion.
>
> Although a side-effect, I consider it a big argument about my +1
> the fact that now we create backpressure whenever needed at the
> JIRA level, rather than at the open PR level.
>
> The reason is that not accepting a PR after the contributor has spent
> cycles working on an issue, it can be a lot more demotivating than
> just waiting on the JIRA assignment to be completed.
>
> +1 from my side,
> Kostas
>
>
> On Mon, Feb 25, 2019 at 2:23 PM Timo Walther <tw...@apache.org> 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
>>
>>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Kostas Kloudas <kk...@gmail.com>.
Really nice idea Timo,
Thanks for taking the initiative to open this discussion.
Although a side-effect, I consider it a big argument about my +1
the fact that now we create backpressure whenever needed at the
JIRA level, rather than at the open PR level.
The reason is that not accepting a PR after the contributor has spent
cycles working on an issue, it can be a lot more demotivating than
just waiting on the JIRA assignment to be completed.
+1 from my side,
Kostas
On Mon, Feb 25, 2019 at 2:23 PM Timo Walther <tw...@apache.org> 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
>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by kai wang <yi...@gmail.com>.
There are many reasons for jira, and one of the most important reasons is
that flink varies greatly from version to version. However, I agree that
you restrict some rights of developers, including the right to assign and
edit.
Robert Metzger <rm...@apache.org> 于2019年7月19日周五 下午10:58写道：
> Hi all!
>
> Chesnay wrote:
>
> > We haven't wiped the set of contributors yet. Not sure if there's an
> > easy way to remove the permissions for all of them; someone from the PMC
> > may have to bite the bullet and click 600 times in a row :)
>
>
> I don't think there's an easy way for us.
> People with "Contributor" permissions have permissions such as "Closing"
> and "Editing" (including "Transition", "Logging work", etc.) issues.
> I would propose to either drastically reduce the number of people with
> Contributor permissions, leaving just those in, who are helping to keep our
> Jira in a clean shape (and this decision would be solely done at the
> discretion of the PMC deleting people from the contributor group)
> Another option would be to ask Infra to remove all people with Contributor
> permissions from Flink (deleting and re-adding the group or so :) )
> Moving forward, the PMC would maintain a list of contributors who are
> helping to keep Jira clean and well-organized.
>
> Tison wrote:
>
> > IIRC someone in this thread once mentioned that
> > "Don't allow contributors to set a blocker priority."
>
>
> Timo wrote this when he kicked off this thread. Sadly, this permission is
> not provided by Jira out of the box:
>
> https://community.atlassian.com/t5/Jira-questions/How-to-restrict-the-setting-of-certain-priorities-to-certain/qaq-p/193230
> We will have to manually monitor tickets with "Blocker" status.
>
>
> Fair enough, we might rephrase as
> > "Pull requests belonging to unassigned Jira tickets or not authored by
> > assignee will ..."
>
>
> That's a good point. If nobody disagrees, would you like to open PR for
> changing it?
>
> For the action "what should we do", iirc someone in this thread proposed
> > closing it via flinkbot. Or leaving without review and merge could be ok
> > before we implement automatic reply/reaction.
>
>
> I proposed to automatically close. I believe that this might be too harsh.
> I've implemented already an extension to Flinkbot which shows warnings for
> a pull request. I just haven't found the time to test the extension and put
> it in production.
>
>
>
> On Fri, Jul 19, 2019 at 5:51 AM Zili Chen <wa...@gmail.com> wrote:
>
> > Fair enough, we might rephrase as
> >
> > "Pull requests belonging to unassigned Jira tickets or not authored by
> > assignee will ..."
> >
> > For the action "what should we do", iirc someone in this thread proposed
> > closing it via flinkbot. Or leaving without review and merge could be ok
> > before we implement automatic reply/reaction.
> >
> > Best,
> > tison.
> >
> >
> > Zili Chen <wa...@gmail.com> 于2019年7月19日周五 上午11:44写道：
> >
> >> @Jack
> >>
> >> From https://flink.apache.org/contributing/contribute-code.html the
> >> community
> >> claims
> >>
> >> - Only start working on the implementation if there is consensus on the
> >> approach (e.g. you are assigned to the ticket)
> >>
> >> and accurately answer your question,
> >>
> >> - Pull requests belonging to unassigned Jira tickets will not be
> reviewed
> >> or merged by the community.
> >>
> >> Best,
> >> tison.
> >>
> >>
> >> Jark Wu <im...@gmail.com> 于2019年7月19日周五 上午11:28写道：
> >>
> >>> A quick question, what should we do if a developer creates a JIRA issue
> >>> and
> >>> then create a pull request at once without assigning?
> >>>
> >>>
> >>> Regards,
> >>> Jark
> >>>
> >>> On Thu, 18 Jul 2019 at 18:50, Zili Chen <wa...@gmail.com> wrote:
> >>>
> >>> > Checking the result, as a discovery, I found that one can
> >>> > still file a JIRA with "blocker" priority.
> >>> >
> >>> > IIRC someone in this thread once mentioned that
> >>> > "Don't allow contributors to set a blocker priority."
> >>> >
> >>> > Chesnay,
> >>> >
> >>> > Thanks for the clarification.
> >>> >
> >>> >
> >>> > Best,
> >>> > tison.
> >>> >
> >>> >
> >>> > Chesnay Schepler <ch...@apache.org> 于2019年7月18日周四 下午6:40写道：
> >>> >
> >>> > > We haven't wiped the set of contributors yet. Not sure if there's
> an
> >>> > > easy way to remove the permissions for all of them; someone from
> the
> >>> PMC
> >>> > > may have to bite the bullet and click 600 times in a row :)
> >>> > >
> >>> > > On 18/07/2019 12:32, Zili Chen wrote:
> >>> > > > Robert,
> >>> > > >
> >>> > > > Thanks for your effort. Rejecting contributor permission request
> >>> > > > with a nice message and pointing them to the announcement sounds
> >>> > > > reasonable. Just to be clear, we now have no person with
> >>> contributor
> >>> > > > role, right?
> >>> > > >
> >>> > > > Chesnay,
> >>> > > >
> >>> > > > https://flink.apache.org/contributing/contribute-code.html has
> >>> been
> >>> > > > updated and mentions that "Only committers can assign a Jira
> >>> ticket."
> >>> > > >
> >>> > > > I think the corresponding update has been done.
> >>> > > >
> >>> > > > Best,
> >>> > > > tison.
> >>> > > >
> >>> > > >
> >>> > > > Chesnay Schepler <ch...@apache.org> 于2019年7月18日周四 下午6:25写道：
> >>> > > >
> >>> > > >> Do our contribution guidelines contain anything that should be
> >>> > updated?
> >>> > > >>
> >>> > > >> On 18/07/2019 12:24, Chesnay Schepler wrote:
> >>> > > >>> Sounds good to me.
> >>> > > >>>
> >>> > > >>> On 18/07/2019 12:07, Robert Metzger wrote:
> >>> > > >>>> Infra has finally changed the permissions. I just announced
> the
> >>> > > >>>> change in a
> >>> > > >>>> separate email [1].
> >>> > > >>>>
> >>> > > >>>> One thing I wanted to discuss here is, how do we want to
> handle
> >>> all
> >>> > > the
> >>> > > >>>> "contributor permissions" requests?
> >>> > > >>>>
> >>> > > >>>> My proposal is to basically reject them with a nice message,
> >>> > pointing
> >>> > > >>>> them
> >>> > > >>>> to my announcement.
> >>> > > >>>>
> >>> > > >>>> What do you think?
> >>> > > >>>>
> >>> > > >>>>
> >>> > > >>>>
> >>> > > >>>> [1]
> >>> > > >>>>
> >>> > > >>
> >>> > >
> >>> >
> >>>
> https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
> >>> > > >>>>
> >>> > > >>>>
> >>> > > >>>> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <
> >>> rmetzger@apache.org>
> >>> > > >>>> wrote:
> >>> > > >>>>
> >>> > > >>>>> This is the Jira ticket I opened
> >>> > > >>>>> https://issues.apache.org/jira/browse/INFRA-18644 a long
> time
> >>> ago
> >>> > :)
> >>> > > >>>>>
> >>> > > >>>>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <
> >>> > chesnay@apache.org
> >>> > > >
> >>> > > >>>>> wrote:
> >>> > > >>>>>
> >>> > > >>>>>> @Robert what's the state here?
> >>> > > >>>>>>
> >>> > > >>>>>> On 24/06/2019 16:16, Robert Metzger wrote:
> >>> > > >>>>>>> Hey all,
> >>> > > >>>>>>>
> >>> > > >>>>>>> I would like to drive this discussion to an end soon.
> >>> > > >>>>>>> I've just merged the updated contribution guide to the
> Flink
> >>> > > website:
> >>> > > >>>>>>> https://flink.apache.org/contributing/contribute-code.html
> >>> > > >>>>>>>
> >>> > > >>>>>>> I will now ask Apache IINFRA to change the permissions in
> our
> >>> > Jira.
> >>> > > >>>>>>>
> >>> > > >>>>>>> Here's the updated TODO list:
> >>> > > >>>>>>>
> >>> > > >>>>>>> 1. I update the contribution guide DONE
> >>> > > >>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings
> >>> on PRs
> >>> > > >>>>>>> with
> >>> > > >>>>>>> unassigned JIRAs IN PROGRESS
> >>> > > >>>>>>> 3. We ask Infra to change the permissions of our JIRA so
> >>> that: IN
> >>> > > >>>>>> PROGRESS
> >>> > > >>>>>>> a) only committers can assign users to tickets
> >>> > > >>>>>>> b) contributors can't assign users to tickets
> >>> > > >>>>>>> c) Every registered JIRA user is an assignable user in
> >>> FLINK
> >>> > > >>>>>>>
> >>> > > >>>>>>>
> >>> > > >>>>>>>
> >>> > > >>>>>>>
> >>> > > >>>>>>>
> >>> > > >>>>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <
> >>> > > rmetzger@apache.org>
> >>> > > >>>>>> wrote:
> >>> > > >>>>>>>> Hey,
> >>> > > >>>>>>>>
> >>> > > >>>>>>>> I started working on step 1 and proposed some changes to
> the
> >>> > Flink
> >>> > > >>>>>>>> website: https://github.com/apache/flink-web/pull/217
> >>> > > >>>>>>>>
> >>> > > >>>>>>>>
> >>> > > >>>>>>>>
> >>> > > >>>>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <
> >>> > > rmetzger@apache.org
> >>> > > >>>>>>>> wrote:
> >>> > > >>>>>>>>
> >>> > > >>>>>>>>> Hi Fabian,
> >>> > > >>>>>>>>> You are right, I made a mistake. I don't think it makes
> >>> sense
> >>> > to
> >>> > > >>>>>>>>> introduce a new permission class. This will make the life
> >>> of
> >>> > JIRA
> >>> > > >>>>>> admins
> >>> > > >>>>>>>>> unnecessarily complicated.
> >>> > > >>>>>>>>> I updated the task list:
> >>> > > >>>>>>>>>
> >>> > > >>>>>>>>> 1. I update the contribution guide
> >>> > > >>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show
> warnings
> >>> on
> >>> > > >>>>>>>>> PRs with
> >>> > > >>>>>>>>> unassigned JIRAs
> >>> > > >>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
> >>> that:
> >>> > > >>>>>>>>> a) only committers can assign users to tickets
> >>> > > >>>>>>>>> b) contributors can't assign users to tickets
> >>> > > >>>>>>>>> c) Every registered JIRA user is an assignable user
> in
> >>> > FLINK
> >>> > > >>>>>>>>> 4. We remove all existing contributors
> >>> > > >>>>>>>>>
> >>> > > >>>>>>>>>
> >>> > > >>>>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <
> >>> > > fhueske@gmail.com>
> >>> > > >>>>>> wrote:
> >>> > > >>>>>>>>>> Hi Robert,
> >>> > > >>>>>>>>>>
> >>> > > >>>>>>>>>> If I understood the decision correctly, we also need to
> >>> ask
> >>> > > >>>>>>>>>> Infra to
> >>> > > >>>>>> make
> >>> > > >>>>>>>>>> everybody an assignable user, right?
> >>> > > >>>>>>>>>> Or do we want to add a new permission class "Assignable
> >>> User"
> >>> > > such
> >>> > > >>>>>> that
> >>> > > >>>>>>>>>> everyone still needs to ask for the right Jira
> >>> permissions?
> >>> > > >>>>>>>>>>
> >>> > > >>>>>>>>>> Fabian
> >>> > > >>>>>>>>>>
> >>> > > >>>>>>>>>>
> >>> > > >>>>>>>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther
> <
> >>> > > >>>>>>>>>> twalthr@apache.org
> >>> > > >>>>>>>>>>> :
> >>> > > >>>>>>>>>>> Hi Robert,
> >>> > > >>>>>>>>>>>
> >>> > > >>>>>>>>>>> thanks for taking care of this. +1 to your suggested
> >>> steps.
> >>> > > >>>>>>>>>>>
> >>> > > >>>>>>>>>>> Regards,
> >>> > > >>>>>>>>>>> Timo
> >>> > > >>>>>>>>>>>
> >>> > > >>>>>>>>>>>
> >>> > > >>>>>>>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
> >>> > > >>>>>>>>>>>> @Stephan: I agree. Auto-closing PRs is quite
> aggressive.
> >>> > > >>>>>>>>>>>> I will only do that for PRs without JIRA ID or
> >>> "[hotfix]" in
> >>> > > the
> >>> > > >>>>>>>>>> title.
> >>> > > >>>>>>>>>>>> We can always revisit this at a later stage.
> >>> > > >>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>
> >>> > > >>>>>>>>>>>> I'm proposing the following steps:
> >>> > > >>>>>>>>>>>>
> >>> > > >>>>>>>>>>>> 1. I update the contribution guide
> >>> > > >>>>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show
> >>> warnings
> >>> > on
> >>> > > >>>>>>>>>>>> PRs
> >>> > > >>>>>>>>>> with
> >>> > > >>>>>>>>>>>> unassigned JIRAs
> >>> > > >>>>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA
> so
> >>> > that:
> >>> > > >>>>>>>>>>>> a) only committers can assign users to tickets
> >>> > > >>>>>>>>>>>> b) contributors can't assign users to tickets
> >>> > > >>>>>>>>>>>> 4. We remove all existing contributors
> >>> > > >>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>
> >>> > > >>>>>>>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang
> >>> > > >>>>>>>>>>>> <ya...@gmail.com>
> >>> > > >>>>>>>>>>> wrote:
> >>> > > >>>>>>>>>>>>> also +1 for option 2.
> >>> > > >>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>> I think auto-close a PR sometimes a bit impertinency.
> >>> > > >>>>>>>>>>>>> The reasons just like Stephan mentioned.
> >>> > > >>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>> Stephan Ewen <se...@apache.org> 于2019年4月24日周三
> >>> > > >>>>>>>>>>>>> 下午4:08写道：
> >>> > > >>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>> About auto-closing PRs from unassigned issues,
> >>> consider
> >>> > the
> >>> > > >>>>>>>>>> following
> >>> > > >>>>>>>>>>>>> case
> >>> > > >>>>>>>>>>>>>> that has happened quite a bit.
> >>> > > >>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>> - a user reports a small bug and immediately
> >>> wants
> >>> > to
> >>> > > >>>>>> provide a
> >>> > > >>>>>>>>>> fix
> >>> > > >>>>>>>>>>> for
> >>> > > >>>>>>>>>>>>>> it
> >>> > > >>>>>>>>>>>>>> - it makes sense to not stall the user for a
> few
> >>> > days
> >>> > > >>>>>>>>>>>>>> until a
> >>> > > >>>>>>>>>>> committer
> >>> > > >>>>>>>>>>>>>> assigned the issue
> >>> > > >>>>>>>>>>>>>> - not auto-closing the PR would at least allow
> >>> the
> >>> > > >>>>>>>>>>>>>> user to
> >>> > > >>>>>>>>>> provide
> >>> > > >>>>>>>>>>>>> their
> >>> > > >>>>>>>>>>>>>> patch.
> >>> > > >>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen
> >>> > > >>>>>>>>>>>>>> <se...@apache.org>
> >>> > > >>>>>>>>>>> wrote:
> >>> > > >>>>>>>>>>>>>>> +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 <
> >>> > > >>>>>> twalthr@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 <
> >>> > > >>>>>>>>>>>>> andrey@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 <
> >>> > > >>>>>>>>>> nemokingdom@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 <
> >>> > > >>>>>>>>>> rmetzger@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 <
> >>> > > >>>>>>>>>>>>>>>> andrey@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
> >>> <
> >>> > > >>>>>>>>>>>>>> rmetzger@apache.org
> >>> > > >>>>>>>>>>>>>>>>>>>>> wrote:
> >>> > > >>>>>>>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>>>>>>>> I'm +1 on option 1.
> >>> > > >>>>>>>>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther
> <
> >>> > > >>>>>>>>>>>>> twalthr@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 <
> >>> > > >>>>>>>>>>>>>>>>>> fhueske@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
> >>> > > >>>>>>>>>> <
> >>> > > >>>>>>>>>>>>>>>>>>>>>>>>> twalthr@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 <
> >>> > > >>>>>>>>>>>>>>>>>>> wander4096@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 <rm...@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
> >>> > > <
> >>> > > >>>>>>>>>>>>>>>>>>>> sewen@apache.org>
> >>> > > >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible,
> >>> > according
> >>> > > to
> >>> > > >>>>>>>>>> infra.
> >>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM
> ZiLi
> >>> > Chen <
> >>> > > >>>>>>>>>>>>>>>>>>>>> wander4096@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 <
> chesnay@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)
> >>> > > >>>>>>>>>>>>>>>>>>>
> >>> > > >>>
> >>> > > >>
> >>> > >
> >>> > >
> >>> >
> >>>
> >>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Robert Metzger <rm...@apache.org>.
Hi all!
Chesnay wrote:
> We haven't wiped the set of contributors yet. Not sure if there's an
> easy way to remove the permissions for all of them; someone from the PMC
> may have to bite the bullet and click 600 times in a row :)
I don't think there's an easy way for us.
People with "Contributor" permissions have permissions such as "Closing"
and "Editing" (including "Transition", "Logging work", etc.) issues.
I would propose to either drastically reduce the number of people with
Contributor permissions, leaving just those in, who are helping to keep our
Jira in a clean shape (and this decision would be solely done at the
discretion of the PMC deleting people from the contributor group)
Another option would be to ask Infra to remove all people with Contributor
permissions from Flink (deleting and re-adding the group or so :) )
Moving forward, the PMC would maintain a list of contributors who are
helping to keep Jira clean and well-organized.
Tison wrote:
> IIRC someone in this thread once mentioned that
> "Don't allow contributors to set a blocker priority."
Timo wrote this when he kicked off this thread. Sadly, this permission is
not provided by Jira out of the box:
https://community.atlassian.com/t5/Jira-questions/How-to-restrict-the-setting-of-certain-priorities-to-certain/qaq-p/193230
We will have to manually monitor tickets with "Blocker" status.
Fair enough, we might rephrase as
> "Pull requests belonging to unassigned Jira tickets or not authored by
> assignee will ..."
That's a good point. If nobody disagrees, would you like to open PR for
changing it?
For the action "what should we do", iirc someone in this thread proposed
> closing it via flinkbot. Or leaving without review and merge could be ok
> before we implement automatic reply/reaction.
I proposed to automatically close. I believe that this might be too harsh.
I've implemented already an extension to Flinkbot which shows warnings for
a pull request. I just haven't found the time to test the extension and put
it in production.
On Fri, Jul 19, 2019 at 5:51 AM Zili Chen <wa...@gmail.com> wrote:
> Fair enough, we might rephrase as
>
> "Pull requests belonging to unassigned Jira tickets or not authored by
> assignee will ..."
>
> For the action "what should we do", iirc someone in this thread proposed
> closing it via flinkbot. Or leaving without review and merge could be ok
> before we implement automatic reply/reaction.
>
> Best,
> tison.
>
>
> Zili Chen <wa...@gmail.com> 于2019年7月19日周五 上午11:44写道：
>
>> @Jack
>>
>> From https://flink.apache.org/contributing/contribute-code.html the
>> community
>> claims
>>
>> - Only start working on the implementation if there is consensus on the
>> approach (e.g. you are assigned to the ticket)
>>
>> and accurately answer your question,
>>
>> - Pull requests belonging to unassigned Jira tickets will not be reviewed
>> or merged by the community.
>>
>> Best,
>> tison.
>>
>>
>> Jark Wu <im...@gmail.com> 于2019年7月19日周五 上午11:28写道：
>>
>>> A quick question, what should we do if a developer creates a JIRA issue
>>> and
>>> then create a pull request at once without assigning?
>>>
>>>
>>> Regards,
>>> Jark
>>>
>>> On Thu, 18 Jul 2019 at 18:50, Zili Chen <wa...@gmail.com> wrote:
>>>
>>> > Checking the result, as a discovery, I found that one can
>>> > still file a JIRA with "blocker" priority.
>>> >
>>> > IIRC someone in this thread once mentioned that
>>> > "Don't allow contributors to set a blocker priority."
>>> >
>>> > Chesnay,
>>> >
>>> > Thanks for the clarification.
>>> >
>>> >
>>> > Best,
>>> > tison.
>>> >
>>> >
>>> > Chesnay Schepler <ch...@apache.org> 于2019年7月18日周四 下午6:40写道：
>>> >
>>> > > We haven't wiped the set of contributors yet. Not sure if there's an
>>> > > easy way to remove the permissions for all of them; someone from the
>>> PMC
>>> > > may have to bite the bullet and click 600 times in a row :)
>>> > >
>>> > > On 18/07/2019 12:32, Zili Chen wrote:
>>> > > > Robert,
>>> > > >
>>> > > > Thanks for your effort. Rejecting contributor permission request
>>> > > > with a nice message and pointing them to the announcement sounds
>>> > > > reasonable. Just to be clear, we now have no person with
>>> contributor
>>> > > > role, right?
>>> > > >
>>> > > > Chesnay,
>>> > > >
>>> > > > https://flink.apache.org/contributing/contribute-code.html has
>>> been
>>> > > > updated and mentions that "Only committers can assign a Jira
>>> ticket."
>>> > > >
>>> > > > I think the corresponding update has been done.
>>> > > >
>>> > > > Best,
>>> > > > tison.
>>> > > >
>>> > > >
>>> > > > Chesnay Schepler <ch...@apache.org> 于2019年7月18日周四 下午6:25写道：
>>> > > >
>>> > > >> Do our contribution guidelines contain anything that should be
>>> > updated?
>>> > > >>
>>> > > >> On 18/07/2019 12:24, Chesnay Schepler wrote:
>>> > > >>> Sounds good to me.
>>> > > >>>
>>> > > >>> On 18/07/2019 12:07, Robert Metzger wrote:
>>> > > >>>> Infra has finally changed the permissions. I just announced the
>>> > > >>>> change in a
>>> > > >>>> separate email [1].
>>> > > >>>>
>>> > > >>>> One thing I wanted to discuss here is, how do we want to handle
>>> all
>>> > > the
>>> > > >>>> "contributor permissions" requests?
>>> > > >>>>
>>> > > >>>> My proposal is to basically reject them with a nice message,
>>> > pointing
>>> > > >>>> them
>>> > > >>>> to my announcement.
>>> > > >>>>
>>> > > >>>> What do you think?
>>> > > >>>>
>>> > > >>>>
>>> > > >>>>
>>> > > >>>> [1]
>>> > > >>>>
>>> > > >>
>>> > >
>>> >
>>> https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
>>> > > >>>>
>>> > > >>>>
>>> > > >>>> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <
>>> rmetzger@apache.org>
>>> > > >>>> wrote:
>>> > > >>>>
>>> > > >>>>> This is the Jira ticket I opened
>>> > > >>>>> https://issues.apache.org/jira/browse/INFRA-18644 a long time
>>> ago
>>> > :)
>>> > > >>>>>
>>> > > >>>>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <
>>> > chesnay@apache.org
>>> > > >
>>> > > >>>>> wrote:
>>> > > >>>>>
>>> > > >>>>>> @Robert what's the state here?
>>> > > >>>>>>
>>> > > >>>>>> On 24/06/2019 16:16, Robert Metzger wrote:
>>> > > >>>>>>> Hey all,
>>> > > >>>>>>>
>>> > > >>>>>>> I would like to drive this discussion to an end soon.
>>> > > >>>>>>> I've just merged the updated contribution guide to the Flink
>>> > > website:
>>> > > >>>>>>> https://flink.apache.org/contributing/contribute-code.html
>>> > > >>>>>>>
>>> > > >>>>>>> I will now ask Apache IINFRA to change the permissions in our
>>> > Jira.
>>> > > >>>>>>>
>>> > > >>>>>>> Here's the updated TODO list:
>>> > > >>>>>>>
>>> > > >>>>>>> 1. I update the contribution guide DONE
>>> > > >>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings
>>> on PRs
>>> > > >>>>>>> with
>>> > > >>>>>>> unassigned JIRAs IN PROGRESS
>>> > > >>>>>>> 3. We ask Infra to change the permissions of our JIRA so
>>> that: IN
>>> > > >>>>>> PROGRESS
>>> > > >>>>>>> a) only committers can assign users to tickets
>>> > > >>>>>>> b) contributors can't assign users to tickets
>>> > > >>>>>>> c) Every registered JIRA user is an assignable user in
>>> FLINK
>>> > > >>>>>>>
>>> > > >>>>>>>
>>> > > >>>>>>>
>>> > > >>>>>>>
>>> > > >>>>>>>
>>> > > >>>>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <
>>> > > rmetzger@apache.org>
>>> > > >>>>>> wrote:
>>> > > >>>>>>>> Hey,
>>> > > >>>>>>>>
>>> > > >>>>>>>> I started working on step 1 and proposed some changes to the
>>> > Flink
>>> > > >>>>>>>> website: https://github.com/apache/flink-web/pull/217
>>> > > >>>>>>>>
>>> > > >>>>>>>>
>>> > > >>>>>>>>
>>> > > >>>>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <
>>> > > rmetzger@apache.org
>>> > > >>>>>>>> wrote:
>>> > > >>>>>>>>
>>> > > >>>>>>>>> Hi Fabian,
>>> > > >>>>>>>>> You are right, I made a mistake. I don't think it makes
>>> sense
>>> > to
>>> > > >>>>>>>>> introduce a new permission class. This will make the life
>>> of
>>> > JIRA
>>> > > >>>>>> admins
>>> > > >>>>>>>>> unnecessarily complicated.
>>> > > >>>>>>>>> I updated the task list:
>>> > > >>>>>>>>>
>>> > > >>>>>>>>> 1. I update the contribution guide
>>> > > >>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings
>>> on
>>> > > >>>>>>>>> PRs with
>>> > > >>>>>>>>> unassigned JIRAs
>>> > > >>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
>>> that:
>>> > > >>>>>>>>> a) only committers can assign users to tickets
>>> > > >>>>>>>>> b) contributors can't assign users to tickets
>>> > > >>>>>>>>> c) Every registered JIRA user is an assignable user in
>>> > FLINK
>>> > > >>>>>>>>> 4. We remove all existing contributors
>>> > > >>>>>>>>>
>>> > > >>>>>>>>>
>>> > > >>>>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <
>>> > > fhueske@gmail.com>
>>> > > >>>>>> wrote:
>>> > > >>>>>>>>>> Hi Robert,
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>> If I understood the decision correctly, we also need to
>>> ask
>>> > > >>>>>>>>>> Infra to
>>> > > >>>>>> make
>>> > > >>>>>>>>>> everybody an assignable user, right?
>>> > > >>>>>>>>>> Or do we want to add a new permission class "Assignable
>>> User"
>>> > > such
>>> > > >>>>>> that
>>> > > >>>>>>>>>> everyone still needs to ask for the right Jira
>>> permissions?
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>> Fabian
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
>>> > > >>>>>>>>>> twalthr@apache.org
>>> > > >>>>>>>>>>> :
>>> > > >>>>>>>>>>> Hi Robert,
>>> > > >>>>>>>>>>>
>>> > > >>>>>>>>>>> thanks for taking care of this. +1 to your suggested
>>> steps.
>>> > > >>>>>>>>>>>
>>> > > >>>>>>>>>>> Regards,
>>> > > >>>>>>>>>>> Timo
>>> > > >>>>>>>>>>>
>>> > > >>>>>>>>>>>
>>> > > >>>>>>>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
>>> > > >>>>>>>>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
>>> > > >>>>>>>>>>>> I will only do that for PRs without JIRA ID or
>>> "[hotfix]" in
>>> > > the
>>> > > >>>>>>>>>> title.
>>> > > >>>>>>>>>>>> We can always revisit this at a later stage.
>>> > > >>>>>>>>>>>>
>>> > > >>>>>>>>>>>>
>>> > > >>>>>>>>>>>> I'm proposing the following steps:
>>> > > >>>>>>>>>>>>
>>> > > >>>>>>>>>>>> 1. I update the contribution guide
>>> > > >>>>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show
>>> warnings
>>> > on
>>> > > >>>>>>>>>>>> PRs
>>> > > >>>>>>>>>> with
>>> > > >>>>>>>>>>>> unassigned JIRAs
>>> > > >>>>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
>>> > that:
>>> > > >>>>>>>>>>>> a) only committers can assign users to tickets
>>> > > >>>>>>>>>>>> b) contributors can't assign users to tickets
>>> > > >>>>>>>>>>>> 4. We remove all existing contributors
>>> > > >>>>>>>>>>>>
>>> > > >>>>>>>>>>>>
>>> > > >>>>>>>>>>>>
>>> > > >>>>>>>>>>>>
>>> > > >>>>>>>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang
>>> > > >>>>>>>>>>>> <ya...@gmail.com>
>>> > > >>>>>>>>>>> wrote:
>>> > > >>>>>>>>>>>>> also +1 for option 2.
>>> > > >>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>> I think auto-close a PR sometimes a bit impertinency.
>>> > > >>>>>>>>>>>>> The reasons just like Stephan mentioned.
>>> > > >>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>> Stephan Ewen <se...@apache.org> 于2019年4月24日周三
>>> > > >>>>>>>>>>>>> 下午4:08写道：
>>> > > >>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>> About auto-closing PRs from unassigned issues,
>>> consider
>>> > the
>>> > > >>>>>>>>>> following
>>> > > >>>>>>>>>>>>> case
>>> > > >>>>>>>>>>>>>> that has happened quite a bit.
>>> > > >>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>> - a user reports a small bug and immediately
>>> wants
>>> > to
>>> > > >>>>>> provide a
>>> > > >>>>>>>>>> fix
>>> > > >>>>>>>>>>> for
>>> > > >>>>>>>>>>>>>> it
>>> > > >>>>>>>>>>>>>> - it makes sense to not stall the user for a few
>>> > days
>>> > > >>>>>>>>>>>>>> until a
>>> > > >>>>>>>>>>> committer
>>> > > >>>>>>>>>>>>>> assigned the issue
>>> > > >>>>>>>>>>>>>> - not auto-closing the PR would at least allow
>>> the
>>> > > >>>>>>>>>>>>>> user to
>>> > > >>>>>>>>>> provide
>>> > > >>>>>>>>>>>>> their
>>> > > >>>>>>>>>>>>>> patch.
>>> > > >>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen
>>> > > >>>>>>>>>>>>>> <se...@apache.org>
>>> > > >>>>>>>>>>> wrote:
>>> > > >>>>>>>>>>>>>>> +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 <
>>> > > >>>>>> twalthr@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 <
>>> > > >>>>>>>>>>>>> andrey@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 <
>>> > > >>>>>>>>>> nemokingdom@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 <
>>> > > >>>>>>>>>> rmetzger@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 <
>>> > > >>>>>>>>>>>>>>>> andrey@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
>>> <
>>> > > >>>>>>>>>>>>>> rmetzger@apache.org
>>> > > >>>>>>>>>>>>>>>>>>>>> wrote:
>>> > > >>>>>>>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>>>>>>>> I'm +1 on option 1.
>>> > > >>>>>>>>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
>>> > > >>>>>>>>>>>>> twalthr@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 <
>>> > > >>>>>>>>>>>>>>>>>> fhueske@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
>>> > > >>>>>>>>>> <
>>> > > >>>>>>>>>>>>>>>>>>>>>>>>> twalthr@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 <
>>> > > >>>>>>>>>>>>>>>>>>> wander4096@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 <rm...@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
>>> > > <
>>> > > >>>>>>>>>>>>>>>>>>>> sewen@apache.org>
>>> > > >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible,
>>> > according
>>> > > to
>>> > > >>>>>>>>>> infra.
>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi
>>> > Chen <
>>> > > >>>>>>>>>>>>>>>>>>>>> wander4096@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 <chesnay@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)
>>> > > >>>>>>>>>>>>>>>>>>>
>>> > > >>>
>>> > > >>
>>> > >
>>> > >
>>> >
>>>
>>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Zili Chen <wa...@gmail.com>.
Fair enough, we might rephrase as
"Pull requests belonging to unassigned Jira tickets or not authored by
assignee will ..."
For the action "what should we do", iirc someone in this thread proposed
closing it via flinkbot. Or leaving without review and merge could be ok
before we implement automatic reply/reaction.
Best,
tison.
Zili Chen <wa...@gmail.com> 于2019年7月19日周五 上午11:44写道：
> @Jack
>
> From https://flink.apache.org/contributing/contribute-code.html the
> community
> claims
>
> - Only start working on the implementation if there is consensus on the
> approach (e.g. you are assigned to the ticket)
>
> and accurately answer your question,
>
> - Pull requests belonging to unassigned Jira tickets will not be reviewed
> or merged by the community.
>
> Best,
> tison.
>
>
> Jark Wu <im...@gmail.com> 于2019年7月19日周五 上午11:28写道：
>
>> A quick question, what should we do if a developer creates a JIRA issue
>> and
>> then create a pull request at once without assigning?
>>
>>
>> Regards,
>> Jark
>>
>> On Thu, 18 Jul 2019 at 18:50, Zili Chen <wa...@gmail.com> wrote:
>>
>> > Checking the result, as a discovery, I found that one can
>> > still file a JIRA with "blocker" priority.
>> >
>> > IIRC someone in this thread once mentioned that
>> > "Don't allow contributors to set a blocker priority."
>> >
>> > Chesnay,
>> >
>> > Thanks for the clarification.
>> >
>> >
>> > Best,
>> > tison.
>> >
>> >
>> > Chesnay Schepler <ch...@apache.org> 于2019年7月18日周四 下午6:40写道：
>> >
>> > > We haven't wiped the set of contributors yet. Not sure if there's an
>> > > easy way to remove the permissions for all of them; someone from the
>> PMC
>> > > may have to bite the bullet and click 600 times in a row :)
>> > >
>> > > On 18/07/2019 12:32, Zili Chen wrote:
>> > > > Robert,
>> > > >
>> > > > Thanks for your effort. Rejecting contributor permission request
>> > > > with a nice message and pointing them to the announcement sounds
>> > > > reasonable. Just to be clear, we now have no person with contributor
>> > > > role, right?
>> > > >
>> > > > Chesnay,
>> > > >
>> > > > https://flink.apache.org/contributing/contribute-code.html has been
>> > > > updated and mentions that "Only committers can assign a Jira
>> ticket."
>> > > >
>> > > > I think the corresponding update has been done.
>> > > >
>> > > > Best,
>> > > > tison.
>> > > >
>> > > >
>> > > > Chesnay Schepler <ch...@apache.org> 于2019年7月18日周四 下午6:25写道：
>> > > >
>> > > >> Do our contribution guidelines contain anything that should be
>> > updated?
>> > > >>
>> > > >> On 18/07/2019 12:24, Chesnay Schepler wrote:
>> > > >>> Sounds good to me.
>> > > >>>
>> > > >>> On 18/07/2019 12:07, Robert Metzger wrote:
>> > > >>>> Infra has finally changed the permissions. I just announced the
>> > > >>>> change in a
>> > > >>>> separate email [1].
>> > > >>>>
>> > > >>>> One thing I wanted to discuss here is, how do we want to handle
>> all
>> > > the
>> > > >>>> "contributor permissions" requests?
>> > > >>>>
>> > > >>>> My proposal is to basically reject them with a nice message,
>> > pointing
>> > > >>>> them
>> > > >>>> to my announcement.
>> > > >>>>
>> > > >>>> What do you think?
>> > > >>>>
>> > > >>>>
>> > > >>>>
>> > > >>>> [1]
>> > > >>>>
>> > > >>
>> > >
>> >
>> https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
>> > > >>>>
>> > > >>>>
>> > > >>>> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <
>> rmetzger@apache.org>
>> > > >>>> wrote:
>> > > >>>>
>> > > >>>>> This is the Jira ticket I opened
>> > > >>>>> https://issues.apache.org/jira/browse/INFRA-18644 a long time
>> ago
>> > :)
>> > > >>>>>
>> > > >>>>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <
>> > chesnay@apache.org
>> > > >
>> > > >>>>> wrote:
>> > > >>>>>
>> > > >>>>>> @Robert what's the state here?
>> > > >>>>>>
>> > > >>>>>> On 24/06/2019 16:16, Robert Metzger wrote:
>> > > >>>>>>> Hey all,
>> > > >>>>>>>
>> > > >>>>>>> I would like to drive this discussion to an end soon.
>> > > >>>>>>> I've just merged the updated contribution guide to the Flink
>> > > website:
>> > > >>>>>>> https://flink.apache.org/contributing/contribute-code.html
>> > > >>>>>>>
>> > > >>>>>>> I will now ask Apache IINFRA to change the permissions in our
>> > Jira.
>> > > >>>>>>>
>> > > >>>>>>> Here's the updated TODO list:
>> > > >>>>>>>
>> > > >>>>>>> 1. I update the contribution guide DONE
>> > > >>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
>> PRs
>> > > >>>>>>> with
>> > > >>>>>>> unassigned JIRAs IN PROGRESS
>> > > >>>>>>> 3. We ask Infra to change the permissions of our JIRA so
>> that: IN
>> > > >>>>>> PROGRESS
>> > > >>>>>>> a) only committers can assign users to tickets
>> > > >>>>>>> b) contributors can't assign users to tickets
>> > > >>>>>>> c) Every registered JIRA user is an assignable user in
>> FLINK
>> > > >>>>>>>
>> > > >>>>>>>
>> > > >>>>>>>
>> > > >>>>>>>
>> > > >>>>>>>
>> > > >>>>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <
>> > > rmetzger@apache.org>
>> > > >>>>>> wrote:
>> > > >>>>>>>> Hey,
>> > > >>>>>>>>
>> > > >>>>>>>> I started working on step 1 and proposed some changes to the
>> > Flink
>> > > >>>>>>>> website: https://github.com/apache/flink-web/pull/217
>> > > >>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <
>> > > rmetzger@apache.org
>> > > >>>>>>>> wrote:
>> > > >>>>>>>>
>> > > >>>>>>>>> Hi Fabian,
>> > > >>>>>>>>> You are right, I made a mistake. I don't think it makes
>> sense
>> > to
>> > > >>>>>>>>> introduce a new permission class. This will make the life of
>> > JIRA
>> > > >>>>>> admins
>> > > >>>>>>>>> unnecessarily complicated.
>> > > >>>>>>>>> I updated the task list:
>> > > >>>>>>>>>
>> > > >>>>>>>>> 1. I update the contribution guide
>> > > >>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings
>> on
>> > > >>>>>>>>> PRs with
>> > > >>>>>>>>> unassigned JIRAs
>> > > >>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
>> that:
>> > > >>>>>>>>> a) only committers can assign users to tickets
>> > > >>>>>>>>> b) contributors can't assign users to tickets
>> > > >>>>>>>>> c) Every registered JIRA user is an assignable user in
>> > FLINK
>> > > >>>>>>>>> 4. We remove all existing contributors
>> > > >>>>>>>>>
>> > > >>>>>>>>>
>> > > >>>>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <
>> > > fhueske@gmail.com>
>> > > >>>>>> wrote:
>> > > >>>>>>>>>> Hi Robert,
>> > > >>>>>>>>>>
>> > > >>>>>>>>>> If I understood the decision correctly, we also need to ask
>> > > >>>>>>>>>> Infra to
>> > > >>>>>> make
>> > > >>>>>>>>>> everybody an assignable user, right?
>> > > >>>>>>>>>> Or do we want to add a new permission class "Assignable
>> User"
>> > > such
>> > > >>>>>> that
>> > > >>>>>>>>>> everyone still needs to ask for the right Jira permissions?
>> > > >>>>>>>>>>
>> > > >>>>>>>>>> Fabian
>> > > >>>>>>>>>>
>> > > >>>>>>>>>>
>> > > >>>>>>>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
>> > > >>>>>>>>>> twalthr@apache.org
>> > > >>>>>>>>>>> :
>> > > >>>>>>>>>>> Hi Robert,
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> thanks for taking care of this. +1 to your suggested
>> steps.
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> Regards,
>> > > >>>>>>>>>>> Timo
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
>> > > >>>>>>>>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
>> > > >>>>>>>>>>>> I will only do that for PRs without JIRA ID or
>> "[hotfix]" in
>> > > the
>> > > >>>>>>>>>> title.
>> > > >>>>>>>>>>>> We can always revisit this at a later stage.
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> I'm proposing the following steps:
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> 1. I update the contribution guide
>> > > >>>>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show
>> warnings
>> > on
>> > > >>>>>>>>>>>> PRs
>> > > >>>>>>>>>> with
>> > > >>>>>>>>>>>> unassigned JIRAs
>> > > >>>>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
>> > that:
>> > > >>>>>>>>>>>> a) only committers can assign users to tickets
>> > > >>>>>>>>>>>> b) contributors can't assign users to tickets
>> > > >>>>>>>>>>>> 4. We remove all existing contributors
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang
>> > > >>>>>>>>>>>> <ya...@gmail.com>
>> > > >>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>> also +1 for option 2.
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> I think auto-close a PR sometimes a bit impertinency.
>> > > >>>>>>>>>>>>> The reasons just like Stephan mentioned.
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> Stephan Ewen <se...@apache.org> 于2019年4月24日周三
>> > > >>>>>>>>>>>>> 下午4:08写道：
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> About auto-closing PRs from unassigned issues, consider
>> > the
>> > > >>>>>>>>>> following
>> > > >>>>>>>>>>>>> case
>> > > >>>>>>>>>>>>>> that has happened quite a bit.
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> - a user reports a small bug and immediately
>> wants
>> > to
>> > > >>>>>> provide a
>> > > >>>>>>>>>> fix
>> > > >>>>>>>>>>> for
>> > > >>>>>>>>>>>>>> it
>> > > >>>>>>>>>>>>>> - it makes sense to not stall the user for a few
>> > days
>> > > >>>>>>>>>>>>>> until a
>> > > >>>>>>>>>>> committer
>> > > >>>>>>>>>>>>>> assigned the issue
>> > > >>>>>>>>>>>>>> - not auto-closing the PR would at least allow
>> the
>> > > >>>>>>>>>>>>>> user to
>> > > >>>>>>>>>> provide
>> > > >>>>>>>>>>>>> their
>> > > >>>>>>>>>>>>>> patch.
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen
>> > > >>>>>>>>>>>>>> <se...@apache.org>
>> > > >>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>> +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 <
>> > > >>>>>> twalthr@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 <
>> > > >>>>>>>>>>>>> andrey@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 <
>> > > >>>>>>>>>> nemokingdom@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 <
>> > > >>>>>>>>>> rmetzger@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
>> <
>> > > >>>>>>>>>>>>>>>> andrey@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 <
>> > > >>>>>>>>>>>>>> rmetzger@apache.org
>> > > >>>>>>>>>>>>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>>> I'm +1 on option 1.
>> > > >>>>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
>> > > >>>>>>>>>>>>> twalthr@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 <
>> > > >>>>>>>>>>>>>>>>>> fhueske@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
>> > > >>>>>>>>>> <
>> > > >>>>>>>>>>>>>>>>>>>>>>>>> twalthr@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
>> <
>> > > >>>>>>>>>>>>>>>>>>> wander4096@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 <rm...@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
>> > > <
>> > > >>>>>>>>>>>>>>>>>>>> sewen@apache.org>
>> > > >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible,
>> > according
>> > > to
>> > > >>>>>>>>>> infra.
>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi
>> > Chen <
>> > > >>>>>>>>>>>>>>>>>>>>> wander4096@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 <ch...@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)
>> > > >>>>>>>>>>>>>>>>>>>
>> > > >>>
>> > > >>
>> > >
>> > >
>> >
>>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Zili Chen <wa...@gmail.com>.
@Jack
From https://flink.apache.org/contributing/contribute-code.html the
community
claims
- Only start working on the implementation if there is consensus on the
approach (e.g. you are assigned to the ticket)
and accurately answer your question,
- Pull requests belonging to unassigned Jira tickets will not be reviewed
or merged by the community.
Best,
tison.
Jark Wu <im...@gmail.com> 于2019年7月19日周五 上午11:28写道：
> A quick question, what should we do if a developer creates a JIRA issue and
> then create a pull request at once without assigning?
>
>
> Regards,
> Jark
>
> On Thu, 18 Jul 2019 at 18:50, Zili Chen <wa...@gmail.com> wrote:
>
> > Checking the result, as a discovery, I found that one can
> > still file a JIRA with "blocker" priority.
> >
> > IIRC someone in this thread once mentioned that
> > "Don't allow contributors to set a blocker priority."
> >
> > Chesnay,
> >
> > Thanks for the clarification.
> >
> >
> > Best,
> > tison.
> >
> >
> > Chesnay Schepler <ch...@apache.org> 于2019年7月18日周四 下午6:40写道：
> >
> > > We haven't wiped the set of contributors yet. Not sure if there's an
> > > easy way to remove the permissions for all of them; someone from the
> PMC
> > > may have to bite the bullet and click 600 times in a row :)
> > >
> > > On 18/07/2019 12:32, Zili Chen wrote:
> > > > Robert,
> > > >
> > > > Thanks for your effort. Rejecting contributor permission request
> > > > with a nice message and pointing them to the announcement sounds
> > > > reasonable. Just to be clear, we now have no person with contributor
> > > > role, right?
> > > >
> > > > Chesnay,
> > > >
> > > > https://flink.apache.org/contributing/contribute-code.html has been
> > > > updated and mentions that "Only committers can assign a Jira ticket."
> > > >
> > > > I think the corresponding update has been done.
> > > >
> > > > Best,
> > > > tison.
> > > >
> > > >
> > > > Chesnay Schepler <ch...@apache.org> 于2019年7月18日周四 下午6:25写道：
> > > >
> > > >> Do our contribution guidelines contain anything that should be
> > updated?
> > > >>
> > > >> On 18/07/2019 12:24, Chesnay Schepler wrote:
> > > >>> Sounds good to me.
> > > >>>
> > > >>> On 18/07/2019 12:07, Robert Metzger wrote:
> > > >>>> Infra has finally changed the permissions. I just announced the
> > > >>>> change in a
> > > >>>> separate email [1].
> > > >>>>
> > > >>>> One thing I wanted to discuss here is, how do we want to handle
> all
> > > the
> > > >>>> "contributor permissions" requests?
> > > >>>>
> > > >>>> My proposal is to basically reject them with a nice message,
> > pointing
> > > >>>> them
> > > >>>> to my announcement.
> > > >>>>
> > > >>>> What do you think?
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> [1]
> > > >>>>
> > > >>
> > >
> >
> https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
> > > >>>>
> > > >>>>
> > > >>>> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <
> rmetzger@apache.org>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> This is the Jira ticket I opened
> > > >>>>> https://issues.apache.org/jira/browse/INFRA-18644 a long time
> ago
> > :)
> > > >>>>>
> > > >>>>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <
> > chesnay@apache.org
> > > >
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> @Robert what's the state here?
> > > >>>>>>
> > > >>>>>> On 24/06/2019 16:16, Robert Metzger wrote:
> > > >>>>>>> Hey all,
> > > >>>>>>>
> > > >>>>>>> I would like to drive this discussion to an end soon.
> > > >>>>>>> I've just merged the updated contribution guide to the Flink
> > > website:
> > > >>>>>>> https://flink.apache.org/contributing/contribute-code.html
> > > >>>>>>>
> > > >>>>>>> I will now ask Apache IINFRA to change the permissions in our
> > Jira.
> > > >>>>>>>
> > > >>>>>>> Here's the updated TODO list:
> > > >>>>>>>
> > > >>>>>>> 1. I update the contribution guide DONE
> > > >>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
> PRs
> > > >>>>>>> with
> > > >>>>>>> unassigned JIRAs IN PROGRESS
> > > >>>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
> IN
> > > >>>>>> PROGRESS
> > > >>>>>>> a) only committers can assign users to tickets
> > > >>>>>>> b) contributors can't assign users to tickets
> > > >>>>>>> c) Every registered JIRA user is an assignable user in
> FLINK
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <
> > > rmetzger@apache.org>
> > > >>>>>> wrote:
> > > >>>>>>>> Hey,
> > > >>>>>>>>
> > > >>>>>>>> I started working on step 1 and proposed some changes to the
> > Flink
> > > >>>>>>>> website: https://github.com/apache/flink-web/pull/217
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <
> > > rmetzger@apache.org
> > > >>>>>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> Hi Fabian,
> > > >>>>>>>>> You are right, I made a mistake. I don't think it makes sense
> > to
> > > >>>>>>>>> introduce a new permission class. This will make the life of
> > JIRA
> > > >>>>>> admins
> > > >>>>>>>>> unnecessarily complicated.
> > > >>>>>>>>> I updated the task list:
> > > >>>>>>>>>
> > > >>>>>>>>> 1. I update the contribution guide
> > > >>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
> > > >>>>>>>>> PRs with
> > > >>>>>>>>> unassigned JIRAs
> > > >>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
> that:
> > > >>>>>>>>> a) only committers can assign users to tickets
> > > >>>>>>>>> b) contributors can't assign users to tickets
> > > >>>>>>>>> c) Every registered JIRA user is an assignable user in
> > FLINK
> > > >>>>>>>>> 4. We remove all existing contributors
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <
> > > fhueske@gmail.com>
> > > >>>>>> wrote:
> > > >>>>>>>>>> Hi Robert,
> > > >>>>>>>>>>
> > > >>>>>>>>>> If I understood the decision correctly, we also need to ask
> > > >>>>>>>>>> Infra to
> > > >>>>>> make
> > > >>>>>>>>>> everybody an assignable user, right?
> > > >>>>>>>>>> Or do we want to add a new permission class "Assignable
> User"
> > > such
> > > >>>>>> that
> > > >>>>>>>>>> everyone still needs to ask for the right Jira permissions?
> > > >>>>>>>>>>
> > > >>>>>>>>>> Fabian
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
> > > >>>>>>>>>> twalthr@apache.org
> > > >>>>>>>>>>> :
> > > >>>>>>>>>>> Hi Robert,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> thanks for taking care of this. +1 to your suggested steps.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Regards,
> > > >>>>>>>>>>> Timo
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
> > > >>>>>>>>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
> > > >>>>>>>>>>>> I will only do that for PRs without JIRA ID or "[hotfix]"
> in
> > > the
> > > >>>>>>>>>> title.
> > > >>>>>>>>>>>> We can always revisit this at a later stage.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I'm proposing the following steps:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 1. I update the contribution guide
> > > >>>>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings
> > on
> > > >>>>>>>>>>>> PRs
> > > >>>>>>>>>> with
> > > >>>>>>>>>>>> unassigned JIRAs
> > > >>>>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
> > that:
> > > >>>>>>>>>>>> a) only committers can assign users to tickets
> > > >>>>>>>>>>>> b) contributors can't assign users to tickets
> > > >>>>>>>>>>>> 4. We remove all existing contributors
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang
> > > >>>>>>>>>>>> <ya...@gmail.com>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>> also +1 for option 2.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I think auto-close a PR sometimes a bit impertinency.
> > > >>>>>>>>>>>>> The reasons just like Stephan mentioned.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Stephan Ewen <se...@apache.org> 于2019年4月24日周三
> > > >>>>>>>>>>>>> 下午4:08写道：
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> About auto-closing PRs from unassigned issues, consider
> > the
> > > >>>>>>>>>> following
> > > >>>>>>>>>>>>> case
> > > >>>>>>>>>>>>>> that has happened quite a bit.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> - a user reports a small bug and immediately wants
> > to
> > > >>>>>> provide a
> > > >>>>>>>>>> fix
> > > >>>>>>>>>>> for
> > > >>>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>> - it makes sense to not stall the user for a few
> > days
> > > >>>>>>>>>>>>>> until a
> > > >>>>>>>>>>> committer
> > > >>>>>>>>>>>>>> assigned the issue
> > > >>>>>>>>>>>>>> - not auto-closing the PR would at least allow the
> > > >>>>>>>>>>>>>> user to
> > > >>>>>>>>>> provide
> > > >>>>>>>>>>>>> their
> > > >>>>>>>>>>>>>> patch.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen
> > > >>>>>>>>>>>>>> <se...@apache.org>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>> +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 <
> > > >>>>>> twalthr@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 <
> > > >>>>>>>>>>>>> andrey@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 <
> > > >>>>>>>>>> nemokingdom@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 <
> > > >>>>>>>>>> rmetzger@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 <
> > > >>>>>>>>>>>>>>>> andrey@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 <
> > > >>>>>>>>>>>>>> rmetzger@apache.org
> > > >>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> I'm +1 on option 1.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
> > > >>>>>>>>>>>>> twalthr@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
> <
> > > >>>>>>>>>>>>>>>>>> fhueske@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
> > > >>>>>>>>>> <
> > > >>>>>>>>>>>>>>>>>>>>>>>>> twalthr@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 <
> > > >>>>>>>>>>>>>>>>>>> wander4096@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 <rm...@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
> > > <
> > > >>>>>>>>>>>>>>>>>>>> sewen@apache.org>
> > > >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible,
> > according
> > > to
> > > >>>>>>>>>> infra.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi
> > Chen <
> > > >>>>>>>>>>>>>>>>>>>>> wander4096@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 <ch...@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)
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>
> > > >>
> > >
> > >
> >
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Jark Wu <im...@gmail.com>.
A quick question, what should we do if a developer creates a JIRA issue and
then create a pull request at once without assigning?
Regards,
Jark
On Thu, 18 Jul 2019 at 18:50, Zili Chen <wa...@gmail.com> wrote:
> Checking the result, as a discovery, I found that one can
> still file a JIRA with "blocker" priority.
>
> IIRC someone in this thread once mentioned that
> "Don't allow contributors to set a blocker priority."
>
> Chesnay,
>
> Thanks for the clarification.
>
>
> Best,
> tison.
>
>
> Chesnay Schepler <ch...@apache.org> 于2019年7月18日周四 下午6:40写道：
>
> > We haven't wiped the set of contributors yet. Not sure if there's an
> > easy way to remove the permissions for all of them; someone from the PMC
> > may have to bite the bullet and click 600 times in a row :)
> >
> > On 18/07/2019 12:32, Zili Chen wrote:
> > > Robert,
> > >
> > > Thanks for your effort. Rejecting contributor permission request
> > > with a nice message and pointing them to the announcement sounds
> > > reasonable. Just to be clear, we now have no person with contributor
> > > role, right?
> > >
> > > Chesnay,
> > >
> > > https://flink.apache.org/contributing/contribute-code.html has been
> > > updated and mentions that "Only committers can assign a Jira ticket."
> > >
> > > I think the corresponding update has been done.
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > Chesnay Schepler <ch...@apache.org> 于2019年7月18日周四 下午6:25写道：
> > >
> > >> Do our contribution guidelines contain anything that should be
> updated?
> > >>
> > >> On 18/07/2019 12:24, Chesnay Schepler wrote:
> > >>> Sounds good to me.
> > >>>
> > >>> On 18/07/2019 12:07, Robert Metzger wrote:
> > >>>> Infra has finally changed the permissions. I just announced the
> > >>>> change in a
> > >>>> separate email [1].
> > >>>>
> > >>>> One thing I wanted to discuss here is, how do we want to handle all
> > the
> > >>>> "contributor permissions" requests?
> > >>>>
> > >>>> My proposal is to basically reject them with a nice message,
> pointing
> > >>>> them
> > >>>> to my announcement.
> > >>>>
> > >>>> What do you think?
> > >>>>
> > >>>>
> > >>>>
> > >>>> [1]
> > >>>>
> > >>
> >
> https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
> > >>>>
> > >>>>
> > >>>> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <rm...@apache.org>
> > >>>> wrote:
> > >>>>
> > >>>>> This is the Jira ticket I opened
> > >>>>> https://issues.apache.org/jira/browse/INFRA-18644 a long time ago
> :)
> > >>>>>
> > >>>>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <
> chesnay@apache.org
> > >
> > >>>>> wrote:
> > >>>>>
> > >>>>>> @Robert what's the state here?
> > >>>>>>
> > >>>>>> On 24/06/2019 16:16, Robert Metzger wrote:
> > >>>>>>> Hey all,
> > >>>>>>>
> > >>>>>>> I would like to drive this discussion to an end soon.
> > >>>>>>> I've just merged the updated contribution guide to the Flink
> > website:
> > >>>>>>> https://flink.apache.org/contributing/contribute-code.html
> > >>>>>>>
> > >>>>>>> I will now ask Apache IINFRA to change the permissions in our
> Jira.
> > >>>>>>>
> > >>>>>>> Here's the updated TODO list:
> > >>>>>>>
> > >>>>>>> 1. I update the contribution guide DONE
> > >>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs
> > >>>>>>> with
> > >>>>>>> unassigned JIRAs IN PROGRESS
> > >>>>>>> 3. We ask Infra to change the permissions of our JIRA so that: IN
> > >>>>>> PROGRESS
> > >>>>>>> a) only committers can assign users to tickets
> > >>>>>>> b) contributors can't assign users to tickets
> > >>>>>>> c) Every registered JIRA user is an assignable user in FLINK
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <
> > rmetzger@apache.org>
> > >>>>>> wrote:
> > >>>>>>>> Hey,
> > >>>>>>>>
> > >>>>>>>> I started working on step 1 and proposed some changes to the
> Flink
> > >>>>>>>> website: https://github.com/apache/flink-web/pull/217
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <
> > rmetzger@apache.org
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Hi Fabian,
> > >>>>>>>>> You are right, I made a mistake. I don't think it makes sense
> to
> > >>>>>>>>> introduce a new permission class. This will make the life of
> JIRA
> > >>>>>> admins
> > >>>>>>>>> unnecessarily complicated.
> > >>>>>>>>> I updated the task list:
> > >>>>>>>>>
> > >>>>>>>>> 1. I update the contribution guide
> > >>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
> > >>>>>>>>> PRs with
> > >>>>>>>>> unassigned JIRAs
> > >>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
> > >>>>>>>>> a) only committers can assign users to tickets
> > >>>>>>>>> b) contributors can't assign users to tickets
> > >>>>>>>>> c) Every registered JIRA user is an assignable user in
> FLINK
> > >>>>>>>>> 4. We remove all existing contributors
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <
> > fhueske@gmail.com>
> > >>>>>> wrote:
> > >>>>>>>>>> Hi Robert,
> > >>>>>>>>>>
> > >>>>>>>>>> If I understood the decision correctly, we also need to ask
> > >>>>>>>>>> Infra to
> > >>>>>> make
> > >>>>>>>>>> everybody an assignable user, right?
> > >>>>>>>>>> Or do we want to add a new permission class "Assignable User"
> > such
> > >>>>>> that
> > >>>>>>>>>> everyone still needs to ask for the right Jira permissions?
> > >>>>>>>>>>
> > >>>>>>>>>> Fabian
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
> > >>>>>>>>>> twalthr@apache.org
> > >>>>>>>>>>> :
> > >>>>>>>>>>> Hi Robert,
> > >>>>>>>>>>>
> > >>>>>>>>>>> thanks for taking care of this. +1 to your suggested steps.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Regards,
> > >>>>>>>>>>> Timo
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
> > >>>>>>>>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
> > >>>>>>>>>>>> I will only do that for PRs without JIRA ID or "[hotfix]" in
> > the
> > >>>>>>>>>> title.
> > >>>>>>>>>>>> We can always revisit this at a later stage.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I'm proposing the following steps:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 1. I update the contribution guide
> > >>>>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings
> on
> > >>>>>>>>>>>> PRs
> > >>>>>>>>>> with
> > >>>>>>>>>>>> unassigned JIRAs
> > >>>>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
> that:
> > >>>>>>>>>>>> a) only committers can assign users to tickets
> > >>>>>>>>>>>> b) contributors can't assign users to tickets
> > >>>>>>>>>>>> 4. We remove all existing contributors
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang
> > >>>>>>>>>>>> <ya...@gmail.com>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>>> also +1 for option 2.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I think auto-close a PR sometimes a bit impertinency.
> > >>>>>>>>>>>>> The reasons just like Stephan mentioned.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Stephan Ewen <se...@apache.org> 于2019年4月24日周三
> > >>>>>>>>>>>>> 下午4:08写道：
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> About auto-closing PRs from unassigned issues, consider
> the
> > >>>>>>>>>> following
> > >>>>>>>>>>>>> case
> > >>>>>>>>>>>>>> that has happened quite a bit.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> - a user reports a small bug and immediately wants
> to
> > >>>>>> provide a
> > >>>>>>>>>> fix
> > >>>>>>>>>>> for
> > >>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>> - it makes sense to not stall the user for a few
> days
> > >>>>>>>>>>>>>> until a
> > >>>>>>>>>>> committer
> > >>>>>>>>>>>>>> assigned the issue
> > >>>>>>>>>>>>>> - not auto-closing the PR would at least allow the
> > >>>>>>>>>>>>>> user to
> > >>>>>>>>>> provide
> > >>>>>>>>>>>>> their
> > >>>>>>>>>>>>>> patch.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen
> > >>>>>>>>>>>>>> <se...@apache.org>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>> +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 <
> > >>>>>> twalthr@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 <
> > >>>>>>>>>>>>> andrey@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 <
> > >>>>>>>>>> nemokingdom@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 <
> > >>>>>>>>>> rmetzger@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 <
> > >>>>>>>>>>>>>>>> andrey@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 <
> > >>>>>>>>>>>>>> rmetzger@apache.org
> > >>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> I'm +1 on option 1.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
> > >>>>>>>>>>>>> twalthr@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 <
> > >>>>>>>>>>>>>>>>>> fhueske@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
> > >>>>>>>>>> <
> > >>>>>>>>>>>>>>>>>>>>>>>>> twalthr@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 <
> > >>>>>>>>>>>>>>>>>>> wander4096@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 <rm...@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
> > <
> > >>>>>>>>>>>>>>>>>>>> sewen@apache.org>
> > >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible,
> according
> > to
> > >>>>>>>>>> infra.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi
> Chen <
> > >>>>>>>>>>>>>>>>>>>>> wander4096@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 <ch...@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)
> > >>>>>>>>>>>>>>>>>>>
> > >>>
> > >>
> >
> >
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Zili Chen <wa...@gmail.com>.
Checking the result, as a discovery, I found that one can
still file a JIRA with "blocker" priority.
IIRC someone in this thread once mentioned that
"Don't allow contributors to set a blocker priority."
Chesnay,
Thanks for the clarification.
Best,
tison.
Chesnay Schepler <ch...@apache.org> 于2019年7月18日周四 下午6:40写道：
> We haven't wiped the set of contributors yet. Not sure if there's an
> easy way to remove the permissions for all of them; someone from the PMC
> may have to bite the bullet and click 600 times in a row :)
>
> On 18/07/2019 12:32, Zili Chen wrote:
> > Robert,
> >
> > Thanks for your effort. Rejecting contributor permission request
> > with a nice message and pointing them to the announcement sounds
> > reasonable. Just to be clear, we now have no person with contributor
> > role, right?
> >
> > Chesnay,
> >
> > https://flink.apache.org/contributing/contribute-code.html has been
> > updated and mentions that "Only committers can assign a Jira ticket."
> >
> > I think the corresponding update has been done.
> >
> > Best,
> > tison.
> >
> >
> > Chesnay Schepler <ch...@apache.org> 于2019年7月18日周四 下午6:25写道：
> >
> >> Do our contribution guidelines contain anything that should be updated?
> >>
> >> On 18/07/2019 12:24, Chesnay Schepler wrote:
> >>> Sounds good to me.
> >>>
> >>> On 18/07/2019 12:07, Robert Metzger wrote:
> >>>> Infra has finally changed the permissions. I just announced the
> >>>> change in a
> >>>> separate email [1].
> >>>>
> >>>> One thing I wanted to discuss here is, how do we want to handle all
> the
> >>>> "contributor permissions" requests?
> >>>>
> >>>> My proposal is to basically reject them with a nice message, pointing
> >>>> them
> >>>> to my announcement.
> >>>>
> >>>> What do you think?
> >>>>
> >>>>
> >>>>
> >>>> [1]
> >>>>
> >>
> https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
> >>>>
> >>>>
> >>>> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <rm...@apache.org>
> >>>> wrote:
> >>>>
> >>>>> This is the Jira ticket I opened
> >>>>> https://issues.apache.org/jira/browse/INFRA-18644 a long time ago :)
> >>>>>
> >>>>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <chesnay@apache.org
> >
> >>>>> wrote:
> >>>>>
> >>>>>> @Robert what's the state here?
> >>>>>>
> >>>>>> On 24/06/2019 16:16, Robert Metzger wrote:
> >>>>>>> Hey all,
> >>>>>>>
> >>>>>>> I would like to drive this discussion to an end soon.
> >>>>>>> I've just merged the updated contribution guide to the Flink
> website:
> >>>>>>> https://flink.apache.org/contributing/contribute-code.html
> >>>>>>>
> >>>>>>> I will now ask Apache IINFRA to change the permissions in our Jira.
> >>>>>>>
> >>>>>>> Here's the updated TODO list:
> >>>>>>>
> >>>>>>> 1. I update the contribution guide DONE
> >>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs
> >>>>>>> with
> >>>>>>> unassigned JIRAs IN PROGRESS
> >>>>>>> 3. We ask Infra to change the permissions of our JIRA so that: IN
> >>>>>> PROGRESS
> >>>>>>> a) only committers can assign users to tickets
> >>>>>>> b) contributors can't assign users to tickets
> >>>>>>> c) Every registered JIRA user is an assignable user in FLINK
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <
> rmetzger@apache.org>
> >>>>>> wrote:
> >>>>>>>> Hey,
> >>>>>>>>
> >>>>>>>> I started working on step 1 and proposed some changes to the Flink
> >>>>>>>> website: https://github.com/apache/flink-web/pull/217
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <
> rmetzger@apache.org
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Fabian,
> >>>>>>>>> You are right, I made a mistake. I don't think it makes sense to
> >>>>>>>>> introduce a new permission class. This will make the life of JIRA
> >>>>>> admins
> >>>>>>>>> unnecessarily complicated.
> >>>>>>>>> I updated the task list:
> >>>>>>>>>
> >>>>>>>>> 1. I update the contribution guide
> >>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
> >>>>>>>>> PRs with
> >>>>>>>>> unassigned JIRAs
> >>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
> >>>>>>>>> a) only committers can assign users to tickets
> >>>>>>>>> b) contributors can't assign users to tickets
> >>>>>>>>> c) Every registered JIRA user is an assignable user in FLINK
> >>>>>>>>> 4. We remove all existing contributors
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <
> fhueske@gmail.com>
> >>>>>> wrote:
> >>>>>>>>>> Hi Robert,
> >>>>>>>>>>
> >>>>>>>>>> If I understood the decision correctly, we also need to ask
> >>>>>>>>>> Infra to
> >>>>>> make
> >>>>>>>>>> everybody an assignable user, right?
> >>>>>>>>>> Or do we want to add a new permission class "Assignable User"
> such
> >>>>>> that
> >>>>>>>>>> everyone still needs to ask for the right Jira permissions?
> >>>>>>>>>>
> >>>>>>>>>> Fabian
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
> >>>>>>>>>> twalthr@apache.org
> >>>>>>>>>>> :
> >>>>>>>>>>> Hi Robert,
> >>>>>>>>>>>
> >>>>>>>>>>> thanks for taking care of this. +1 to your suggested steps.
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Timo
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
> >>>>>>>>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
> >>>>>>>>>>>> I will only do that for PRs without JIRA ID or "[hotfix]" in
> the
> >>>>>>>>>> title.
> >>>>>>>>>>>> We can always revisit this at a later stage.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'm proposing the following steps:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1. I update the contribution guide
> >>>>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
> >>>>>>>>>>>> PRs
> >>>>>>>>>> with
> >>>>>>>>>>>> unassigned JIRAs
> >>>>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
> >>>>>>>>>>>> a) only committers can assign users to tickets
> >>>>>>>>>>>> b) contributors can't assign users to tickets
> >>>>>>>>>>>> 4. We remove all existing contributors
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang
> >>>>>>>>>>>> <ya...@gmail.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>> also +1 for option 2.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I think auto-close a PR sometimes a bit impertinency.
> >>>>>>>>>>>>> The reasons just like Stephan mentioned.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Stephan Ewen <se...@apache.org> 于2019年4月24日周三
> >>>>>>>>>>>>> 下午4:08写道：
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> About auto-closing PRs from unassigned issues, consider the
> >>>>>>>>>> following
> >>>>>>>>>>>>> case
> >>>>>>>>>>>>>> that has happened quite a bit.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> - a user reports a small bug and immediately wants to
> >>>>>> provide a
> >>>>>>>>>> fix
> >>>>>>>>>>> for
> >>>>>>>>>>>>>> it
> >>>>>>>>>>>>>> - it makes sense to not stall the user for a few days
> >>>>>>>>>>>>>> until a
> >>>>>>>>>>> committer
> >>>>>>>>>>>>>> assigned the issue
> >>>>>>>>>>>>>> - not auto-closing the PR would at least allow the
> >>>>>>>>>>>>>> user to
> >>>>>>>>>> provide
> >>>>>>>>>>>>> their
> >>>>>>>>>>>>>> patch.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen
> >>>>>>>>>>>>>> <se...@apache.org>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>> +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 <
> >>>>>> twalthr@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 <
> >>>>>>>>>>>>> andrey@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 <
> >>>>>>>>>> nemokingdom@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 <
> >>>>>>>>>> rmetzger@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 <
> >>>>>>>>>>>>>>>> andrey@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 <
> >>>>>>>>>>>>>> rmetzger@apache.org
> >>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I'm +1 on option 1.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
> >>>>>>>>>>>>> twalthr@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 <
> >>>>>>>>>>>>>>>>>> fhueske@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
> >>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>> twalthr@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 <
> >>>>>>>>>>>>>>>>>>> wander4096@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 <rm...@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
> <
> >>>>>>>>>>>>>>>>>>>> sewen@apache.org>
> >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according
> to
> >>>>>>>>>> infra.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
> >>>>>>>>>>>>>>>>>>>>> wander4096@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 <ch...@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)
> >>>>>>>>>>>>>>>>>>>
> >>>
> >>
>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Chesnay Schepler <ch...@apache.org>.
We haven't wiped the set of contributors yet. Not sure if there's an
easy way to remove the permissions for all of them; someone from the PMC
may have to bite the bullet and click 600 times in a row :)
On 18/07/2019 12:32, Zili Chen wrote:
> Robert,
>
> Thanks for your effort. Rejecting contributor permission request
> with a nice message and pointing them to the announcement sounds
> reasonable. Just to be clear, we now have no person with contributor
> role, right?
>
> Chesnay,
>
> https://flink.apache.org/contributing/contribute-code.html has been
> updated and mentions that "Only committers can assign a Jira ticket."
>
> I think the corresponding update has been done.
>
> Best,
> tison.
>
>
> Chesnay Schepler <ch...@apache.org> 于2019年7月18日周四 下午6:25写道：
>
>> Do our contribution guidelines contain anything that should be updated?
>>
>> On 18/07/2019 12:24, Chesnay Schepler wrote:
>>> Sounds good to me.
>>>
>>> On 18/07/2019 12:07, Robert Metzger wrote:
>>>> Infra has finally changed the permissions. I just announced the
>>>> change in a
>>>> separate email [1].
>>>>
>>>> One thing I wanted to discuss here is, how do we want to handle all the
>>>> "contributor permissions" requests?
>>>>
>>>> My proposal is to basically reject them with a nice message, pointing
>>>> them
>>>> to my announcement.
>>>>
>>>> What do you think?
>>>>
>>>>
>>>>
>>>> [1]
>>>>
>> https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
>>>>
>>>>
>>>> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <rm...@apache.org>
>>>> wrote:
>>>>
>>>>> This is the Jira ticket I opened
>>>>> https://issues.apache.org/jira/browse/INFRA-18644 a long time ago :)
>>>>>
>>>>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <ch...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> @Robert what's the state here?
>>>>>>
>>>>>> On 24/06/2019 16:16, Robert Metzger wrote:
>>>>>>> Hey all,
>>>>>>>
>>>>>>> I would like to drive this discussion to an end soon.
>>>>>>> I've just merged the updated contribution guide to the Flink website:
>>>>>>> https://flink.apache.org/contributing/contribute-code.html
>>>>>>>
>>>>>>> I will now ask Apache IINFRA to change the permissions in our Jira.
>>>>>>>
>>>>>>> Here's the updated TODO list:
>>>>>>>
>>>>>>> 1. I update the contribution guide DONE
>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs
>>>>>>> with
>>>>>>> unassigned JIRAs IN PROGRESS
>>>>>>> 3. We ask Infra to change the permissions of our JIRA so that: IN
>>>>>> PROGRESS
>>>>>>> a) only committers can assign users to tickets
>>>>>>> b) contributors can't assign users to tickets
>>>>>>> c) Every registered JIRA user is an assignable user in FLINK
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <rm...@apache.org>
>>>>>> wrote:
>>>>>>>> Hey,
>>>>>>>>
>>>>>>>> I started working on step 1 and proposed some changes to the Flink
>>>>>>>> website: https://github.com/apache/flink-web/pull/217
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <rmetzger@apache.org
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Fabian,
>>>>>>>>> You are right, I made a mistake. I don't think it makes sense to
>>>>>>>>> introduce a new permission class. This will make the life of JIRA
>>>>>> admins
>>>>>>>>> unnecessarily complicated.
>>>>>>>>> I updated the task list:
>>>>>>>>>
>>>>>>>>> 1. I update the contribution guide
>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
>>>>>>>>> PRs with
>>>>>>>>> unassigned JIRAs
>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
>>>>>>>>> a) only committers can assign users to tickets
>>>>>>>>> b) contributors can't assign users to tickets
>>>>>>>>> c) Every registered JIRA user is an assignable user in FLINK
>>>>>>>>> 4. We remove all existing contributors
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <fh...@gmail.com>
>>>>>> wrote:
>>>>>>>>>> Hi Robert,
>>>>>>>>>>
>>>>>>>>>> If I understood the decision correctly, we also need to ask
>>>>>>>>>> Infra to
>>>>>> make
>>>>>>>>>> everybody an assignable user, right?
>>>>>>>>>> Or do we want to add a new permission class "Assignable User" such
>>>>>> that
>>>>>>>>>> everyone still needs to ask for the right Jira permissions?
>>>>>>>>>>
>>>>>>>>>> Fabian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
>>>>>>>>>> twalthr@apache.org
>>>>>>>>>>> :
>>>>>>>>>>> Hi Robert,
>>>>>>>>>>>
>>>>>>>>>>> thanks for taking care of this. +1 to your suggested steps.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Timo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
>>>>>>>>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
>>>>>>>>>>>> I will only do that for PRs without JIRA ID or "[hotfix]" in the
>>>>>>>>>> title.
>>>>>>>>>>>> We can always revisit this at a later stage.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I'm proposing the following steps:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. I update the contribution guide
>>>>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
>>>>>>>>>>>> PRs
>>>>>>>>>> with
>>>>>>>>>>>> unassigned JIRAs
>>>>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
>>>>>>>>>>>> a) only committers can assign users to tickets
>>>>>>>>>>>> b) contributors can't assign users to tickets
>>>>>>>>>>>> 4. We remove all existing contributors
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang
>>>>>>>>>>>> <ya...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>> also +1 for option 2.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think auto-close a PR sometimes a bit impertinency.
>>>>>>>>>>>>> The reasons just like Stephan mentioned.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Stephan Ewen <se...@apache.org> 于2019年4月24日周三
>>>>>>>>>>>>> 下午4:08写道：
>>>>>>>>>>>>>
>>>>>>>>>>>>>> About auto-closing PRs from unassigned issues, consider the
>>>>>>>>>> following
>>>>>>>>>>>>> case
>>>>>>>>>>>>>> that has happened quite a bit.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - a user reports a small bug and immediately wants to
>>>>>> provide a
>>>>>>>>>> fix
>>>>>>>>>>> for
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> - it makes sense to not stall the user for a few days
>>>>>>>>>>>>>> until a
>>>>>>>>>>> committer
>>>>>>>>>>>>>> assigned the issue
>>>>>>>>>>>>>> - not auto-closing the PR would at least allow the
>>>>>>>>>>>>>> user to
>>>>>>>>>> provide
>>>>>>>>>>>>> their
>>>>>>>>>>>>>> patch.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen
>>>>>>>>>>>>>> <se...@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> +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 <
>>>>>> twalthr@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 <
>>>>>>>>>>>>> andrey@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 <
>>>>>>>>>> nemokingdom@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 <
>>>>>>>>>> rmetzger@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 <
>>>>>>>>>>>>>>>> andrey@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 <
>>>>>>>>>>>>>> rmetzger@apache.org
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I'm +1 on option 1.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
>>>>>>>>>>>>> twalthr@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 <
>>>>>>>>>>>>>>>>>> fhueske@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
>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>> twalthr@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 <
>>>>>>>>>>>>>>>>>>> wander4096@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 <rm...@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 <
>>>>>>>>>>>>>>>>>>>> sewen@apache.org>
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to
>>>>>>>>>> infra.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
>>>>>>>>>>>>>>>>>>>>> wander4096@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 <ch...@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)
>>>>>>>>>>>>>>>>>>>
>>>
>>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Zili Chen <wa...@gmail.com>.
Robert,
Thanks for your effort. Rejecting contributor permission request
with a nice message and pointing them to the announcement sounds
reasonable. Just to be clear, we now have no person with contributor
role, right?
Chesnay,
https://flink.apache.org/contributing/contribute-code.html has been
updated and mentions that "Only committers can assign a Jira ticket."
I think the corresponding update has been done.
Best,
tison.
Chesnay Schepler <ch...@apache.org> 于2019年7月18日周四 下午6:25写道：
> Do our contribution guidelines contain anything that should be updated?
>
> On 18/07/2019 12:24, Chesnay Schepler wrote:
> > Sounds good to me.
> >
> > On 18/07/2019 12:07, Robert Metzger wrote:
> >> Infra has finally changed the permissions. I just announced the
> >> change in a
> >> separate email [1].
> >>
> >> One thing I wanted to discuss here is, how do we want to handle all the
> >> "contributor permissions" requests?
> >>
> >> My proposal is to basically reject them with a nice message, pointing
> >> them
> >> to my announcement.
> >>
> >> What do you think?
> >>
> >>
> >>
> >> [1]
> >>
> https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
> >>
> >>
> >>
> >> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <rm...@apache.org>
> >> wrote:
> >>
> >>> This is the Jira ticket I opened
> >>> https://issues.apache.org/jira/browse/INFRA-18644 a long time ago :)
> >>>
> >>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <ch...@apache.org>
> >>> wrote:
> >>>
> >>>> @Robert what's the state here?
> >>>>
> >>>> On 24/06/2019 16:16, Robert Metzger wrote:
> >>>>> Hey all,
> >>>>>
> >>>>> I would like to drive this discussion to an end soon.
> >>>>> I've just merged the updated contribution guide to the Flink website:
> >>>>> https://flink.apache.org/contributing/contribute-code.html
> >>>>>
> >>>>> I will now ask Apache IINFRA to change the permissions in our Jira.
> >>>>>
> >>>>> Here's the updated TODO list:
> >>>>>
> >>>>> 1. I update the contribution guide DONE
> >>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs
> >>>>> with
> >>>>> unassigned JIRAs IN PROGRESS
> >>>>> 3. We ask Infra to change the permissions of our JIRA so that: IN
> >>>> PROGRESS
> >>>>> a) only committers can assign users to tickets
> >>>>> b) contributors can't assign users to tickets
> >>>>> c) Every registered JIRA user is an assignable user in FLINK
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <rm...@apache.org>
> >>>> wrote:
> >>>>>> Hey,
> >>>>>>
> >>>>>> I started working on step 1 and proposed some changes to the Flink
> >>>>>> website: https://github.com/apache/flink-web/pull/217
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <rmetzger@apache.org
> >
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi Fabian,
> >>>>>>> You are right, I made a mistake. I don't think it makes sense to
> >>>>>>> introduce a new permission class. This will make the life of JIRA
> >>>> admins
> >>>>>>> unnecessarily complicated.
> >>>>>>> I updated the task list:
> >>>>>>>
> >>>>>>> 1. I update the contribution guide
> >>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
> >>>>>>> PRs with
> >>>>>>> unassigned JIRAs
> >>>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
> >>>>>>> a) only committers can assign users to tickets
> >>>>>>> b) contributors can't assign users to tickets
> >>>>>>> c) Every registered JIRA user is an assignable user in FLINK
> >>>>>>> 4. We remove all existing contributors
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <fh...@gmail.com>
> >>>> wrote:
> >>>>>>>> Hi Robert,
> >>>>>>>>
> >>>>>>>> If I understood the decision correctly, we also need to ask
> >>>>>>>> Infra to
> >>>> make
> >>>>>>>> everybody an assignable user, right?
> >>>>>>>> Or do we want to add a new permission class "Assignable User" such
> >>>> that
> >>>>>>>> everyone still needs to ask for the right Jira permissions?
> >>>>>>>>
> >>>>>>>> Fabian
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
> >>>>>>>> twalthr@apache.org
> >>>>>>>>> :
> >>>>>>>>> Hi Robert,
> >>>>>>>>>
> >>>>>>>>> thanks for taking care of this. +1 to your suggested steps.
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Timo
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
> >>>>>>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
> >>>>>>>>>> I will only do that for PRs without JIRA ID or "[hotfix]" in the
> >>>>>>>> title.
> >>>>>>>>>> We can always revisit this at a later stage.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I'm proposing the following steps:
> >>>>>>>>>>
> >>>>>>>>>> 1. I update the contribution guide
> >>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
> >>>>>>>>>> PRs
> >>>>>>>> with
> >>>>>>>>>> unassigned JIRAs
> >>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
> >>>>>>>>>> a) only committers can assign users to tickets
> >>>>>>>>>> b) contributors can't assign users to tickets
> >>>>>>>>>> 4. We remove all existing contributors
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang
> >>>>>>>>>> <ya...@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>> also +1 for option 2.
> >>>>>>>>>>>
> >>>>>>>>>>> I think auto-close a PR sometimes a bit impertinency.
> >>>>>>>>>>> The reasons just like Stephan mentioned.
> >>>>>>>>>>>
> >>>>>>>>>>> Stephan Ewen <se...@apache.org> 于2019年4月24日周三
> >>>>>>>>>>> 下午4:08写道：
> >>>>>>>>>>>
> >>>>>>>>>>>> About auto-closing PRs from unassigned issues, consider the
> >>>>>>>> following
> >>>>>>>>>>> case
> >>>>>>>>>>>> that has happened quite a bit.
> >>>>>>>>>>>>
> >>>>>>>>>>>> - a user reports a small bug and immediately wants to
> >>>> provide a
> >>>>>>>> fix
> >>>>>>>>> for
> >>>>>>>>>>>> it
> >>>>>>>>>>>> - it makes sense to not stall the user for a few days
> >>>>>>>>>>>> until a
> >>>>>>>>> committer
> >>>>>>>>>>>> assigned the issue
> >>>>>>>>>>>> - not auto-closing the PR would at least allow the
> >>>>>>>>>>>> user to
> >>>>>>>> provide
> >>>>>>>>>>> their
> >>>>>>>>>>>> patch.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen
> >>>>>>>>>>>> <se...@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>> +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 <
> >>>> twalthr@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 <
> >>>>>>>>>>> andrey@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 <
> >>>>>>>> nemokingdom@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 <
> >>>>>>>> rmetzger@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 <
> >>>>>>>>>>>>>> andrey@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 <
> >>>>>>>>>>>> rmetzger@apache.org
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I'm +1 on option 1.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
> >>>>>>>>>>> twalthr@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 <
> >>>>>>>>>>>>>>>> fhueske@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
> >>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>> twalthr@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 <
> >>>>>>>>>>>>>>>>> wander4096@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 <rm...@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 <
> >>>>>>>>>>>>>>>>>> sewen@apache.org>
> >>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to
> >>>>>>>> infra.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
> >>>>>>>>>>>>>>>>>>> wander4096@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 <ch...@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)
> >>>>>>>>>>>>>>>>>
> >>>>
> >
> >
>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Chesnay Schepler <ch...@apache.org>.
Do our contribution guidelines contain anything that should be updated?
On 18/07/2019 12:24, Chesnay Schepler wrote:
> Sounds good to me.
>
> On 18/07/2019 12:07, Robert Metzger wrote:
>> Infra has finally changed the permissions. I just announced the
>> change in a
>> separate email [1].
>>
>> One thing I wanted to discuss here is, how do we want to handle all the
>> "contributor permissions" requests?
>>
>> My proposal is to basically reject them with a nice message, pointing
>> them
>> to my announcement.
>>
>> What do you think?
>>
>>
>>
>> [1]
>> https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
>>
>>
>>
>> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <rm...@apache.org>
>> wrote:
>>
>>> This is the Jira ticket I opened
>>> https://issues.apache.org/jira/browse/INFRA-18644 a long time ago :)
>>>
>>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <ch...@apache.org>
>>> wrote:
>>>
>>>> @Robert what's the state here?
>>>>
>>>> On 24/06/2019 16:16, Robert Metzger wrote:
>>>>> Hey all,
>>>>>
>>>>> I would like to drive this discussion to an end soon.
>>>>> I've just merged the updated contribution guide to the Flink website:
>>>>> https://flink.apache.org/contributing/contribute-code.html
>>>>>
>>>>> I will now ask Apache IINFRA to change the permissions in our Jira.
>>>>>
>>>>> Here's the updated TODO list:
>>>>>
>>>>> 1. I update the contribution guide DONE
>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs
>>>>> with
>>>>> unassigned JIRAs IN PROGRESS
>>>>> 3. We ask Infra to change the permissions of our JIRA so that: IN
>>>> PROGRESS
>>>>> a) only committers can assign users to tickets
>>>>> b) contributors can't assign users to tickets
>>>>> c) Every registered JIRA user is an assignable user in FLINK
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <rm...@apache.org>
>>>> wrote:
>>>>>> Hey,
>>>>>>
>>>>>> I started working on step 1 and proposed some changes to the Flink
>>>>>> website: https://github.com/apache/flink-web/pull/217
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <rm...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Fabian,
>>>>>>> You are right, I made a mistake. I don't think it makes sense to
>>>>>>> introduce a new permission class. This will make the life of JIRA
>>>> admins
>>>>>>> unnecessarily complicated.
>>>>>>> I updated the task list:
>>>>>>>
>>>>>>> 1. I update the contribution guide
>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
>>>>>>> PRs with
>>>>>>> unassigned JIRAs
>>>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
>>>>>>> a) only committers can assign users to tickets
>>>>>>> b) contributors can't assign users to tickets
>>>>>>> c) Every registered JIRA user is an assignable user in FLINK
>>>>>>> 4. We remove all existing contributors
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <fh...@gmail.com>
>>>> wrote:
>>>>>>>> Hi Robert,
>>>>>>>>
>>>>>>>> If I understood the decision correctly, we also need to ask
>>>>>>>> Infra to
>>>> make
>>>>>>>> everybody an assignable user, right?
>>>>>>>> Or do we want to add a new permission class "Assignable User" such
>>>> that
>>>>>>>> everyone still needs to ask for the right Jira permissions?
>>>>>>>>
>>>>>>>> Fabian
>>>>>>>>
>>>>>>>>
>>>>>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
>>>>>>>> twalthr@apache.org
>>>>>>>>> :
>>>>>>>>> Hi Robert,
>>>>>>>>>
>>>>>>>>> thanks for taking care of this. +1 to your suggested steps.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Timo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
>>>>>>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
>>>>>>>>>> I will only do that for PRs without JIRA ID or "[hotfix]" in the
>>>>>>>> title.
>>>>>>>>>> We can always revisit this at a later stage.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm proposing the following steps:
>>>>>>>>>>
>>>>>>>>>> 1. I update the contribution guide
>>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
>>>>>>>>>> PRs
>>>>>>>> with
>>>>>>>>>> unassigned JIRAs
>>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
>>>>>>>>>> a) only committers can assign users to tickets
>>>>>>>>>> b) contributors can't assign users to tickets
>>>>>>>>>> 4. We remove all existing contributors
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang
>>>>>>>>>> <ya...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>> also +1 for option 2.
>>>>>>>>>>>
>>>>>>>>>>> I think auto-close a PR sometimes a bit impertinency.
>>>>>>>>>>> The reasons just like Stephan mentioned.
>>>>>>>>>>>
>>>>>>>>>>> Stephan Ewen <se...@apache.org> 于2019年4月24日周三
>>>>>>>>>>> 下午4:08写道：
>>>>>>>>>>>
>>>>>>>>>>>> About auto-closing PRs from unassigned issues, consider the
>>>>>>>> following
>>>>>>>>>>> case
>>>>>>>>>>>> that has happened quite a bit.
>>>>>>>>>>>>
>>>>>>>>>>>> - a user reports a small bug and immediately wants to
>>>> provide a
>>>>>>>> fix
>>>>>>>>> for
>>>>>>>>>>>> it
>>>>>>>>>>>> - it makes sense to not stall the user for a few days
>>>>>>>>>>>> until a
>>>>>>>>> committer
>>>>>>>>>>>> assigned the issue
>>>>>>>>>>>> - not auto-closing the PR would at least allow the
>>>>>>>>>>>> user to
>>>>>>>> provide
>>>>>>>>>>> their
>>>>>>>>>>>> patch.
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen
>>>>>>>>>>>> <se...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>>>> +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 <
>>>> twalthr@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 <
>>>>>>>>>>> andrey@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 <
>>>>>>>> nemokingdom@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 <
>>>>>>>> rmetzger@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 <
>>>>>>>>>>>>>> andrey@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 <
>>>>>>>>>>>> rmetzger@apache.org
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I'm +1 on option 1.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
>>>>>>>>>>> twalthr@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 <
>>>>>>>>>>>>>>>> fhueske@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
>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>> twalthr@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 <
>>>>>>>>>>>>>>>>> wander4096@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 <rm...@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 <
>>>>>>>>>>>>>>>>>> sewen@apache.org>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to
>>>>>>>> infra.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
>>>>>>>>>>>>>>>>>>> wander4096@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 <ch...@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)
>>>>>>>>>>>>>>>>>
>>>>
>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Chesnay Schepler <ch...@apache.org>.
Sounds good to me.
On 18/07/2019 12:07, Robert Metzger wrote:
> Infra has finally changed the permissions. I just announced the change in a
> separate email [1].
>
> One thing I wanted to discuss here is, how do we want to handle all the
> "contributor permissions" requests?
>
> My proposal is to basically reject them with a nice message, pointing them
> to my announcement.
>
> What do you think?
>
>
>
> [1]
> https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
>
>
> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <rm...@apache.org> wrote:
>
>> This is the Jira ticket I opened
>> https://issues.apache.org/jira/browse/INFRA-18644 a long time ago :)
>>
>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <ch...@apache.org>
>> wrote:
>>
>>> @Robert what's the state here?
>>>
>>> On 24/06/2019 16:16, Robert Metzger wrote:
>>>> Hey all,
>>>>
>>>> I would like to drive this discussion to an end soon.
>>>> I've just merged the updated contribution guide to the Flink website:
>>>> https://flink.apache.org/contributing/contribute-code.html
>>>>
>>>> I will now ask Apache IINFRA to change the permissions in our Jira.
>>>>
>>>> Here's the updated TODO list:
>>>>
>>>> 1. I update the contribution guide DONE
>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
>>>> unassigned JIRAs IN PROGRESS
>>>> 3. We ask Infra to change the permissions of our JIRA so that: IN
>>> PROGRESS
>>>> a) only committers can assign users to tickets
>>>> b) contributors can't assign users to tickets
>>>> c) Every registered JIRA user is an assignable user in FLINK
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <rm...@apache.org>
>>> wrote:
>>>>> Hey,
>>>>>
>>>>> I started working on step 1 and proposed some changes to the Flink
>>>>> website: https://github.com/apache/flink-web/pull/217
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <rm...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Hi Fabian,
>>>>>> You are right, I made a mistake. I don't think it makes sense to
>>>>>> introduce a new permission class. This will make the life of JIRA
>>> admins
>>>>>> unnecessarily complicated.
>>>>>> I updated the task list:
>>>>>>
>>>>>> 1. I update the contribution guide
>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
>>>>>> unassigned JIRAs
>>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
>>>>>> a) only committers can assign users to tickets
>>>>>> b) contributors can't assign users to tickets
>>>>>> c) Every registered JIRA user is an assignable user in FLINK
>>>>>> 4. We remove all existing contributors
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <fh...@gmail.com>
>>> wrote:
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>> If I understood the decision correctly, we also need to ask Infra to
>>> make
>>>>>>> everybody an assignable user, right?
>>>>>>> Or do we want to add a new permission class "Assignable User" such
>>> that
>>>>>>> everyone still needs to ask for the right Jira permissions?
>>>>>>>
>>>>>>> Fabian
>>>>>>>
>>>>>>>
>>>>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
>>>>>>> twalthr@apache.org
>>>>>>>> :
>>>>>>>> Hi Robert,
>>>>>>>>
>>>>>>>> thanks for taking care of this. +1 to your suggested steps.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Timo
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
>>>>>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
>>>>>>>>> I will only do that for PRs without JIRA ID or "[hotfix]" in the
>>>>>>> title.
>>>>>>>>> We can always revisit this at a later stage.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm proposing the following steps:
>>>>>>>>>
>>>>>>>>> 1. I update the contribution guide
>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs
>>>>>>> with
>>>>>>>>> unassigned JIRAs
>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
>>>>>>>>> a) only committers can assign users to tickets
>>>>>>>>> b) contributors can't assign users to tickets
>>>>>>>>> 4. We remove all existing contributors
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang <ya...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>> also +1 for option 2.
>>>>>>>>>>
>>>>>>>>>> I think auto-close a PR sometimes a bit impertinency.
>>>>>>>>>> The reasons just like Stephan mentioned.
>>>>>>>>>>
>>>>>>>>>> Stephan Ewen <se...@apache.org> 于2019年4月24日周三 下午4:08写道：
>>>>>>>>>>
>>>>>>>>>>> About auto-closing PRs from unassigned issues, consider the
>>>>>>> following
>>>>>>>>>> case
>>>>>>>>>>> that has happened quite a bit.
>>>>>>>>>>>
>>>>>>>>>>> - a user reports a small bug and immediately wants to
>>> provide a
>>>>>>> fix
>>>>>>>> for
>>>>>>>>>>> it
>>>>>>>>>>> - it makes sense to not stall the user for a few days until a
>>>>>>>> committer
>>>>>>>>>>> assigned the issue
>>>>>>>>>>> - not auto-closing the PR would at least allow the user to
>>>>>>> provide
>>>>>>>>>> their
>>>>>>>>>>> patch.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen <se...@apache.org>
>>>>>>>> wrote:
>>>>>>>>>>>> +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 <
>>> twalthr@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 <
>>>>>>>>>> andrey@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 <
>>>>>>> nemokingdom@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 <
>>>>>>> rmetzger@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 <
>>>>>>>>>>>>> andrey@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 <
>>>>>>>>>>> rmetzger@apache.org
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm +1 on option 1.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
>>>>>>>>>> twalthr@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 <
>>>>>>>>>>>>>>> fhueske@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
>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>> twalthr@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 <
>>>>>>>>>>>>>>>> wander4096@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 <rm...@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 <
>>>>>>>>>>>>>>>>> sewen@apache.org>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to
>>>>>>> infra.
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
>>>>>>>>>>>>>>>>>> wander4096@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 <ch...@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)
>>>>>>>>>>>>>>>>
>>>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Robert Metzger <rm...@apache.org>.
Infra has finally changed the permissions. I just announced the change in a
separate email [1].
One thing I wanted to discuss here is, how do we want to handle all the
"contributor permissions" requests?
My proposal is to basically reject them with a nice message, pointing them
to my announcement.
What do you think?
[1]
https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <rm...@apache.org> wrote:
> This is the Jira ticket I opened
> https://issues.apache.org/jira/browse/INFRA-18644 a long time ago :)
>
> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <ch...@apache.org>
> wrote:
>
>> @Robert what's the state here?
>>
>> On 24/06/2019 16:16, Robert Metzger wrote:
>> > Hey all,
>> >
>> > I would like to drive this discussion to an end soon.
>> > I've just merged the updated contribution guide to the Flink website:
>> > https://flink.apache.org/contributing/contribute-code.html
>> >
>> > I will now ask Apache IINFRA to change the permissions in our Jira.
>> >
>> > Here's the updated TODO list:
>> >
>> > 1. I update the contribution guide DONE
>> > 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
>> > unassigned JIRAs IN PROGRESS
>> > 3. We ask Infra to change the permissions of our JIRA so that: IN
>> PROGRESS
>> > a) only committers can assign users to tickets
>> > b) contributors can't assign users to tickets
>> > c) Every registered JIRA user is an assignable user in FLINK
>> >
>> >
>> >
>> >
>> >
>> > On Fri, May 24, 2019 at 9:18 AM Robert Metzger <rm...@apache.org>
>> wrote:
>> >
>> >> Hey,
>> >>
>> >> I started working on step 1 and proposed some changes to the Flink
>> >> website: https://github.com/apache/flink-web/pull/217
>> >>
>> >>
>> >>
>> >> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <rm...@apache.org>
>> >> wrote:
>> >>
>> >>> Hi Fabian,
>> >>> You are right, I made a mistake. I don't think it makes sense to
>> >>> introduce a new permission class. This will make the life of JIRA
>> admins
>> >>> unnecessarily complicated.
>> >>> I updated the task list:
>> >>>
>> >>> 1. I update the contribution guide
>> >>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
>> >>> unassigned JIRAs
>> >>> 3. We ask Infra to change the permissions of our JIRA so that:
>> >>> a) only committers can assign users to tickets
>> >>> b) contributors can't assign users to tickets
>> >>> c) Every registered JIRA user is an assignable user in FLINK
>> >>> 4. We remove all existing contributors
>> >>>
>> >>>
>> >>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <fh...@gmail.com>
>> wrote:
>> >>>
>> >>>> Hi Robert,
>> >>>>
>> >>>> If I understood the decision correctly, we also need to ask Infra to
>> make
>> >>>> everybody an assignable user, right?
>> >>>> Or do we want to add a new permission class "Assignable User" such
>> that
>> >>>> everyone still needs to ask for the right Jira permissions?
>> >>>>
>> >>>> Fabian
>> >>>>
>> >>>>
>> >>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
>> >>>> twalthr@apache.org
>> >>>>> :
>> >>>>> Hi Robert,
>> >>>>>
>> >>>>> thanks for taking care of this. +1 to your suggested steps.
>> >>>>>
>> >>>>> Regards,
>> >>>>> Timo
>> >>>>>
>> >>>>>
>> >>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
>> >>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
>> >>>>>> I will only do that for PRs without JIRA ID or "[hotfix]" in the
>> >>>> title.
>> >>>>>> We can always revisit this at a later stage.
>> >>>>>>
>> >>>>>>
>> >>>>>> I'm proposing the following steps:
>> >>>>>>
>> >>>>>> 1. I update the contribution guide
>> >>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs
>> >>>> with
>> >>>>>> unassigned JIRAs
>> >>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
>> >>>>>> a) only committers can assign users to tickets
>> >>>>>> b) contributors can't assign users to tickets
>> >>>>>> 4. We remove all existing contributors
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang <ya...@gmail.com>
>> >>>>> wrote:
>> >>>>>>> also +1 for option 2.
>> >>>>>>>
>> >>>>>>> I think auto-close a PR sometimes a bit impertinency.
>> >>>>>>> The reasons just like Stephan mentioned.
>> >>>>>>>
>> >>>>>>> Stephan Ewen <se...@apache.org> 于2019年4月24日周三 下午4:08写道：
>> >>>>>>>
>> >>>>>>>> About auto-closing PRs from unassigned issues, consider the
>> >>>> following
>> >>>>>>> case
>> >>>>>>>> that has happened quite a bit.
>> >>>>>>>>
>> >>>>>>>> - a user reports a small bug and immediately wants to
>> provide a
>> >>>> fix
>> >>>>> for
>> >>>>>>>> it
>> >>>>>>>> - it makes sense to not stall the user for a few days until a
>> >>>>> committer
>> >>>>>>>> assigned the issue
>> >>>>>>>> - not auto-closing the PR would at least allow the user to
>> >>>> provide
>> >>>>>>> their
>> >>>>>>>> patch.
>> >>>>>>>>
>> >>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen <se...@apache.org>
>> >>>>> wrote:
>> >>>>>>>>> +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 <
>> twalthr@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 <
>> >>>>>>> andrey@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 <
>> >>>> nemokingdom@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 <
>> >>>> rmetzger@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 <
>> >>>>>>>>>> andrey@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 <
>> >>>>>>>> rmetzger@apache.org
>> >>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> I'm +1 on option 1.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
>> >>>>>>> twalthr@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 <
>> >>>>>>>>>>>> fhueske@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
>> >>>> <
>> >>>>>>>>>>>>>>>>>>> twalthr@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 <
>> >>>>>>>>>>>>> wander4096@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 <rm...@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 <
>> >>>>>>>>>>>>>> sewen@apache.org>
>> >>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to
>> >>>> infra.
>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
>> >>>>>>>>>>>>>>> wander4096@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 <ch...@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)
>> >>>>>>>>>>>>>
>> >>>>>
>>
>>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Robert Metzger <rm...@apache.org>.
This is the Jira ticket I opened
https://issues.apache.org/jira/browse/INFRA-18644 a long time ago :)
On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <ch...@apache.org> wrote:
> @Robert what's the state here?
>
> On 24/06/2019 16:16, Robert Metzger wrote:
> > Hey all,
> >
> > I would like to drive this discussion to an end soon.
> > I've just merged the updated contribution guide to the Flink website:
> > https://flink.apache.org/contributing/contribute-code.html
> >
> > I will now ask Apache IINFRA to change the permissions in our Jira.
> >
> > Here's the updated TODO list:
> >
> > 1. I update the contribution guide DONE
> > 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
> > unassigned JIRAs IN PROGRESS
> > 3. We ask Infra to change the permissions of our JIRA so that: IN
> PROGRESS
> > a) only committers can assign users to tickets
> > b) contributors can't assign users to tickets
> > c) Every registered JIRA user is an assignable user in FLINK
> >
> >
> >
> >
> >
> > On Fri, May 24, 2019 at 9:18 AM Robert Metzger <rm...@apache.org>
> wrote:
> >
> >> Hey,
> >>
> >> I started working on step 1 and proposed some changes to the Flink
> >> website: https://github.com/apache/flink-web/pull/217
> >>
> >>
> >>
> >> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <rm...@apache.org>
> >> wrote:
> >>
> >>> Hi Fabian,
> >>> You are right, I made a mistake. I don't think it makes sense to
> >>> introduce a new permission class. This will make the life of JIRA
> admins
> >>> unnecessarily complicated.
> >>> I updated the task list:
> >>>
> >>> 1. I update the contribution guide
> >>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
> >>> unassigned JIRAs
> >>> 3. We ask Infra to change the permissions of our JIRA so that:
> >>> a) only committers can assign users to tickets
> >>> b) contributors can't assign users to tickets
> >>> c) Every registered JIRA user is an assignable user in FLINK
> >>> 4. We remove all existing contributors
> >>>
> >>>
> >>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <fh...@gmail.com>
> wrote:
> >>>
> >>>> Hi Robert,
> >>>>
> >>>> If I understood the decision correctly, we also need to ask Infra to
> make
> >>>> everybody an assignable user, right?
> >>>> Or do we want to add a new permission class "Assignable User" such
> that
> >>>> everyone still needs to ask for the right Jira permissions?
> >>>>
> >>>> Fabian
> >>>>
> >>>>
> >>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
> >>>> twalthr@apache.org
> >>>>> :
> >>>>> Hi Robert,
> >>>>>
> >>>>> thanks for taking care of this. +1 to your suggested steps.
> >>>>>
> >>>>> Regards,
> >>>>> Timo
> >>>>>
> >>>>>
> >>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
> >>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
> >>>>>> I will only do that for PRs without JIRA ID or "[hotfix]" in the
> >>>> title.
> >>>>>> We can always revisit this at a later stage.
> >>>>>>
> >>>>>>
> >>>>>> I'm proposing the following steps:
> >>>>>>
> >>>>>> 1. I update the contribution guide
> >>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs
> >>>> with
> >>>>>> unassigned JIRAs
> >>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
> >>>>>> a) only committers can assign users to tickets
> >>>>>> b) contributors can't assign users to tickets
> >>>>>> 4. We remove all existing contributors
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang <ya...@gmail.com>
> >>>>> wrote:
> >>>>>>> also +1 for option 2.
> >>>>>>>
> >>>>>>> I think auto-close a PR sometimes a bit impertinency.
> >>>>>>> The reasons just like Stephan mentioned.
> >>>>>>>
> >>>>>>> Stephan Ewen <se...@apache.org> 于2019年4月24日周三 下午4:08写道：
> >>>>>>>
> >>>>>>>> About auto-closing PRs from unassigned issues, consider the
> >>>> following
> >>>>>>> case
> >>>>>>>> that has happened quite a bit.
> >>>>>>>>
> >>>>>>>> - a user reports a small bug and immediately wants to provide
> a
> >>>> fix
> >>>>> for
> >>>>>>>> it
> >>>>>>>> - it makes sense to not stall the user for a few days until a
> >>>>> committer
> >>>>>>>> assigned the issue
> >>>>>>>> - not auto-closing the PR would at least allow the user to
> >>>> provide
> >>>>>>> their
> >>>>>>>> patch.
> >>>>>>>>
> >>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen <se...@apache.org>
> >>>>> wrote:
> >>>>>>>>> +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 <twalthr@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 <
> >>>>>>> andrey@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 <
> >>>> nemokingdom@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 <
> >>>> rmetzger@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 <
> >>>>>>>>>> andrey@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 <
> >>>>>>>> rmetzger@apache.org
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I'm +1 on option 1.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
> >>>>>>> twalthr@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 <
> >>>>>>>>>>>> fhueske@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
> >>>> <
> >>>>>>>>>>>>>>>>>>> twalthr@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 <
> >>>>>>>>>>>>> wander4096@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 <rm...@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 <
> >>>>>>>>>>>>>> sewen@apache.org>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to
> >>>> infra.
> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
> >>>>>>>>>>>>>>> wander4096@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 <ch...@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)
> >>>>>>>>>>>>>
> >>>>>
>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Chesnay Schepler <ch...@apache.org>.
@Robert what's the state here?
On 24/06/2019 16:16, Robert Metzger wrote:
> Hey all,
>
> I would like to drive this discussion to an end soon.
> I've just merged the updated contribution guide to the Flink website:
> https://flink.apache.org/contributing/contribute-code.html
>
> I will now ask Apache IINFRA to change the permissions in our Jira.
>
> Here's the updated TODO list:
>
> 1. I update the contribution guide DONE
> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
> unassigned JIRAs IN PROGRESS
> 3. We ask Infra to change the permissions of our JIRA so that: IN PROGRESS
> a) only committers can assign users to tickets
> b) contributors can't assign users to tickets
> c) Every registered JIRA user is an assignable user in FLINK
>
>
>
>
>
> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <rm...@apache.org> wrote:
>
>> Hey,
>>
>> I started working on step 1 and proposed some changes to the Flink
>> website: https://github.com/apache/flink-web/pull/217
>>
>>
>>
>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <rm...@apache.org>
>> wrote:
>>
>>> Hi Fabian,
>>> You are right, I made a mistake. I don't think it makes sense to
>>> introduce a new permission class. This will make the life of JIRA admins
>>> unnecessarily complicated.
>>> I updated the task list:
>>>
>>> 1. I update the contribution guide
>>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
>>> unassigned JIRAs
>>> 3. We ask Infra to change the permissions of our JIRA so that:
>>> a) only committers can assign users to tickets
>>> b) contributors can't assign users to tickets
>>> c) Every registered JIRA user is an assignable user in FLINK
>>> 4. We remove all existing contributors
>>>
>>>
>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <fh...@gmail.com> wrote:
>>>
>>>> Hi Robert,
>>>>
>>>> If I understood the decision correctly, we also need to ask Infra to make
>>>> everybody an assignable user, right?
>>>> Or do we want to add a new permission class "Assignable User" such that
>>>> everyone still needs to ask for the right Jira permissions?
>>>>
>>>> Fabian
>>>>
>>>>
>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
>>>> twalthr@apache.org
>>>>> :
>>>>> Hi Robert,
>>>>>
>>>>> thanks for taking care of this. +1 to your suggested steps.
>>>>>
>>>>> Regards,
>>>>> Timo
>>>>>
>>>>>
>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
>>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
>>>>>> I will only do that for PRs without JIRA ID or "[hotfix]" in the
>>>> title.
>>>>>> We can always revisit this at a later stage.
>>>>>>
>>>>>>
>>>>>> I'm proposing the following steps:
>>>>>>
>>>>>> 1. I update the contribution guide
>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs
>>>> with
>>>>>> unassigned JIRAs
>>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
>>>>>> a) only committers can assign users to tickets
>>>>>> b) contributors can't assign users to tickets
>>>>>> 4. We remove all existing contributors
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang <ya...@gmail.com>
>>>>> wrote:
>>>>>>> also +1 for option 2.
>>>>>>>
>>>>>>> I think auto-close a PR sometimes a bit impertinency.
>>>>>>> The reasons just like Stephan mentioned.
>>>>>>>
>>>>>>> Stephan Ewen <se...@apache.org> 于2019年4月24日周三 下午4:08写道：
>>>>>>>
>>>>>>>> About auto-closing PRs from unassigned issues, consider the
>>>> following
>>>>>>> case
>>>>>>>> that has happened quite a bit.
>>>>>>>>
>>>>>>>> - a user reports a small bug and immediately wants to provide a
>>>> fix
>>>>> for
>>>>>>>> it
>>>>>>>> - it makes sense to not stall the user for a few days until a
>>>>> committer
>>>>>>>> assigned the issue
>>>>>>>> - not auto-closing the PR would at least allow the user to
>>>> provide
>>>>>>> their
>>>>>>>> patch.
>>>>>>>>
>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen <se...@apache.org>
>>>>> wrote:
>>>>>>>>> +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 <tw...@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 <
>>>>>>> andrey@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 <
>>>> nemokingdom@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 <
>>>> rmetzger@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 <
>>>>>>>>>> andrey@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 <
>>>>>>>> rmetzger@apache.org
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm +1 on option 1.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
>>>>>>> twalthr@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 <
>>>>>>>>>>>> fhueske@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
>>>> <
>>>>>>>>>>>>>>>>>>> twalthr@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 <
>>>>>>>>>>>>> wander4096@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 <rm...@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 <
>>>>>>>>>>>>>> sewen@apache.org>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to
>>>> infra.
>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
>>>>>>>>>>>>>>> wander4096@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 <ch...@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)
>>>>>>>>>>>>>
>>>>>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Robert Metzger <rm...@apache.org>.
Hey all,
I would like to drive this discussion to an end soon.
I've just merged the updated contribution guide to the Flink website:
https://flink.apache.org/contributing/contribute-code.html
I will now ask Apache IINFRA to change the permissions in our Jira.
Here's the updated TODO list:
1. I update the contribution guide DONE
2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
unassigned JIRAs IN PROGRESS
3. We ask Infra to change the permissions of our JIRA so that: IN PROGRESS
a) only committers can assign users to tickets
b) contributors can't assign users to tickets
c) Every registered JIRA user is an assignable user in FLINK
On Fri, May 24, 2019 at 9:18 AM Robert Metzger <rm...@apache.org> wrote:
> Hey,
>
> I started working on step 1 and proposed some changes to the Flink
> website: https://github.com/apache/flink-web/pull/217
>
>
>
> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <rm...@apache.org>
> wrote:
>
>> Hi Fabian,
>> You are right, I made a mistake. I don't think it makes sense to
>> introduce a new permission class. This will make the life of JIRA admins
>> unnecessarily complicated.
>> I updated the task list:
>>
>> 1. I update the contribution guide
>> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
>> unassigned JIRAs
>> 3. We ask Infra to change the permissions of our JIRA so that:
>> a) only committers can assign users to tickets
>> b) contributors can't assign users to tickets
>> c) Every registered JIRA user is an assignable user in FLINK
>> 4. We remove all existing contributors
>>
>>
>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <fh...@gmail.com> wrote:
>>
>>> Hi Robert,
>>>
>>> If I understood the decision correctly, we also need to ask Infra to make
>>> everybody an assignable user, right?
>>> Or do we want to add a new permission class "Assignable User" such that
>>> everyone still needs to ask for the right Jira permissions?
>>>
>>> Fabian
>>>
>>>
>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
>>> twalthr@apache.org
>>> >:
>>>
>>> > Hi Robert,
>>> >
>>> > thanks for taking care of this. +1 to your suggested steps.
>>> >
>>> > Regards,
>>> > Timo
>>> >
>>> >
>>> > Am 30.04.19 um 10:42 schrieb Robert Metzger:
>>> > > @Stephan: I agree. Auto-closing PRs is quite aggressive.
>>> > > I will only do that for PRs without JIRA ID or "[hotfix]" in the
>>> title.
>>> > > We can always revisit this at a later stage.
>>> > >
>>> > >
>>> > > I'm proposing the following steps:
>>> > >
>>> > > 1. I update the contribution guide
>>> > > 2. Update Flinkbot to close invalid PRs, and show warnings on PRs
>>> with
>>> > > unassigned JIRAs
>>> > > 3. We ask Infra to change the permissions of our JIRA so that:
>>> > > a) only committers can assign users to tickets
>>> > > b) contributors can't assign users to tickets
>>> > > 4. We remove all existing contributors
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > On Wed, Apr 24, 2019 at 11:17 AM vino yang <ya...@gmail.com>
>>> > wrote:
>>> > >
>>> > >> also +1 for option 2.
>>> > >>
>>> > >> I think auto-close a PR sometimes a bit impertinency.
>>> > >> The reasons just like Stephan mentioned.
>>> > >>
>>> > >> Stephan Ewen <se...@apache.org> 于2019年4月24日周三 下午4:08写道：
>>> > >>
>>> > >>> About auto-closing PRs from unassigned issues, consider the
>>> following
>>> > >> case
>>> > >>> that has happened quite a bit.
>>> > >>>
>>> > >>> - a user reports a small bug and immediately wants to provide a
>>> fix
>>> > for
>>> > >>> it
>>> > >>> - it makes sense to not stall the user for a few days until a
>>> > committer
>>> > >>> assigned the issue
>>> > >>> - not auto-closing the PR would at least allow the user to
>>> provide
>>> > >> their
>>> > >>> patch.
>>> > >>>
>>> > >>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen <se...@apache.org>
>>> > wrote:
>>> > >>>
>>> > >>>> +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 <tw...@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 <
>>> > >> andrey@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 <
>>> nemokingdom@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 <
>>> rmetzger@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 <
>>> > >>>>> andrey@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 <
>>> > >>> rmetzger@apache.org
>>> > >>>>>>>>>> wrote:
>>> > >>>>>>>>>>
>>> > >>>>>>>>>>> I'm +1 on option 1.
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
>>> > >> twalthr@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 <
>>> > >>>>>>> fhueske@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
>>> <
>>> > >>>>>>>>>>>>>> twalthr@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 <
>>> > >>>>>>>> wander4096@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 <rm...@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 <
>>> > >>>>>>>>> sewen@apache.org>
>>> > >>>>>>>>>>>>>> wrote:
>>> > >>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to
>>> infra.
>>> > >>>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
>>> > >>>>>>>>>> wander4096@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 <ch...@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)
>>> > >>>>>>>>
>>> > >>>>>
>>> >
>>> >
>>>
>>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Robert Metzger <rm...@apache.org>.
Hey,
I started working on step 1 and proposed some changes to the Flink website:
https://github.com/apache/flink-web/pull/217
On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <rm...@apache.org> wrote:
> Hi Fabian,
> You are right, I made a mistake. I don't think it makes sense to introduce
> a new permission class. This will make the life of JIRA admins
> unnecessarily complicated.
> I updated the task list:
>
> 1. I update the contribution guide
> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
> unassigned JIRAs
> 3. We ask Infra to change the permissions of our JIRA so that:
> a) only committers can assign users to tickets
> b) contributors can't assign users to tickets
> c) Every registered JIRA user is an assignable user in FLINK
> 4. We remove all existing contributors
>
>
> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <fh...@gmail.com> wrote:
>
>> Hi Robert,
>>
>> If I understood the decision correctly, we also need to ask Infra to make
>> everybody an assignable user, right?
>> Or do we want to add a new permission class "Assignable User" such that
>> everyone still needs to ask for the right Jira permissions?
>>
>> Fabian
>>
>>
>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
>> twalthr@apache.org
>> >:
>>
>> > Hi Robert,
>> >
>> > thanks for taking care of this. +1 to your suggested steps.
>> >
>> > Regards,
>> > Timo
>> >
>> >
>> > Am 30.04.19 um 10:42 schrieb Robert Metzger:
>> > > @Stephan: I agree. Auto-closing PRs is quite aggressive.
>> > > I will only do that for PRs without JIRA ID or "[hotfix]" in the
>> title.
>> > > We can always revisit this at a later stage.
>> > >
>> > >
>> > > I'm proposing the following steps:
>> > >
>> > > 1. I update the contribution guide
>> > > 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
>> > > unassigned JIRAs
>> > > 3. We ask Infra to change the permissions of our JIRA so that:
>> > > a) only committers can assign users to tickets
>> > > b) contributors can't assign users to tickets
>> > > 4. We remove all existing contributors
>> > >
>> > >
>> > >
>> > >
>> > > On Wed, Apr 24, 2019 at 11:17 AM vino yang <ya...@gmail.com>
>> > wrote:
>> > >
>> > >> also +1 for option 2.
>> > >>
>> > >> I think auto-close a PR sometimes a bit impertinency.
>> > >> The reasons just like Stephan mentioned.
>> > >>
>> > >> Stephan Ewen <se...@apache.org> 于2019年4月24日周三 下午4:08写道：
>> > >>
>> > >>> About auto-closing PRs from unassigned issues, consider the
>> following
>> > >> case
>> > >>> that has happened quite a bit.
>> > >>>
>> > >>> - a user reports a small bug and immediately wants to provide a
>> fix
>> > for
>> > >>> it
>> > >>> - it makes sense to not stall the user for a few days until a
>> > committer
>> > >>> assigned the issue
>> > >>> - not auto-closing the PR would at least allow the user to
>> provide
>> > >> their
>> > >>> patch.
>> > >>>
>> > >>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen <se...@apache.org>
>> > wrote:
>> > >>>
>> > >>>> +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 <tw...@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 <
>> > >> andrey@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 <nemokingdom@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 <
>> rmetzger@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 <
>> > >>>>> andrey@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 <
>> > >>> rmetzger@apache.org
>> > >>>>>>>>>> wrote:
>> > >>>>>>>>>>
>> > >>>>>>>>>>> I'm +1 on option 1.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
>> > >> twalthr@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 <
>> > >>>>>>> fhueske@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 <
>> > >>>>>>>>>>>>>> twalthr@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 <
>> > >>>>>>>> wander4096@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 <rm...@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 <
>> > >>>>>>>>> sewen@apache.org>
>> > >>>>>>>>>>>>>> wrote:
>> > >>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to
>> infra.
>> > >>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
>> > >>>>>>>>>> wander4096@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 <ch...@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)
>> > >>>>>>>>
>> > >>>>>
>> >
>> >
>>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Robert Metzger <rm...@apache.org>.
Hi Fabian,
You are right, I made a mistake. I don't think it makes sense to introduce
a new permission class. This will make the life of JIRA admins
unnecessarily complicated.
I updated the task list:
1. I update the contribution guide
2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
unassigned JIRAs
3. We ask Infra to change the permissions of our JIRA so that:
a) only committers can assign users to tickets
b) contributors can't assign users to tickets
c) Every registered JIRA user is an assignable user in FLINK
4. We remove all existing contributors
On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <fh...@gmail.com> wrote:
> Hi Robert,
>
> If I understood the decision correctly, we also need to ask Infra to make
> everybody an assignable user, right?
> Or do we want to add a new permission class "Assignable User" such that
> everyone still needs to ask for the right Jira permissions?
>
> Fabian
>
>
> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
> twalthr@apache.org
> >:
>
> > Hi Robert,
> >
> > thanks for taking care of this. +1 to your suggested steps.
> >
> > Regards,
> > Timo
> >
> >
> > Am 30.04.19 um 10:42 schrieb Robert Metzger:
> > > @Stephan: I agree. Auto-closing PRs is quite aggressive.
> > > I will only do that for PRs without JIRA ID or "[hotfix]" in the title.
> > > We can always revisit this at a later stage.
> > >
> > >
> > > I'm proposing the following steps:
> > >
> > > 1. I update the contribution guide
> > > 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
> > > unassigned JIRAs
> > > 3. We ask Infra to change the permissions of our JIRA so that:
> > > a) only committers can assign users to tickets
> > > b) contributors can't assign users to tickets
> > > 4. We remove all existing contributors
> > >
> > >
> > >
> > >
> > > On Wed, Apr 24, 2019 at 11:17 AM vino yang <ya...@gmail.com>
> > wrote:
> > >
> > >> also +1 for option 2.
> > >>
> > >> I think auto-close a PR sometimes a bit impertinency.
> > >> The reasons just like Stephan mentioned.
> > >>
> > >> Stephan Ewen <se...@apache.org> 于2019年4月24日周三 下午4:08写道：
> > >>
> > >>> About auto-closing PRs from unassigned issues, consider the following
> > >> case
> > >>> that has happened quite a bit.
> > >>>
> > >>> - a user reports a small bug and immediately wants to provide a
> fix
> > for
> > >>> it
> > >>> - it makes sense to not stall the user for a few days until a
> > committer
> > >>> assigned the issue
> > >>> - not auto-closing the PR would at least allow the user to provide
> > >> their
> > >>> patch.
> > >>>
> > >>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen <se...@apache.org>
> > wrote:
> > >>>
> > >>>> +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 <tw...@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 <
> > >> andrey@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 <ne...@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 <
> rmetzger@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 <
> > >>>>> andrey@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 <
> > >>> rmetzger@apache.org
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> I'm +1 on option 1.
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
> > >> twalthr@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 <
> > >>>>>>> fhueske@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 <
> > >>>>>>>>>>>>>> twalthr@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 <
> > >>>>>>>> wander4096@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 <rm...@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 <
> > >>>>>>>>> sewen@apache.org>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to infra.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
> > >>>>>>>>>> wander4096@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 <ch...@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)
> > >>>>>>>>
> > >>>>>
> >
> >
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Fabian Hueske <fh...@gmail.com>.
Hi Robert,
If I understood the decision correctly, we also need to ask Infra to make
everybody an assignable user, right?
Or do we want to add a new permission class "Assignable User" such that
everyone still needs to ask for the right Jira permissions?
Fabian
Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <twalthr@apache.org
>:
> Hi Robert,
>
> thanks for taking care of this. +1 to your suggested steps.
>
> Regards,
> Timo
>
>
> Am 30.04.19 um 10:42 schrieb Robert Metzger:
> > @Stephan: I agree. Auto-closing PRs is quite aggressive.
> > I will only do that for PRs without JIRA ID or "[hotfix]" in the title.
> > We can always revisit this at a later stage.
> >
> >
> > I'm proposing the following steps:
> >
> > 1. I update the contribution guide
> > 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
> > unassigned JIRAs
> > 3. We ask Infra to change the permissions of our JIRA so that:
> > a) only committers can assign users to tickets
> > b) contributors can't assign users to tickets
> > 4. We remove all existing contributors
> >
> >
> >
> >
> > On Wed, Apr 24, 2019 at 11:17 AM vino yang <ya...@gmail.com>
> wrote:
> >
> >> also +1 for option 2.
> >>
> >> I think auto-close a PR sometimes a bit impertinency.
> >> The reasons just like Stephan mentioned.
> >>
> >> Stephan Ewen <se...@apache.org> 于2019年4月24日周三 下午4:08写道：
> >>
> >>> About auto-closing PRs from unassigned issues, consider the following
> >> case
> >>> that has happened quite a bit.
> >>>
> >>> - a user reports a small bug and immediately wants to provide a fix
> for
> >>> it
> >>> - it makes sense to not stall the user for a few days until a
> committer
> >>> assigned the issue
> >>> - not auto-closing the PR would at least allow the user to provide
> >> their
> >>> patch.
> >>>
> >>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen <se...@apache.org>
> wrote:
> >>>
> >>>> +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 <tw...@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 <
> >> andrey@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 <ne...@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 <rmetzger@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 <
> >>>>> andrey@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 <
> >>> rmetzger@apache.org
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I'm +1 on option 1.
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
> >> twalthr@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 <
> >>>>>>> fhueske@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 <
> >>>>>>>>>>>>>> twalthr@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 <
> >>>>>>>> wander4096@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 <rm...@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 <
> >>>>>>>>> sewen@apache.org>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to infra.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
> >>>>>>>>>> wander4096@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 <ch...@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)
> >>>>>>>>
> >>>>>
>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Timo Walther <tw...@apache.org>.
Hi Robert,
thanks for taking care of this. +1 to your suggested steps.
Regards,
Timo
Am 30.04.19 um 10:42 schrieb Robert Metzger:
> @Stephan: I agree. Auto-closing PRs is quite aggressive.
> I will only do that for PRs without JIRA ID or "[hotfix]" in the title.
> We can always revisit this at a later stage.
>
>
> I'm proposing the following steps:
>
> 1. I update the contribution guide
> 2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
> unassigned JIRAs
> 3. We ask Infra to change the permissions of our JIRA so that:
> a) only committers can assign users to tickets
> b) contributors can't assign users to tickets
> 4. We remove all existing contributors
>
>
>
>
> On Wed, Apr 24, 2019 at 11:17 AM vino yang <ya...@gmail.com> wrote:
>
>> also +1 for option 2.
>>
>> I think auto-close a PR sometimes a bit impertinency.
>> The reasons just like Stephan mentioned.
>>
>> Stephan Ewen <se...@apache.org> 于2019年4月24日周三 下午4:08写道：
>>
>>> About auto-closing PRs from unassigned issues, consider the following
>> case
>>> that has happened quite a bit.
>>>
>>> - a user reports a small bug and immediately wants to provide a fix for
>>> it
>>> - it makes sense to not stall the user for a few days until a committer
>>> assigned the issue
>>> - not auto-closing the PR would at least allow the user to provide
>> their
>>> patch.
>>>
>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen <se...@apache.org> wrote:
>>>
>>>> +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 <tw...@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 <
>> andrey@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 <ne...@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 <rmetzger@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 <
>>>>> andrey@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 <
>>> rmetzger@apache.org
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I'm +1 on option 1.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
>> twalthr@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 <
>>>>>>> fhueske@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 <
>>>>>>>>>>>>>> twalthr@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 <
>>>>>>>> wander4096@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 <rm...@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 <
>>>>>>>>> sewen@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to infra.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
>>>>>>>>>> wander4096@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 <ch...@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)
>>>>>>>>
>>>>>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Robert Metzger <rm...@apache.org>.
@Stephan: I agree. Auto-closing PRs is quite aggressive.
I will only do that for PRs without JIRA ID or "[hotfix]" in the title.
We can always revisit this at a later stage.
I'm proposing the following steps:
1. I update the contribution guide
2. Update Flinkbot to close invalid PRs, and show warnings on PRs with
unassigned JIRAs
3. We ask Infra to change the permissions of our JIRA so that:
a) only committers can assign users to tickets
b) contributors can't assign users to tickets
4. We remove all existing contributors
On Wed, Apr 24, 2019 at 11:17 AM vino yang <ya...@gmail.com> wrote:
> also +1 for option 2.
>
> I think auto-close a PR sometimes a bit impertinency.
> The reasons just like Stephan mentioned.
>
> Stephan Ewen <se...@apache.org> 于2019年4月24日周三 下午4:08写道：
>
> > About auto-closing PRs from unassigned issues, consider the following
> case
> > that has happened quite a bit.
> >
> > - a user reports a small bug and immediately wants to provide a fix for
> > it
> > - it makes sense to not stall the user for a few days until a committer
> > assigned the issue
> > - not auto-closing the PR would at least allow the user to provide
> their
> > patch.
> >
> > On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen <se...@apache.org> wrote:
> >
> > > +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 <tw...@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 <
> andrey@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 <ne...@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 <rmetzger@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 <
> > >> andrey@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 <
> > rmetzger@apache.org
> > >> >
> > >> >>>>> wrote:
> > >> >>>>>
> > >> >>>>>> I'm +1 on option 1.
> > >> >>>>>>
> > >> >>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
> twalthr@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 <
> > >> >> fhueske@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 <
> > >> >>>>>>>>> twalthr@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 <
> > >> >>> wander4096@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 <rm...@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 <
> > >> >>>> sewen@apache.org>
> > >> >>>>>>>>> wrote:
> > >> >>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to infra.
> > >> >>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
> > >> >>>>> wander4096@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 <ch...@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)
> > >> >>>
> > >> >
> > >>
> > >>
> >
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by vino yang <ya...@gmail.com>.
also +1 for option 2.
I think auto-close a PR sometimes a bit impertinency.
The reasons just like Stephan mentioned.
Stephan Ewen <se...@apache.org> 于2019年4月24日周三 下午4:08写道：
> About auto-closing PRs from unassigned issues, consider the following case
> that has happened quite a bit.
>
> - a user reports a small bug and immediately wants to provide a fix for
> it
> - it makes sense to not stall the user for a few days until a committer
> assigned the issue
> - not auto-closing the PR would at least allow the user to provide their
> patch.
>
> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen <se...@apache.org> wrote:
>
> > +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 <tw...@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 <andrey@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 <ne...@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 <rm...@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 <
> >> andrey@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 <
> rmetzger@apache.org
> >> >
> >> >>>>> wrote:
> >> >>>>>
> >> >>>>>> I'm +1 on option 1.
> >> >>>>>>
> >> >>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <tw...@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 <
> >> >> fhueske@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 <
> >> >>>>>>>>> twalthr@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 <
> >> >>> wander4096@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 <rm...@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 <
> >> >>>> sewen@apache.org>
> >> >>>>>>>>> wrote:
> >> >>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to infra.
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
> >> >>>>> wander4096@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 <ch...@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)
> >> >>>
> >> >
> >>
> >>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Stephan Ewen <se...@apache.org>.
About auto-closing PRs from unassigned issues, consider the following case
that has happened quite a bit.
- a user reports a small bug and immediately wants to provide a fix for it
- it makes sense to not stall the user for a few days until a committer
assigned the issue
- not auto-closing the PR would at least allow the user to provide their
patch.
On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen <se...@apache.org> wrote:
> +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 <tw...@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 <an...@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 <ne...@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 <rm...@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 <
>> andrey@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 <rmetzger@apache.org
>> >
>> >>>>> wrote:
>> >>>>>
>> >>>>>> I'm +1 on option 1.
>> >>>>>>
>> >>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <tw...@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 <
>> >> fhueske@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 <
>> >>>>>>>>> twalthr@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 <
>> >>> wander4096@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 <rm...@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 <
>> >>>> sewen@apache.org>
>> >>>>>>>>> wrote:
>> >>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to infra.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
>> >>>>> wander4096@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 <ch...@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)
>> >>>
>> >
>>
>>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Stephan Ewen <se...@apache.org>.
+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 <tw...@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 <an...@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 <ne...@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 <rm...@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 <
> andrey@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 <rm...@apache.org>
> >>>>> wrote:
> >>>>>
> >>>>>> I'm +1 on option 1.
> >>>>>>
> >>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <tw...@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 <
> >> fhueske@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 <
> >>>>>>>>> twalthr@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 <
> >>> wander4096@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 <rm...@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 <
> >>>> sewen@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to infra.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
> >>>>> wander4096@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 <ch...@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)
> >>>
> >
>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Timo Walther <tw...@apache.org>.
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 <an...@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 <ne...@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 <rm...@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 <andrey@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 <rm...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> I'm +1 on option 1.
>>>>>>
>>>>>> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <tw...@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 <
>> fhueske@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 <
>>>>>>>>> twalthr@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 <
>>> wander4096@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 <rm...@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 <
>>>> sewen@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>>>>> @Chesnay - yes, this is possible, according to infra.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
>>>>> wander4096@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 <ch...@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)
>>>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Konstantin Knauf <ko...@ververica.com>.
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 <an...@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 <ne...@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 <rm...@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 <andrey@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 <rm...@apache.org>
> > > > wrote:
> > > >
> > > > > I'm +1 on option 1.
> > > > >
> > > > > On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <tw...@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 <
> fhueske@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 <
> > > > > > >> twalthr@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 <
> > wander4096@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 <rm...@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 <
> > > sewen@apache.org>
> > > > > > >> wrote:
> > > > > > >>>>>>> @Chesnay - yes, this is possible, according to infra.
> > > > > > >>>>>>>
> > > > > > >>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
> > > > wander4096@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 <ch...@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)
> >
>
--
Konstantin Knauf | Solutions Architect
+49 160 91394525
<https://www.ververica.com/>
Follow us @VervericaData
--
Join Flink Forward <https://flink-forward.org/> - The Apache Flink
Conference
Stream Processing | Event Driven | Real Time
--
Data Artisans GmbH | Invalidenstrasse 115, 10115 Berlin, Germany
--
Data Artisans GmbH
Registered at Amtsgericht Charlottenburg: HRB 158244 B
Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Andrey Zagrebin <an...@ververica.com>.
@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 <ne...@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 <rm...@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 <an...@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 <rm...@apache.org>
> > > wrote:
> > >
> > > > I'm +1 on option 1.
> > > >
> > > > On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <tw...@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 <fhueske@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 <
> > > > > >> twalthr@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 <
> wander4096@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 <rm...@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 <
> > sewen@apache.org>
> > > > > >> wrote:
> > > > > >>>>>>> @Chesnay - yes, this is possible, according to infra.
> > > > > >>>>>>>
> > > > > >>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
> > > wander4096@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 <ch...@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)
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Feng LI <ne...@gmail.com>.
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 <rm...@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 <an...@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 <rm...@apache.org>
> > wrote:
> >
> > > I'm +1 on option 1.
> > >
> > > On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <tw...@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 <fh...@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 <
> > > > >> twalthr@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 <wander4096@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 <rm...@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 <
> sewen@apache.org>
> > > > >> wrote:
> > > > >>>>>>> @Chesnay - yes, this is possible, according to infra.
> > > > >>>>>>>
> > > > >>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
> > wander4096@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 <ch...@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)
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Robert Metzger <rm...@apache.org>.
@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 <an...@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 <rm...@apache.org>
> wrote:
>
> > I'm +1 on option 1.
> >
> > On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <tw...@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 <fh...@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 <
> > > >> twalthr@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 <wa...@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 <rm...@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 <
> wander4096@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 <ch...@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
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>
> > >
> > >
> >
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Andrey Zagrebin <an...@ververica.com>.
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 <rm...@apache.org> wrote:
> I'm +1 on option 1.
>
> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <tw...@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 <fh...@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 <
> > >> twalthr@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 <wa...@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 <rm...@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 <wander4096@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 <ch...@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
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>
> >
> >
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Robert Metzger <rm...@apache.org>.
I'm +1 on option 1.
On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <tw...@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 <fh...@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 <
> >> twalthr@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 <wa...@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 <rm...@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 <wa...@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 <ch...@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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>
>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Timo Walther <tw...@apache.org>.
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 <fh...@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 <
>> twalthr@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 <wa...@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 <rm...@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 <wa...@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 <ch...@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
>>>>>>>>>>
>>>>>>>>>>
>>>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Robert Metzger <rm...@apache.org>.
@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 <fh...@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 <
> twalthr@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 <wa...@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 <rm...@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 <wa...@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 <ch...@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
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> >
> >
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Fabian Hueske <fh...@gmail.com>.
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 <twalthr@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 <wa...@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 <rm...@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 <wa...@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 <ch...@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
> >>>>>>>
> >>>>>>>
> >>>>>>
>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Timo Walther <tw...@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 <wa...@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 <rm...@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 <wa...@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 <ch...@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
>>>>>>>
>>>>>>>
>>>>>>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Robert Metzger <rm...@apache.org>.
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 <wa...@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 <rm...@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 <wa...@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 <ch...@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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by ZiLi Chen <wa...@gmail.com>.
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 <rm...@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 <wa...@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 <ch...@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
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Robert Metzger <rm...@apache.org>.
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 <wa...@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 <ch...@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
> > > >
> > > >
> > >
> > >
> >
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Stephan Ewen <se...@apache.org>.
@Chesnay - yes, this is possible, according to infra.
On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <wa...@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 <ch...@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
> > >
> > >
> >
> >
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by ZiLi Chen <wa...@gmail.com>.
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 <ch...@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
> >
> >
>
>
Re: [DISCUSS] A more restrictive JIRA workflow
Posted by Chesnay Schepler <ch...@apache.org>.
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
>
>