[DISCUSS] A more restrictive JIRA workflow

[Timo Walther-2]

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

[Kostas Kloudas-4]

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 <[hidden email]> 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
>
>

[dwysakowicz]

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 [hidden email] 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

[Stephan Ewen]

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 <[hidden email]>
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 <[hidden email]> <[hidden email]> 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
>
>

[Hequn Cheng]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> <
> [hidden email]> 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
> >
> >
>

[Chesnay Schepler-3]

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

[tison]

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 <[hidden email]> 于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
> >
> >
>
>

[Stephan Ewen]

@Chesnay - yes, this is possible, according to infra.

On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <[hidden email]> 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 <[hidden email]> 于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
> > >
> > >
> >
> >
>

[Robert Metzger]

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 <[hidden email]> wrote:

> @Chesnay - yes, this is possible, according to infra.
>
> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <[hidden email]> 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 <[hidden email]> 于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
> > > >
> > > >
> > >
> > >
> >
>

[tison]

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 <[hidden email]> 于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 <[hidden email]> wrote:
>
> > @Chesnay - yes, this is possible, according to infra.
> >
> > On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <[hidden email]> 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 <[hidden email]> 于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
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
>

[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 <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]> wrote:
> >
> > > @Chesnay - yes, this is possible, according to infra.
> > >
> > > On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <[hidden email]>
> 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 <[hidden email]> 于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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

[Timo Walther-2]

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 <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]> wrote:
>>>
>>>> @Chesnay - yes, this is possible, according to infra.
>>>>
>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <[hidden email]>
>> 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 <[hidden email]> 于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
>>>>>>>
>>>>>>>
>>>>>>

[Fabian Hueske-2]

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 <[hidden email]
>:

> 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 <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]> wrote:
> >>>
> >>>> @Chesnay - yes, this is possible, according to infra.
> >>>>
> >>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <[hidden email]>
> >> 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 <[hidden email]> 于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
> >>>>>>>
> >>>>>>>
> >>>>>>
>
>

[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 <[hidden email]> 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 <
> [hidden email]
> >:
>
> > 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 <[hidden email]>
> 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 <[hidden email]> 于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 <[hidden email]>
> wrote:
> > >>>
> > >>>> @Chesnay - yes, this is possible, according to infra.
> > >>>>
> > >>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <[hidden email]>
> > >> 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 <[hidden email]> 于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
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> >
> >
>

[Timo Walther-2]

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 <[hidden email]> 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 <
>> [hidden email]
>>> :
>>> 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 <[hidden email]>
>> 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 <[hidden email]> 于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 <[hidden email]>
>> wrote:
>>>>>>> @Chesnay - yes, this is possible, according to infra.
>>>>>>>
>>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <[hidden email]>
>>>>> 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 <[hidden email]> 于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
>>>>>>>>>>
>>>>>>>>>>
>>>

[Robert Metzger]

I'm +1 on option 1.

On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <[hidden email]> 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 <[hidden email]> 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 <
> >> [hidden email]
> >>> :
> >>> 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 <[hidden email]>
> >> 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 <[hidden email]> 于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 <[hidden email]>
> >> wrote:
> >>>>>>> @Chesnay - yes, this is possible, according to infra.
> >>>>>>>
> >>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <[hidden email]>
> >>>>> 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 <[hidden email]> 于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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>
>
>

[Andrey Zagrebin-3]

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 <[hidden email]> wrote:

> I'm +1 on option 1.
>
> On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <[hidden email]> 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 <[hidden email]>
> 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 <
> > >> [hidden email]
> > >>> :
> > >>> 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 <[hidden email]>
> > >> 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 <[hidden email]> 于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 <[hidden email]>
> > >> wrote:
> > >>>>>>> @Chesnay - yes, this is possible, according to infra.
> > >>>>>>>
> > >>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <[hidden email]
> >
> > >>>>> 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 <[hidden email]> 于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
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>
> >
> >
>

[Robert Metzger]

@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 <[hidden email]>
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 <[hidden email]>
> wrote:
>
> > I'm +1 on option 1.
> >
> > On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <[hidden email]> 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 <[hidden email]>
> > 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 <
> > > >> [hidden email]
> > > >>> :
> > > >>> 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 <[hidden email]>
> > > >> 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 <[hidden email]> 于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 <[hidden email]>
> > > >> wrote:
> > > >>>>>>> @Chesnay - yes, this is possible, according to infra.
> > > >>>>>>>
> > > >>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
> [hidden email]
> > >
> > > >>>>> 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 <[hidden email]> 于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 LI]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> > wrote:
> >
> > > I'm +1 on option 1.
> > >
> > > On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <[hidden email]>
> 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 <[hidden email]>
> > > 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 <
> > > > >> [hidden email]
> > > > >>> :
> > > > >>> 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 <[hidden email]
> >
> > > > >> 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 <[hidden email]> 于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 <
> [hidden email]>
> > > > >> wrote:
> > > > >>>>>>> @Chesnay - yes, this is possible, according to infra.
> > > > >>>>>>>
> > > > >>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
> > [hidden email]
> > > >
> > > > >>>>> 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 <[hidden email]> 于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)

[Andrey Zagrebin-3]

@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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > wrote:
> > >
> > > > I'm +1 on option 1.
> > > >
> > > > On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <[hidden email]>
> > 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 <[hidden email]
> >
> > > > 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 <
> > > > > >> [hidden email]
> > > > > >>> :
> > > > > >>> 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 <
> [hidden email]
> > >
> > > > > >> 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 <[hidden email]> 于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 <
> > [hidden email]>
> > > > > >> wrote:
> > > > > >>>>>>> @Chesnay - yes, this is possible, according to infra.
> > > > > >>>>>>>
> > > > > >>>>>>> On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
> > > [hidden email]
> > > > >
> > > > > >>>>> 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 <[hidden email]> 于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)
>