[DISCUSS] A more restrictive JIRA workflow

[tison]

@Jack

From https://flink.apache.org/contributing/contribute-code.html the
community
claims

- Only start working on the implementation if there is consensus on the
approach (e.g. you are assigned to the ticket)

and accurately answer your question,

- Pull requests belonging to unassigned Jira tickets will not be reviewed
or merged by the community.

Best,
tison.


Jark Wu <[hidden email]> 于2019年7月19日周五 上午11:28写道：

> A quick question, what should we do if a developer creates a JIRA issue and
> then create a pull request at once without assigning?
>
>
> Regards,
> Jark
>
> On Thu, 18 Jul 2019 at 18:50, Zili Chen <[hidden email]> wrote:
>
> > Checking the result, as a discovery, I found that one can
> > still file a JIRA with "blocker" priority.
> >
> > IIRC someone in this thread once mentioned that
> > "Don't allow contributors to set a blocker priority."
> >
> > Chesnay,
> >
> > Thanks for the clarification.
> >
> >
> > Best,
> > tison.
> >
> >
> > Chesnay Schepler <[hidden email]> 于2019年7月18日周四 下午6:40写道：
> >
> > > We haven't wiped the set of contributors yet. Not sure if there's an
> > > easy way to remove the permissions for all of them; someone from the
> PMC
> > > may have to bite the bullet and click 600 times in a row :)
> > >
> > > On 18/07/2019 12:32, Zili Chen wrote:
> > > > Robert,
> > > >
> > > > Thanks for your effort. Rejecting contributor permission request
> > > > with a nice message and pointing them to the announcement sounds
> > > > reasonable. Just to be clear, we now have no person with contributor
> > > > role, right?
> > > >
> > > > Chesnay,
> > > >
> > > > https://flink.apache.org/contributing/contribute-code.html has been
> > > > updated and mentions that "Only committers can assign a Jira ticket."
> > > >
> > > > I think the corresponding update has been done.
> > > >
> > > > Best,
> > > > tison.
> > > >
> > > >
> > > > Chesnay Schepler <[hidden email]> 于2019年7月18日周四 下午6:25写道：
> > > >
> > > >> Do our contribution guidelines contain anything that should be
> > updated?
> > > >>
> > > >> On 18/07/2019 12:24, Chesnay Schepler wrote:
> > > >>> Sounds good to me.
> > > >>>
> > > >>> On 18/07/2019 12:07, Robert Metzger wrote:
> > > >>>> Infra has finally changed the permissions. I just announced the
> > > >>>> change in a
> > > >>>> separate email [1].
> > > >>>>
> > > >>>> One thing I wanted to discuss here is, how do we want to handle
> all
> > > the
> > > >>>> "contributor permissions" requests?
> > > >>>>
> > > >>>> My proposal is to basically reject them with a nice message,
> > pointing
> > > >>>> them
> > > >>>> to my announcement.
> > > >>>>
> > > >>>> What do you think?
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> [1]
> > > >>>>
> > > >>
> > >
> >
> https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
> > > >>>>
> > > >>>>
> > > >>>> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <
> [hidden email]>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> This is the Jira ticket I opened
> > > >>>>> https://issues.apache.org/jira/browse/INFRA-18644 a long time
> ago
> > :)
> > > >>>>>
> > > >>>>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <
> > [hidden email]
> > > >
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> @Robert what's the state here?
> > > >>>>>>
> > > >>>>>> On 24/06/2019 16:16, Robert Metzger wrote:
> > > >>>>>>> Hey all,
> > > >>>>>>>
> > > >>>>>>> I would like to drive this discussion to an end soon.
> > > >>>>>>> I've just merged the updated contribution guide to the Flink
> > > website:
> > > >>>>>>> https://flink.apache.org/contributing/contribute-code.html
> > > >>>>>>>
> > > >>>>>>> I will now ask Apache IINFRA to change the permissions in our
> > Jira.
> > > >>>>>>>
> > > >>>>>>> Here's the updated TODO list:
> > > >>>>>>>
> > > >>>>>>> 1. I update the contribution guide DONE
> > > >>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
> PRs
> > > >>>>>>> with
> > > >>>>>>> unassigned JIRAs IN PROGRESS
> > > >>>>>>> 3. We ask Infra to change the permissions of our JIRA so that:
> IN
> > > >>>>>> PROGRESS
> > > >>>>>>>      a) only committers can assign users to tickets
> > > >>>>>>>      b) contributors can't assign users to tickets
> > > >>>>>>>      c) Every registered JIRA user is an assignable user in
> FLINK
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <
> > > [hidden email]>
> > > >>>>>> wrote:
> > > >>>>>>>> Hey,
> > > >>>>>>>>
> > > >>>>>>>> I started working on step 1 and proposed some changes to the
> > Flink
> > > >>>>>>>> website: https://github.com/apache/flink-web/pull/217
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <
> > > [hidden email]
> > > >>>>>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> Hi Fabian,
> > > >>>>>>>>> You are right, I made a mistake. I don't think it makes sense
> > to
> > > >>>>>>>>> introduce a new permission class. This will make the life of
> > JIRA
> > > >>>>>> admins
> > > >>>>>>>>> unnecessarily complicated.
> > > >>>>>>>>> I updated the task list:
> > > >>>>>>>>>
> > > >>>>>>>>> 1. I update the contribution guide
> > > >>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
> > > >>>>>>>>> PRs with
> > > >>>>>>>>> unassigned JIRAs
> > > >>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
> that:
> > > >>>>>>>>>      a) only committers can assign users to tickets
> > > >>>>>>>>>      b) contributors can't assign users to tickets
> > > >>>>>>>>>      c) Every registered JIRA user is an assignable user in
> > FLINK
> > > >>>>>>>>> 4. We remove all existing contributors
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <
> > > [hidden email]>
> > > >>>>>> wrote:
> > > >>>>>>>>>> Hi Robert,
> > > >>>>>>>>>>
> > > >>>>>>>>>> If I understood the decision correctly, we also need to ask
> > > >>>>>>>>>> Infra to
> > > >>>>>> make
> > > >>>>>>>>>> everybody an assignable user, right?
> > > >>>>>>>>>> Or do we want to add a new permission class "Assignable
> User"
> > > such
> > > >>>>>> that
> > > >>>>>>>>>> everyone still needs to ask for the right Jira permissions?
> > > >>>>>>>>>>
> > > >>>>>>>>>> Fabian
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
> > > >>>>>>>>>> [hidden email]
> > > >>>>>>>>>>> :
> > > >>>>>>>>>>> Hi Robert,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> thanks for taking care of this. +1 to your suggested steps.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Regards,
> > > >>>>>>>>>>> Timo
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
> > > >>>>>>>>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
> > > >>>>>>>>>>>> I will only do that for PRs without JIRA ID or "[hotfix]"
> in
> > > the
> > > >>>>>>>>>> title.
> > > >>>>>>>>>>>> We can always revisit this at a later stage.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I'm proposing the following steps:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 1. I update the contribution guide
> > > >>>>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings
> > on
> > > >>>>>>>>>>>> PRs
> > > >>>>>>>>>> with
> > > >>>>>>>>>>>> unassigned JIRAs
> > > >>>>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
> > that:
> > > >>>>>>>>>>>>       a) only committers can assign users to tickets
> > > >>>>>>>>>>>>       b) contributors can't assign users to tickets
> > > >>>>>>>>>>>> 4. We remove all existing contributors
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang
> > > >>>>>>>>>>>> <[hidden email]>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>> also +1 for option 2.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I think auto-close a PR sometimes a bit impertinency.
> > > >>>>>>>>>>>>> The reasons just like Stephan mentioned.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Stephan Ewen <[hidden email]> 于2019年4月24日周三
> > > >>>>>>>>>>>>> 下午4:08写道：
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> About auto-closing PRs from unassigned issues, consider
> > the
> > > >>>>>>>>>> following
> > > >>>>>>>>>>>>> case
> > > >>>>>>>>>>>>>> that has happened quite a bit.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>       - a user reports a small bug and immediately wants
> > to
> > > >>>>>> provide a
> > > >>>>>>>>>> fix
> > > >>>>>>>>>>> for
> > > >>>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>       - it makes sense to not stall the user for a few
> > days
> > > >>>>>>>>>>>>>> until a
> > > >>>>>>>>>>> committer
> > > >>>>>>>>>>>>>> assigned the issue
> > > >>>>>>>>>>>>>>       - not auto-closing the PR would at least allow the
> > > >>>>>>>>>>>>>> user to
> > > >>>>>>>>>> provide
> > > >>>>>>>>>>>>> their
> > > >>>>>>>>>>>>>> patch.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen
> > > >>>>>>>>>>>>>> <[hidden email]>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>> +1 for option #2
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Seems to me that this does not contradict option #1, it
> > > only
> > > >>>>>>>>>> extends
> > > >>>>>>>>>>>>> this
> > > >>>>>>>>>>>>>>> a bit. I think there is a good case for that, to help
> > > >>>>>>>>>>>>>>> frequent
> > > >>>>>>>>>>>>>> contributors
> > > >>>>>>>>>>>>>>> on a way to committership.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> @Konstantin: Trivial fixes (typos, docs, javadocs, ...)
> > > >>>>>>>>>>>>>>> should
> > > >>>>>>>>>> still
> > > >>>>>>>>>>> be
> > > >>>>>>>>>>>>>>> possible as "hotfixes".
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On Mon, Apr 15, 2019 at 3:14 PM Timo Walther <
> > > >>>>>> [hidden email]>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>> I think this really depends on the contribution.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Sometimes "triviality" means that people just want to
> > fix
> > > a
> > > >>>>>> typo
> > > >>>>>>>>>> in
> > > >>>>>>>>>>>>> some
> > > >>>>>>>>>>>>>>>> docs. For this, a hotfix PR is sufficient and does not
> > > >>>>>>>>>>>>>>>> need a
> > > >>>>>>>>>> JIRA
> > > >>>>>>>>>>>>>> issue.
> > > >>>>>>>>>>>>>>>> However, sometimes "triviality" is only trivial at
> first
> > > >>>>>>>>>>>>>>>> glance
> > > >>>>>>>>>> but
> > > >>>>>>>>>>>>>>>> introduces side effects. In any case, any contribution
> > > >>>>>>>>>>>>>>>> needs to
> > > >>>>>>>>>> be
> > > >>>>>>>>>>>>>>>> reviewed and merged by a committer so follow-up
> > responses
> > > >>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>> follow-up
> > > >>>>>>>>>>>>>>>> work might always be required. But you are right,
> > > committers
> > > >>>>>>>>>> need to
> > > >>>>>>>>>>>>>>>> respond quicker in any case.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Timo
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Am 15.04.19 um 14:54 schrieb Konstantin Knauf:
> > > >>>>>>>>>>>>>>>>> Hi everyone,
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> just my two cents:  as a non-committer I appreciate a
> > > >>>>>>>>>> lightweight,
> > > >>>>>>>>>>>>>>>>> frictionless process for trivial changes or small
> fixes
> > > >>>>>> without
> > > >>>>>>>>>> the
> > > >>>>>>>>>>>>>>>> need to
> > > >>>>>>>>>>>>>>>>> approach a committer beforehand. If it takes 5 days,
> so
> > > >>>>>>>>>>>>>>>>> that I
> > > >>>>>>>>>> can
> > > >>>>>>>>>>>>>> start
> > > >>>>>>>>>>>>>>>>> with a triviality, I might not bother in the first
> > > >>>>>>>>>>>>>>>>> place. So,
> > > >>>>>> in
> > > >>>>>>>>>>>>> order
> > > >>>>>>>>>>>>>>>> for
> > > >>>>>>>>>>>>>>>>> this not to backfire by making the community more
> > > >>>>>>>>>>>>>>>>> exclusive,
> > > >>>>>> we
> > > >>>>>>>>>> need
> > > >>>>>>>>>>>>>>>> more
> > > >>>>>>>>>>>>>>>>> timely responses & follow ups by committers after the
> > > >>>>>>>>>>>>>>>>> change
> > > >>>>>> to
> > > >>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>> workflow. Having said that, I am slightly leaning
> > towards
> > > >>>>>>>>>> Andrey's
> > > >>>>>>>>>>>>>>>>> interpretation of option 2.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Cheers,
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Konstantin
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> On Mon, Apr 15, 2019 at 1:39 PM Andrey Zagrebin <
> > > >>>>>>>>>>>>> [hidden email]
> > > >>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> @Robert thanks for pointing out and sorry for
> > > >>>>>>>>>>>>>>>>>> confusion. The
> > > >>>>>>>>>>>>> correct
> > > >>>>>>>>>>>>>>>> text:
> > > >>>>>>>>>>>>>>>>>> +1 for option 1.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> I also do not mind option 2, after 1-2
> contributions,
> > > any
> > > >>>>>>>>>>>>> contributor
> > > >>>>>>>>>>>>>>>> could
> > > >>>>>>>>>>>>>>>>>> just ask the committer (who merged those
> > contributions)
> > > >>>>>>>>>>>>>>>>>> about
> > > >>>>>>>>>>>>>>>> contributor
> > > >>>>>>>>>>>>>>>>>> permissions.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Best,
> > > >>>>>>>>>>>>>>>>>> Andrey
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> On Mon, Apr 15, 2019 at 10:34 AM Feng LI <
> > > >>>>>>>>>> [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)
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>
> > > >>
> > >
> > >
> >
>

[tison]

Fair enough, we might rephrase as

"Pull requests belonging to unassigned Jira tickets or not authored by
assignee will ..."

For the action "what should we do", iirc someone in this thread proposed
closing it via flinkbot. Or leaving without review and merge could be ok
before we implement automatic reply/reaction.

Best,
tison.


Zili Chen <[hidden email]> 于2019年7月19日周五 上午11:44写道：

> @Jack
>
> From https://flink.apache.org/contributing/contribute-code.html the
> community
> claims
>
> - Only start working on the implementation if there is consensus on the
> approach (e.g. you are assigned to the ticket)
>
> and accurately answer your question,
>
> - Pull requests belonging to unassigned Jira tickets will not be reviewed
> or merged by the community.
>
> Best,
> tison.
>
>
> Jark Wu <[hidden email]> 于2019年7月19日周五 上午11:28写道：
>
>> A quick question, what should we do if a developer creates a JIRA issue
>> and
>> then create a pull request at once without assigning?
>>
>>
>> Regards,
>> Jark
>>
>> On Thu, 18 Jul 2019 at 18:50, Zili Chen <[hidden email]> wrote:
>>
>> > Checking the result, as a discovery, I found that one can
>> > still file a JIRA with "blocker" priority.
>> >
>> > IIRC someone in this thread once mentioned that
>> > "Don't allow contributors to set a blocker priority."
>> >
>> > Chesnay,
>> >
>> > Thanks for the clarification.
>> >
>> >
>> > Best,
>> > tison.
>> >
>> >
>> > Chesnay Schepler <[hidden email]> 于2019年7月18日周四 下午6:40写道：
>> >
>> > > We haven't wiped the set of contributors yet. Not sure if there's an
>> > > easy way to remove the permissions for all of them; someone from the
>> PMC
>> > > may have to bite the bullet and click 600 times in a row :)
>> > >
>> > > On 18/07/2019 12:32, Zili Chen wrote:
>> > > > Robert,
>> > > >
>> > > > Thanks for your effort. Rejecting contributor permission request
>> > > > with a nice message and pointing them to the announcement sounds
>> > > > reasonable. Just to be clear, we now have no person with contributor
>> > > > role, right?
>> > > >
>> > > > Chesnay,
>> > > >
>> > > > https://flink.apache.org/contributing/contribute-code.html has been
>> > > > updated and mentions that "Only committers can assign a Jira
>> ticket."
>> > > >
>> > > > I think the corresponding update has been done.
>> > > >
>> > > > Best,
>> > > > tison.
>> > > >
>> > > >
>> > > > Chesnay Schepler <[hidden email]> 于2019年7月18日周四 下午6:25写道：
>> > > >
>> > > >> Do our contribution guidelines contain anything that should be
>> > updated?
>> > > >>
>> > > >> On 18/07/2019 12:24, Chesnay Schepler wrote:
>> > > >>> Sounds good to me.
>> > > >>>
>> > > >>> On 18/07/2019 12:07, Robert Metzger wrote:
>> > > >>>> Infra has finally changed the permissions. I just announced the
>> > > >>>> change in a
>> > > >>>> separate email [1].
>> > > >>>>
>> > > >>>> One thing I wanted to discuss here is, how do we want to handle
>> all
>> > > the
>> > > >>>> "contributor permissions" requests?
>> > > >>>>
>> > > >>>> My proposal is to basically reject them with a nice message,
>> > pointing
>> > > >>>> them
>> > > >>>> to my announcement.
>> > > >>>>
>> > > >>>> What do you think?
>> > > >>>>
>> > > >>>>
>> > > >>>>
>> > > >>>> [1]
>> > > >>>>
>> > > >>
>> > >
>> >
>> https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
>> > > >>>>
>> > > >>>>
>> > > >>>> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <
>> [hidden email]>
>> > > >>>> wrote:
>> > > >>>>
>> > > >>>>> This is the Jira ticket I opened
>> > > >>>>> https://issues.apache.org/jira/browse/INFRA-18644 a long time
>> ago
>> > :)
>> > > >>>>>
>> > > >>>>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <
>> > [hidden email]
>> > > >
>> > > >>>>> wrote:
>> > > >>>>>
>> > > >>>>>> @Robert what's the state here?
>> > > >>>>>>
>> > > >>>>>> On 24/06/2019 16:16, Robert Metzger wrote:
>> > > >>>>>>> Hey all,
>> > > >>>>>>>
>> > > >>>>>>> I would like to drive this discussion to an end soon.
>> > > >>>>>>> I've just merged the updated contribution guide to the Flink
>> > > website:
>> > > >>>>>>> https://flink.apache.org/contributing/contribute-code.html
>> > > >>>>>>>
>> > > >>>>>>> I will now ask Apache IINFRA to change the permissions in our
>> > Jira.
>> > > >>>>>>>
>> > > >>>>>>> Here's the updated TODO list:
>> > > >>>>>>>
>> > > >>>>>>> 1. I update the contribution guide DONE
>> > > >>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings on
>> PRs
>> > > >>>>>>> with
>> > > >>>>>>> unassigned JIRAs IN PROGRESS
>> > > >>>>>>> 3. We ask Infra to change the permissions of our JIRA so
>> that: IN
>> > > >>>>>> PROGRESS
>> > > >>>>>>>      a) only committers can assign users to tickets
>> > > >>>>>>>      b) contributors can't assign users to tickets
>> > > >>>>>>>      c) Every registered JIRA user is an assignable user in
>> FLINK
>> > > >>>>>>>
>> > > >>>>>>>
>> > > >>>>>>>
>> > > >>>>>>>
>> > > >>>>>>>
>> > > >>>>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <
>> > > [hidden email]>
>> > > >>>>>> wrote:
>> > > >>>>>>>> Hey,
>> > > >>>>>>>>
>> > > >>>>>>>> I started working on step 1 and proposed some changes to the
>> > Flink
>> > > >>>>>>>> website: https://github.com/apache/flink-web/pull/217
>> > > >>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <
>> > > [hidden email]
>> > > >>>>>>>> wrote:
>> > > >>>>>>>>
>> > > >>>>>>>>> Hi Fabian,
>> > > >>>>>>>>> You are right, I made a mistake. I don't think it makes
>> sense
>> > to
>> > > >>>>>>>>> introduce a new permission class. This will make the life of
>> > JIRA
>> > > >>>>>> admins
>> > > >>>>>>>>> unnecessarily complicated.
>> > > >>>>>>>>> I updated the task list:
>> > > >>>>>>>>>
>> > > >>>>>>>>> 1. I update the contribution guide
>> > > >>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings
>> on
>> > > >>>>>>>>> PRs with
>> > > >>>>>>>>> unassigned JIRAs
>> > > >>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
>> that:
>> > > >>>>>>>>>      a) only committers can assign users to tickets
>> > > >>>>>>>>>      b) contributors can't assign users to tickets
>> > > >>>>>>>>>      c) Every registered JIRA user is an assignable user in
>> > FLINK
>> > > >>>>>>>>> 4. We remove all existing contributors
>> > > >>>>>>>>>
>> > > >>>>>>>>>
>> > > >>>>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <
>> > > [hidden email]>
>> > > >>>>>> wrote:
>> > > >>>>>>>>>> Hi Robert,
>> > > >>>>>>>>>>
>> > > >>>>>>>>>> If I understood the decision correctly, we also need to ask
>> > > >>>>>>>>>> Infra to
>> > > >>>>>> make
>> > > >>>>>>>>>> everybody an assignable user, right?
>> > > >>>>>>>>>> Or do we want to add a new permission class "Assignable
>> User"
>> > > such
>> > > >>>>>> that
>> > > >>>>>>>>>> everyone still needs to ask for the right Jira permissions?
>> > > >>>>>>>>>>
>> > > >>>>>>>>>> Fabian
>> > > >>>>>>>>>>
>> > > >>>>>>>>>>
>> > > >>>>>>>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
>> > > >>>>>>>>>> [hidden email]
>> > > >>>>>>>>>>> :
>> > > >>>>>>>>>>> Hi Robert,
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> thanks for taking care of this. +1 to your suggested
>> steps.
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> Regards,
>> > > >>>>>>>>>>> Timo
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
>> > > >>>>>>>>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
>> > > >>>>>>>>>>>> I will only do that for PRs without JIRA ID or
>> "[hotfix]" in
>> > > the
>> > > >>>>>>>>>> title.
>> > > >>>>>>>>>>>> We can always revisit this at a later stage.
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> I'm proposing the following steps:
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> 1. I update the contribution guide
>> > > >>>>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show
>> warnings
>> > on
>> > > >>>>>>>>>>>> PRs
>> > > >>>>>>>>>> with
>> > > >>>>>>>>>>>> unassigned JIRAs
>> > > >>>>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
>> > that:
>> > > >>>>>>>>>>>>       a) only committers can assign users to tickets
>> > > >>>>>>>>>>>>       b) contributors can't assign users to tickets
>> > > >>>>>>>>>>>> 4. We remove all existing contributors
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang
>> > > >>>>>>>>>>>> <[hidden email]>
>> > > >>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>> also +1 for option 2.
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> I think auto-close a PR sometimes a bit impertinency.
>> > > >>>>>>>>>>>>> The reasons just like Stephan mentioned.
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> Stephan Ewen <[hidden email]> 于2019年4月24日周三
>> > > >>>>>>>>>>>>> 下午4:08写道：
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> About auto-closing PRs from unassigned issues, consider
>> > the
>> > > >>>>>>>>>> following
>> > > >>>>>>>>>>>>> case
>> > > >>>>>>>>>>>>>> that has happened quite a bit.
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>       - a user reports a small bug and immediately
>> wants
>> > to
>> > > >>>>>> provide a
>> > > >>>>>>>>>> fix
>> > > >>>>>>>>>>> for
>> > > >>>>>>>>>>>>>> it
>> > > >>>>>>>>>>>>>>       - it makes sense to not stall the user for a few
>> > days
>> > > >>>>>>>>>>>>>> until a
>> > > >>>>>>>>>>> committer
>> > > >>>>>>>>>>>>>> assigned the issue
>> > > >>>>>>>>>>>>>>       - not auto-closing the PR would at least allow
>> the
>> > > >>>>>>>>>>>>>> user to
>> > > >>>>>>>>>> provide
>> > > >>>>>>>>>>>>> their
>> > > >>>>>>>>>>>>>> patch.
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen
>> > > >>>>>>>>>>>>>> <[hidden email]>
>> > > >>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>> +1 for option #2
>> > > >>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>> Seems to me that this does not contradict option #1,
>> it
>> > > only
>> > > >>>>>>>>>> extends
>> > > >>>>>>>>>>>>> this
>> > > >>>>>>>>>>>>>>> a bit. I think there is a good case for that, to help
>> > > >>>>>>>>>>>>>>> frequent
>> > > >>>>>>>>>>>>>> contributors
>> > > >>>>>>>>>>>>>>> on a way to committership.
>> > > >>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>> @Konstantin: Trivial fixes (typos, docs, javadocs,
>> ...)
>> > > >>>>>>>>>>>>>>> should
>> > > >>>>>>>>>> still
>> > > >>>>>>>>>>> be
>> > > >>>>>>>>>>>>>>> possible as "hotfixes".
>> > > >>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>> On Mon, Apr 15, 2019 at 3:14 PM Timo Walther <
>> > > >>>>>> [hidden email]>
>> > > >>>>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>>> I think this really depends on the contribution.
>> > > >>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>> Sometimes "triviality" means that people just want to
>> > fix
>> > > a
>> > > >>>>>> typo
>> > > >>>>>>>>>> in
>> > > >>>>>>>>>>>>> some
>> > > >>>>>>>>>>>>>>>> docs. For this, a hotfix PR is sufficient and does
>> not
>> > > >>>>>>>>>>>>>>>> need a
>> > > >>>>>>>>>> JIRA
>> > > >>>>>>>>>>>>>> issue.
>> > > >>>>>>>>>>>>>>>> However, sometimes "triviality" is only trivial at
>> first
>> > > >>>>>>>>>>>>>>>> glance
>> > > >>>>>>>>>> but
>> > > >>>>>>>>>>>>>>>> introduces side effects. In any case, any
>> contribution
>> > > >>>>>>>>>>>>>>>> needs to
>> > > >>>>>>>>>> be
>> > > >>>>>>>>>>>>>>>> reviewed and merged by a committer so follow-up
>> > responses
>> > > >>>>>>>>>>>>>>>> and
>> > > >>>>>>>>>>>>> follow-up
>> > > >>>>>>>>>>>>>>>> work might always be required. But you are right,
>> > > committers
>> > > >>>>>>>>>> need to
>> > > >>>>>>>>>>>>>>>> respond quicker in any case.
>> > > >>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>> Timo
>> > > >>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>> Am 15.04.19 um 14:54 schrieb Konstantin Knauf:
>> > > >>>>>>>>>>>>>>>>> Hi everyone,
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> just my two cents:  as a non-committer I appreciate
>> a
>> > > >>>>>>>>>> lightweight,
>> > > >>>>>>>>>>>>>>>>> frictionless process for trivial changes or small
>> fixes
>> > > >>>>>> without
>> > > >>>>>>>>>> the
>> > > >>>>>>>>>>>>>>>> need to
>> > > >>>>>>>>>>>>>>>>> approach a committer beforehand. If it takes 5
>> days, so
>> > > >>>>>>>>>>>>>>>>> that I
>> > > >>>>>>>>>> can
>> > > >>>>>>>>>>>>>> start
>> > > >>>>>>>>>>>>>>>>> with a triviality, I might not bother in the first
>> > > >>>>>>>>>>>>>>>>> place. So,
>> > > >>>>>> in
>> > > >>>>>>>>>>>>> order
>> > > >>>>>>>>>>>>>>>> for
>> > > >>>>>>>>>>>>>>>>> this not to backfire by making the community more
>> > > >>>>>>>>>>>>>>>>> exclusive,
>> > > >>>>>> we
>> > > >>>>>>>>>> need
>> > > >>>>>>>>>>>>>>>> more
>> > > >>>>>>>>>>>>>>>>> timely responses & follow ups by committers after
>> the
>> > > >>>>>>>>>>>>>>>>> change
>> > > >>>>>> to
>> > > >>>>>>>>>> the
>> > > >>>>>>>>>>>>>>>>> workflow. Having said that, I am slightly leaning
>> > towards
>> > > >>>>>>>>>> Andrey's
>> > > >>>>>>>>>>>>>>>>> interpretation of option 2.
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> Cheers,
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> Konstantin
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> On Mon, Apr 15, 2019 at 1:39 PM Andrey Zagrebin <
>> > > >>>>>>>>>>>>> [hidden email]
>> > > >>>>>>>>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>> @Robert thanks for pointing out and sorry for
>> > > >>>>>>>>>>>>>>>>>> confusion. The
>> > > >>>>>>>>>>>>> correct
>> > > >>>>>>>>>>>>>>>> text:
>> > > >>>>>>>>>>>>>>>>>> +1 for option 1.
>> > > >>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>> I also do not mind option 2, after 1-2
>> contributions,
>> > > any
>> > > >>>>>>>>>>>>> contributor
>> > > >>>>>>>>>>>>>>>> could
>> > > >>>>>>>>>>>>>>>>>> just ask the committer (who merged those
>> > contributions)
>> > > >>>>>>>>>>>>>>>>>> about
>> > > >>>>>>>>>>>>>>>> contributor
>> > > >>>>>>>>>>>>>>>>>> permissions.
>> > > >>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>> Best,
>> > > >>>>>>>>>>>>>>>>>> Andrey
>> > > >>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>> On Mon, Apr 15, 2019 at 10:34 AM Feng LI <
>> > > >>>>>>>>>> [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)
>> > > >>>>>>>>>>>>>>>>>>>
>> > > >>>
>> > > >>
>> > >
>> > >
>> >
>>
>

[Robert Metzger]

Hi all!

Chesnay wrote:

> We haven't wiped the set of contributors yet. Not sure if there's an
> easy way to remove the permissions for all of them; someone from the PMC
> may have to bite the bullet and click 600 times in a row :)


I don't think there's an easy way for us.
People with "Contributor" permissions have permissions such as "Closing"
and "Editing" (including "Transition", "Logging work", etc.) issues.
I would propose to either drastically reduce the number of people with
Contributor permissions, leaving just those in, who are helping to keep our
Jira in a clean shape (and this decision would be solely done at the
discretion of the PMC deleting people from the contributor group)
Another option would be to ask Infra to remove all people with Contributor
permissions from Flink (deleting and re-adding the group or so :) )
Moving forward, the PMC would maintain a list of contributors who are
helping to keep Jira clean and well-organized.

Tison wrote:

> IIRC someone in this thread once mentioned that
> "Don't allow contributors to set a blocker priority."


Timo wrote this when he kicked off this thread. Sadly, this permission is
not provided by Jira out of the box:
https://community.atlassian.com/t5/Jira-questions/How-to-restrict-the-setting-of-certain-priorities-to-certain/qaq-p/193230
We will have to manually monitor tickets with "Blocker" status.


Fair enough, we might rephrase as
> "Pull requests belonging to unassigned Jira tickets or not authored by
> assignee will ..."


That's a good point. If nobody disagrees, would you like to open PR for
changing it?

For the action "what should we do", iirc someone in this thread proposed
> closing it via flinkbot. Or leaving without review and merge could be ok
> before we implement automatic reply/reaction.


I proposed to automatically close. I believe that this might be too harsh.
I've implemented already an extension to Flinkbot which shows warnings for
a pull request. I just haven't found the time to test the extension and put
it in production.



On Fri, Jul 19, 2019 at 5:51 AM Zili Chen <[hidden email]> wrote:

> Fair enough, we might rephrase as
>
> "Pull requests belonging to unassigned Jira tickets or not authored by
> assignee will ..."
>
> For the action "what should we do", iirc someone in this thread proposed
> closing it via flinkbot. Or leaving without review and merge could be ok
> before we implement automatic reply/reaction.
>
> Best,
> tison.
>
>
> Zili Chen <[hidden email]> 于2019年7月19日周五 上午11:44写道：
>
>> @Jack
>>
>> From https://flink.apache.org/contributing/contribute-code.html the
>> community
>> claims
>>
>> - Only start working on the implementation if there is consensus on the
>> approach (e.g. you are assigned to the ticket)
>>
>> and accurately answer your question,
>>
>> - Pull requests belonging to unassigned Jira tickets will not be reviewed
>> or merged by the community.
>>
>> Best,
>> tison.
>>
>>
>> Jark Wu <[hidden email]> 于2019年7月19日周五 上午11:28写道：
>>
>>> A quick question, what should we do if a developer creates a JIRA issue
>>> and
>>> then create a pull request at once without assigning?
>>>
>>>
>>> Regards,
>>> Jark
>>>
>>> On Thu, 18 Jul 2019 at 18:50, Zili Chen <[hidden email]> wrote:
>>>
>>> > Checking the result, as a discovery, I found that one can
>>> > still file a JIRA with "blocker" priority.
>>> >
>>> > IIRC someone in this thread once mentioned that
>>> > "Don't allow contributors to set a blocker priority."
>>> >
>>> > Chesnay,
>>> >
>>> > Thanks for the clarification.
>>> >
>>> >
>>> > Best,
>>> > tison.
>>> >
>>> >
>>> > Chesnay Schepler <[hidden email]> 于2019年7月18日周四 下午6:40写道：
>>> >
>>> > > We haven't wiped the set of contributors yet. Not sure if there's an
>>> > > easy way to remove the permissions for all of them; someone from the
>>> PMC
>>> > > may have to bite the bullet and click 600 times in a row :)
>>> > >
>>> > > On 18/07/2019 12:32, Zili Chen wrote:
>>> > > > Robert,
>>> > > >
>>> > > > Thanks for your effort. Rejecting contributor permission request
>>> > > > with a nice message and pointing them to the announcement sounds
>>> > > > reasonable. Just to be clear, we now have no person with
>>> contributor
>>> > > > role, right?
>>> > > >
>>> > > > Chesnay,
>>> > > >
>>> > > > https://flink.apache.org/contributing/contribute-code.html has
>>> been
>>> > > > updated and mentions that "Only committers can assign a Jira
>>> ticket."
>>> > > >
>>> > > > I think the corresponding update has been done.
>>> > > >
>>> > > > Best,
>>> > > > tison.
>>> > > >
>>> > > >
>>> > > > Chesnay Schepler <[hidden email]> 于2019年7月18日周四 下午6:25写道：
>>> > > >
>>> > > >> Do our contribution guidelines contain anything that should be
>>> > updated?
>>> > > >>
>>> > > >> On 18/07/2019 12:24, Chesnay Schepler wrote:
>>> > > >>> Sounds good to me.
>>> > > >>>
>>> > > >>> On 18/07/2019 12:07, Robert Metzger wrote:
>>> > > >>>> Infra has finally changed the permissions. I just announced the
>>> > > >>>> change in a
>>> > > >>>> separate email [1].
>>> > > >>>>
>>> > > >>>> One thing I wanted to discuss here is, how do we want to handle
>>> all
>>> > > the
>>> > > >>>> "contributor permissions" requests?
>>> > > >>>>
>>> > > >>>> My proposal is to basically reject them with a nice message,
>>> > pointing
>>> > > >>>> them
>>> > > >>>> to my announcement.
>>> > > >>>>
>>> > > >>>> What do you think?
>>> > > >>>>
>>> > > >>>>
>>> > > >>>>
>>> > > >>>> [1]
>>> > > >>>>
>>> > > >>
>>> > >
>>> >
>>> https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
>>> > > >>>>
>>> > > >>>>
>>> > > >>>> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <
>>> [hidden email]>
>>> > > >>>> wrote:
>>> > > >>>>
>>> > > >>>>> This is the Jira ticket I opened
>>> > > >>>>> https://issues.apache.org/jira/browse/INFRA-18644 a long time
>>> ago
>>> > :)
>>> > > >>>>>
>>> > > >>>>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <
>>> > [hidden email]
>>> > > >
>>> > > >>>>> wrote:
>>> > > >>>>>
>>> > > >>>>>> @Robert what's the state here?
>>> > > >>>>>>
>>> > > >>>>>> On 24/06/2019 16:16, Robert Metzger wrote:
>>> > > >>>>>>> Hey all,
>>> > > >>>>>>>
>>> > > >>>>>>> I would like to drive this discussion to an end soon.
>>> > > >>>>>>> I've just merged the updated contribution guide to the Flink
>>> > > website:
>>> > > >>>>>>> https://flink.apache.org/contributing/contribute-code.html
>>> > > >>>>>>>
>>> > > >>>>>>> I will now ask Apache IINFRA to change the permissions in our
>>> > Jira.
>>> > > >>>>>>>
>>> > > >>>>>>> Here's the updated TODO list:
>>> > > >>>>>>>
>>> > > >>>>>>> 1. I update the contribution guide DONE
>>> > > >>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings
>>> on PRs
>>> > > >>>>>>> with
>>> > > >>>>>>> unassigned JIRAs IN PROGRESS
>>> > > >>>>>>> 3. We ask Infra to change the permissions of our JIRA so
>>> that: IN
>>> > > >>>>>> PROGRESS
>>> > > >>>>>>>      a) only committers can assign users to tickets
>>> > > >>>>>>>      b) contributors can't assign users to tickets
>>> > > >>>>>>>      c) Every registered JIRA user is an assignable user in
>>> FLINK
>>> > > >>>>>>>
>>> > > >>>>>>>
>>> > > >>>>>>>
>>> > > >>>>>>>
>>> > > >>>>>>>
>>> > > >>>>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <
>>> > > [hidden email]>
>>> > > >>>>>> wrote:
>>> > > >>>>>>>> Hey,
>>> > > >>>>>>>>
>>> > > >>>>>>>> I started working on step 1 and proposed some changes to the
>>> > Flink
>>> > > >>>>>>>> website: https://github.com/apache/flink-web/pull/217
>>> > > >>>>>>>>
>>> > > >>>>>>>>
>>> > > >>>>>>>>
>>> > > >>>>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <
>>> > > [hidden email]
>>> > > >>>>>>>> wrote:
>>> > > >>>>>>>>
>>> > > >>>>>>>>> Hi Fabian,
>>> > > >>>>>>>>> You are right, I made a mistake. I don't think it makes
>>> sense
>>> > to
>>> > > >>>>>>>>> introduce a new permission class. This will make the life
>>> of
>>> > JIRA
>>> > > >>>>>> admins
>>> > > >>>>>>>>> unnecessarily complicated.
>>> > > >>>>>>>>> I updated the task list:
>>> > > >>>>>>>>>
>>> > > >>>>>>>>> 1. I update the contribution guide
>>> > > >>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings
>>> on
>>> > > >>>>>>>>> PRs with
>>> > > >>>>>>>>> unassigned JIRAs
>>> > > >>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
>>> that:
>>> > > >>>>>>>>>      a) only committers can assign users to tickets
>>> > > >>>>>>>>>      b) contributors can't assign users to tickets
>>> > > >>>>>>>>>      c) Every registered JIRA user is an assignable user in
>>> > FLINK
>>> > > >>>>>>>>> 4. We remove all existing contributors
>>> > > >>>>>>>>>
>>> > > >>>>>>>>>
>>> > > >>>>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <
>>> > > [hidden email]>
>>> > > >>>>>> wrote:
>>> > > >>>>>>>>>> Hi Robert,
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>> If I understood the decision correctly, we also need to
>>> ask
>>> > > >>>>>>>>>> Infra to
>>> > > >>>>>> make
>>> > > >>>>>>>>>> everybody an assignable user, right?
>>> > > >>>>>>>>>> Or do we want to add a new permission class "Assignable
>>> User"
>>> > > such
>>> > > >>>>>> that
>>> > > >>>>>>>>>> everyone still needs to ask for the right Jira
>>> permissions?
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>> Fabian
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
>>> > > >>>>>>>>>> [hidden email]
>>> > > >>>>>>>>>>> :
>>> > > >>>>>>>>>>> Hi Robert,
>>> > > >>>>>>>>>>>
>>> > > >>>>>>>>>>> thanks for taking care of this. +1 to your suggested
>>> steps.
>>> > > >>>>>>>>>>>
>>> > > >>>>>>>>>>> Regards,
>>> > > >>>>>>>>>>> Timo
>>> > > >>>>>>>>>>>
>>> > > >>>>>>>>>>>
>>> > > >>>>>>>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
>>> > > >>>>>>>>>>>> @Stephan: I agree. Auto-closing PRs is quite aggressive.
>>> > > >>>>>>>>>>>> I will only do that for PRs without JIRA ID or
>>> "[hotfix]" in
>>> > > the
>>> > > >>>>>>>>>> title.
>>> > > >>>>>>>>>>>> We can always revisit this at a later stage.
>>> > > >>>>>>>>>>>>
>>> > > >>>>>>>>>>>>
>>> > > >>>>>>>>>>>> I'm proposing the following steps:
>>> > > >>>>>>>>>>>>
>>> > > >>>>>>>>>>>> 1. I update the contribution guide
>>> > > >>>>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show
>>> warnings
>>> > on
>>> > > >>>>>>>>>>>> PRs
>>> > > >>>>>>>>>> with
>>> > > >>>>>>>>>>>> unassigned JIRAs
>>> > > >>>>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
>>> > that:
>>> > > >>>>>>>>>>>>       a) only committers can assign users to tickets
>>> > > >>>>>>>>>>>>       b) contributors can't assign users to tickets
>>> > > >>>>>>>>>>>> 4. We remove all existing contributors
>>> > > >>>>>>>>>>>>
>>> > > >>>>>>>>>>>>
>>> > > >>>>>>>>>>>>
>>> > > >>>>>>>>>>>>
>>> > > >>>>>>>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang
>>> > > >>>>>>>>>>>> <[hidden email]>
>>> > > >>>>>>>>>>> wrote:
>>> > > >>>>>>>>>>>>> also +1 for option 2.
>>> > > >>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>> I think auto-close a PR sometimes a bit impertinency.
>>> > > >>>>>>>>>>>>> The reasons just like Stephan mentioned.
>>> > > >>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>> Stephan Ewen <[hidden email]> 于2019年4月24日周三
>>> > > >>>>>>>>>>>>> 下午4:08写道：
>>> > > >>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>> About auto-closing PRs from unassigned issues,
>>> consider
>>> > the
>>> > > >>>>>>>>>> following
>>> > > >>>>>>>>>>>>> case
>>> > > >>>>>>>>>>>>>> that has happened quite a bit.
>>> > > >>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>       - a user reports a small bug and immediately
>>> wants
>>> > to
>>> > > >>>>>> provide a
>>> > > >>>>>>>>>> fix
>>> > > >>>>>>>>>>> for
>>> > > >>>>>>>>>>>>>> it
>>> > > >>>>>>>>>>>>>>       - it makes sense to not stall the user for a few
>>> > days
>>> > > >>>>>>>>>>>>>> until a
>>> > > >>>>>>>>>>> committer
>>> > > >>>>>>>>>>>>>> assigned the issue
>>> > > >>>>>>>>>>>>>>       - not auto-closing the PR would at least allow
>>> the
>>> > > >>>>>>>>>>>>>> user to
>>> > > >>>>>>>>>> provide
>>> > > >>>>>>>>>>>>> their
>>> > > >>>>>>>>>>>>>> patch.
>>> > > >>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen
>>> > > >>>>>>>>>>>>>> <[hidden email]>
>>> > > >>>>>>>>>>> wrote:
>>> > > >>>>>>>>>>>>>>> +1 for option #2
>>> > > >>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>> Seems to me that this does not contradict option #1,
>>> it
>>> > > only
>>> > > >>>>>>>>>> extends
>>> > > >>>>>>>>>>>>> this
>>> > > >>>>>>>>>>>>>>> a bit. I think there is a good case for that, to help
>>> > > >>>>>>>>>>>>>>> frequent
>>> > > >>>>>>>>>>>>>> contributors
>>> > > >>>>>>>>>>>>>>> on a way to committership.
>>> > > >>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>> @Konstantin: Trivial fixes (typos, docs, javadocs,
>>> ...)
>>> > > >>>>>>>>>>>>>>> should
>>> > > >>>>>>>>>> still
>>> > > >>>>>>>>>>> be
>>> > > >>>>>>>>>>>>>>> possible as "hotfixes".
>>> > > >>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>> On Mon, Apr 15, 2019 at 3:14 PM Timo Walther <
>>> > > >>>>>> [hidden email]>
>>> > > >>>>>>>>>>>>> wrote:
>>> > > >>>>>>>>>>>>>>>> I think this really depends on the contribution.
>>> > > >>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>> Sometimes "triviality" means that people just want
>>> to
>>> > fix
>>> > > a
>>> > > >>>>>> typo
>>> > > >>>>>>>>>> in
>>> > > >>>>>>>>>>>>> some
>>> > > >>>>>>>>>>>>>>>> docs. For this, a hotfix PR is sufficient and does
>>> not
>>> > > >>>>>>>>>>>>>>>> need a
>>> > > >>>>>>>>>> JIRA
>>> > > >>>>>>>>>>>>>> issue.
>>> > > >>>>>>>>>>>>>>>> However, sometimes "triviality" is only trivial at
>>> first
>>> > > >>>>>>>>>>>>>>>> glance
>>> > > >>>>>>>>>> but
>>> > > >>>>>>>>>>>>>>>> introduces side effects. In any case, any
>>> contribution
>>> > > >>>>>>>>>>>>>>>> needs to
>>> > > >>>>>>>>>> be
>>> > > >>>>>>>>>>>>>>>> reviewed and merged by a committer so follow-up
>>> > responses
>>> > > >>>>>>>>>>>>>>>> and
>>> > > >>>>>>>>>>>>> follow-up
>>> > > >>>>>>>>>>>>>>>> work might always be required. But you are right,
>>> > > committers
>>> > > >>>>>>>>>> need to
>>> > > >>>>>>>>>>>>>>>> respond quicker in any case.
>>> > > >>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>> Timo
>>> > > >>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>> Am 15.04.19 um 14:54 schrieb Konstantin Knauf:
>>> > > >>>>>>>>>>>>>>>>> Hi everyone,
>>> > > >>>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>>> just my two cents:  as a non-committer I
>>> appreciate a
>>> > > >>>>>>>>>> lightweight,
>>> > > >>>>>>>>>>>>>>>>> frictionless process for trivial changes or small
>>> fixes
>>> > > >>>>>> without
>>> > > >>>>>>>>>> the
>>> > > >>>>>>>>>>>>>>>> need to
>>> > > >>>>>>>>>>>>>>>>> approach a committer beforehand. If it takes 5
>>> days, so
>>> > > >>>>>>>>>>>>>>>>> that I
>>> > > >>>>>>>>>> can
>>> > > >>>>>>>>>>>>>> start
>>> > > >>>>>>>>>>>>>>>>> with a triviality, I might not bother in the first
>>> > > >>>>>>>>>>>>>>>>> place. So,
>>> > > >>>>>> in
>>> > > >>>>>>>>>>>>> order
>>> > > >>>>>>>>>>>>>>>> for
>>> > > >>>>>>>>>>>>>>>>> this not to backfire by making the community more
>>> > > >>>>>>>>>>>>>>>>> exclusive,
>>> > > >>>>>> we
>>> > > >>>>>>>>>> need
>>> > > >>>>>>>>>>>>>>>> more
>>> > > >>>>>>>>>>>>>>>>> timely responses & follow ups by committers after
>>> the
>>> > > >>>>>>>>>>>>>>>>> change
>>> > > >>>>>> to
>>> > > >>>>>>>>>> the
>>> > > >>>>>>>>>>>>>>>>> workflow. Having said that, I am slightly leaning
>>> > towards
>>> > > >>>>>>>>>> Andrey's
>>> > > >>>>>>>>>>>>>>>>> interpretation of option 2.
>>> > > >>>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>>> Cheers,
>>> > > >>>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>>> Konstantin
>>> > > >>>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>>> On Mon, Apr 15, 2019 at 1:39 PM Andrey Zagrebin <
>>> > > >>>>>>>>>>>>> [hidden email]
>>> > > >>>>>>>>>>>>>>>>> wrote:
>>> > > >>>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>>>> @Robert thanks for pointing out and sorry for
>>> > > >>>>>>>>>>>>>>>>>> confusion. The
>>> > > >>>>>>>>>>>>> correct
>>> > > >>>>>>>>>>>>>>>> text:
>>> > > >>>>>>>>>>>>>>>>>> +1 for option 1.
>>> > > >>>>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>>>> I also do not mind option 2, after 1-2
>>> contributions,
>>> > > any
>>> > > >>>>>>>>>>>>> contributor
>>> > > >>>>>>>>>>>>>>>> could
>>> > > >>>>>>>>>>>>>>>>>> just ask the committer (who merged those
>>> > contributions)
>>> > > >>>>>>>>>>>>>>>>>> about
>>> > > >>>>>>>>>>>>>>>> contributor
>>> > > >>>>>>>>>>>>>>>>>> permissions.
>>> > > >>>>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>>>> Best,
>>> > > >>>>>>>>>>>>>>>>>> Andrey
>>> > > >>>>>>>>>>>>>>>>>>
>>> > > >>>>>>>>>>>>>>>>>> On Mon, Apr 15, 2019 at 10:34 AM Feng LI <
>>> > > >>>>>>>>>> [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)
>>> > > >>>>>>>>>>>>>>>>>>>
>>> > > >>>
>>> > > >>
>>> > >
>>> > >
>>> >
>>>
>>

[kai wang]

There are many reasons for jira, and one of the most important reasons is
that flink varies greatly from version to version. However, I agree that
you restrict some rights of developers, including the right to assign and
edit.

Robert Metzger <[hidden email]> 于2019年7月19日周五 下午10:58写道：

> Hi all!
>
> Chesnay wrote:
>
> > We haven't wiped the set of contributors yet. Not sure if there's an
> > easy way to remove the permissions for all of them; someone from the PMC
> > may have to bite the bullet and click 600 times in a row :)
>
>
> I don't think there's an easy way for us.
> People with "Contributor" permissions have permissions such as "Closing"
> and "Editing" (including "Transition", "Logging work", etc.) issues.
> I would propose to either drastically reduce the number of people with
> Contributor permissions, leaving just those in, who are helping to keep our
> Jira in a clean shape (and this decision would be solely done at the
> discretion of the PMC deleting people from the contributor group)
> Another option would be to ask Infra to remove all people with Contributor
> permissions from Flink (deleting and re-adding the group or so :) )
> Moving forward, the PMC would maintain a list of contributors who are
> helping to keep Jira clean and well-organized.
>
> Tison wrote:
>
> > IIRC someone in this thread once mentioned that
> > "Don't allow contributors to set a blocker priority."
>
>
> Timo wrote this when he kicked off this thread. Sadly, this permission is
> not provided by Jira out of the box:
>
> https://community.atlassian.com/t5/Jira-questions/How-to-restrict-the-setting-of-certain-priorities-to-certain/qaq-p/193230
> We will have to manually monitor tickets with "Blocker" status.
>
>
> Fair enough, we might rephrase as
> > "Pull requests belonging to unassigned Jira tickets or not authored by
> > assignee will ..."
>
>
> That's a good point. If nobody disagrees, would you like to open PR for
> changing it?
>
> For the action "what should we do", iirc someone in this thread proposed
> > closing it via flinkbot. Or leaving without review and merge could be ok
> > before we implement automatic reply/reaction.
>
>
> I proposed to automatically close. I believe that this might be too harsh.
> I've implemented already an extension to Flinkbot which shows warnings for
> a pull request. I just haven't found the time to test the extension and put
> it in production.
>
>
>
> On Fri, Jul 19, 2019 at 5:51 AM Zili Chen <[hidden email]> wrote:
>
> > Fair enough, we might rephrase as
> >
> > "Pull requests belonging to unassigned Jira tickets or not authored by
> > assignee will ..."
> >
> > For the action "what should we do", iirc someone in this thread proposed
> > closing it via flinkbot. Or leaving without review and merge could be ok
> > before we implement automatic reply/reaction.
> >
> > Best,
> > tison.
> >
> >
> > Zili Chen <[hidden email]> 于2019年7月19日周五 上午11:44写道：
> >
> >> @Jack
> >>
> >> From https://flink.apache.org/contributing/contribute-code.html the
> >> community
> >> claims
> >>
> >> - Only start working on the implementation if there is consensus on the
> >> approach (e.g. you are assigned to the ticket)
> >>
> >> and accurately answer your question,
> >>
> >> - Pull requests belonging to unassigned Jira tickets will not be
> reviewed
> >> or merged by the community.
> >>
> >> Best,
> >> tison.
> >>
> >>
> >> Jark Wu <[hidden email]> 于2019年7月19日周五 上午11:28写道：
> >>
> >>> A quick question, what should we do if a developer creates a JIRA issue
> >>> and
> >>> then create a pull request at once without assigning?
> >>>
> >>>
> >>> Regards,
> >>> Jark
> >>>
> >>> On Thu, 18 Jul 2019 at 18:50, Zili Chen <[hidden email]> wrote:
> >>>
> >>> > Checking the result, as a discovery, I found that one can
> >>> > still file a JIRA with "blocker" priority.
> >>> >
> >>> > IIRC someone in this thread once mentioned that
> >>> > "Don't allow contributors to set a blocker priority."
> >>> >
> >>> > Chesnay,
> >>> >
> >>> > Thanks for the clarification.
> >>> >
> >>> >
> >>> > Best,
> >>> > tison.
> >>> >
> >>> >
> >>> > Chesnay Schepler <[hidden email]> 于2019年7月18日周四 下午6:40写道：
> >>> >
> >>> > > We haven't wiped the set of contributors yet. Not sure if there's
> an
> >>> > > easy way to remove the permissions for all of them; someone from
> the
> >>> PMC
> >>> > > may have to bite the bullet and click 600 times in a row :)
> >>> > >
> >>> > > On 18/07/2019 12:32, Zili Chen wrote:
> >>> > > > Robert,
> >>> > > >
> >>> > > > Thanks for your effort. Rejecting contributor permission request
> >>> > > > with a nice message and pointing them to the announcement sounds
> >>> > > > reasonable. Just to be clear, we now have no person with
> >>> contributor
> >>> > > > role, right?
> >>> > > >
> >>> > > > Chesnay,
> >>> > > >
> >>> > > > https://flink.apache.org/contributing/contribute-code.html has
> >>> been
> >>> > > > updated and mentions that "Only committers can assign a Jira
> >>> ticket."
> >>> > > >
> >>> > > > I think the corresponding update has been done.
> >>> > > >
> >>> > > > Best,
> >>> > > > tison.
> >>> > > >
> >>> > > >
> >>> > > > Chesnay Schepler <[hidden email]> 于2019年7月18日周四 下午6:25写道：
> >>> > > >
> >>> > > >> Do our contribution guidelines contain anything that should be
> >>> > updated?
> >>> > > >>
> >>> > > >> On 18/07/2019 12:24, Chesnay Schepler wrote:
> >>> > > >>> Sounds good to me.
> >>> > > >>>
> >>> > > >>> On 18/07/2019 12:07, Robert Metzger wrote:
> >>> > > >>>> Infra has finally changed the permissions. I just announced
> the
> >>> > > >>>> change in a
> >>> > > >>>> separate email [1].
> >>> > > >>>>
> >>> > > >>>> One thing I wanted to discuss here is, how do we want to
> handle
> >>> all
> >>> > > the
> >>> > > >>>> "contributor permissions" requests?
> >>> > > >>>>
> >>> > > >>>> My proposal is to basically reject them with a nice message,
> >>> > pointing
> >>> > > >>>> them
> >>> > > >>>> to my announcement.
> >>> > > >>>>
> >>> > > >>>> What do you think?
> >>> > > >>>>
> >>> > > >>>>
> >>> > > >>>>
> >>> > > >>>> [1]
> >>> > > >>>>
> >>> > > >>
> >>> > >
> >>> >
> >>>
> https://lists.apache.org/thread.html/4ed570c7110b7b55b5c3bd52bb61ff35d5bda88f47939d8e7f1844c4@%3Cdev.flink.apache.org%3E
> >>> > > >>>>
> >>> > > >>>>
> >>> > > >>>> On Thu, Jul 4, 2019 at 1:21 PM Robert Metzger <
> >>> [hidden email]>
> >>> > > >>>> wrote:
> >>> > > >>>>
> >>> > > >>>>> This is the Jira ticket I opened
> >>> > > >>>>> https://issues.apache.org/jira/browse/INFRA-18644 a long
> time
> >>> ago
> >>> > :)
> >>> > > >>>>>
> >>> > > >>>>> On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <
> >>> > [hidden email]
> >>> > > >
> >>> > > >>>>> wrote:
> >>> > > >>>>>
> >>> > > >>>>>> @Robert what's the state here?
> >>> > > >>>>>>
> >>> > > >>>>>> On 24/06/2019 16:16, Robert Metzger wrote:
> >>> > > >>>>>>> Hey all,
> >>> > > >>>>>>>
> >>> > > >>>>>>> I would like to drive this discussion to an end soon.
> >>> > > >>>>>>> I've just merged the updated contribution guide to the
> Flink
> >>> > > website:
> >>> > > >>>>>>> https://flink.apache.org/contributing/contribute-code.html
> >>> > > >>>>>>>
> >>> > > >>>>>>> I will now ask Apache IINFRA to change the permissions in
> our
> >>> > Jira.
> >>> > > >>>>>>>
> >>> > > >>>>>>> Here's the updated TODO list:
> >>> > > >>>>>>>
> >>> > > >>>>>>> 1. I update the contribution guide DONE
> >>> > > >>>>>>> 2. Update Flinkbot to close invalid PRs, and show warnings
> >>> on PRs
> >>> > > >>>>>>> with
> >>> > > >>>>>>> unassigned JIRAs IN PROGRESS
> >>> > > >>>>>>> 3. We ask Infra to change the permissions of our JIRA so
> >>> that: IN
> >>> > > >>>>>> PROGRESS
> >>> > > >>>>>>>      a) only committers can assign users to tickets
> >>> > > >>>>>>>      b) contributors can't assign users to tickets
> >>> > > >>>>>>>      c) Every registered JIRA user is an assignable user in
> >>> FLINK
> >>> > > >>>>>>>
> >>> > > >>>>>>>
> >>> > > >>>>>>>
> >>> > > >>>>>>>
> >>> > > >>>>>>>
> >>> > > >>>>>>> On Fri, May 24, 2019 at 9:18 AM Robert Metzger <
> >>> > > [hidden email]>
> >>> > > >>>>>> wrote:
> >>> > > >>>>>>>> Hey,
> >>> > > >>>>>>>>
> >>> > > >>>>>>>> I started working on step 1 and proposed some changes to
> the
> >>> > Flink
> >>> > > >>>>>>>> website: https://github.com/apache/flink-web/pull/217
> >>> > > >>>>>>>>
> >>> > > >>>>>>>>
> >>> > > >>>>>>>>
> >>> > > >>>>>>>> On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <
> >>> > > [hidden email]
> >>> > > >>>>>>>> wrote:
> >>> > > >>>>>>>>
> >>> > > >>>>>>>>> Hi Fabian,
> >>> > > >>>>>>>>> You are right, I made a mistake. I don't think it makes
> >>> sense
> >>> > to
> >>> > > >>>>>>>>> introduce a new permission class. This will make the life
> >>> of
> >>> > JIRA
> >>> > > >>>>>> admins
> >>> > > >>>>>>>>> unnecessarily complicated.
> >>> > > >>>>>>>>> I updated the task list:
> >>> > > >>>>>>>>>
> >>> > > >>>>>>>>> 1. I update the contribution guide
> >>> > > >>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show
> warnings
> >>> on
> >>> > > >>>>>>>>> PRs with
> >>> > > >>>>>>>>> unassigned JIRAs
> >>> > > >>>>>>>>> 3. We ask Infra to change the permissions of our JIRA so
> >>> that:
> >>> > > >>>>>>>>>      a) only committers can assign users to tickets
> >>> > > >>>>>>>>>      b) contributors can't assign users to tickets
> >>> > > >>>>>>>>>      c) Every registered JIRA user is an assignable user
> in
> >>> > FLINK
> >>> > > >>>>>>>>> 4. We remove all existing contributors
> >>> > > >>>>>>>>>
> >>> > > >>>>>>>>>
> >>> > > >>>>>>>>> On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <
> >>> > > [hidden email]>
> >>> > > >>>>>> wrote:
> >>> > > >>>>>>>>>> Hi Robert,
> >>> > > >>>>>>>>>>
> >>> > > >>>>>>>>>> If I understood the decision correctly, we also need to
> >>> ask
> >>> > > >>>>>>>>>> Infra to
> >>> > > >>>>>> make
> >>> > > >>>>>>>>>> everybody an assignable user, right?
> >>> > > >>>>>>>>>> Or do we want to add a new permission class "Assignable
> >>> User"
> >>> > > such
> >>> > > >>>>>> that
> >>> > > >>>>>>>>>> everyone still needs to ask for the right Jira
> >>> permissions?
> >>> > > >>>>>>>>>>
> >>> > > >>>>>>>>>> Fabian
> >>> > > >>>>>>>>>>
> >>> > > >>>>>>>>>>
> >>> > > >>>>>>>>>> Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther
> <
> >>> > > >>>>>>>>>> [hidden email]
> >>> > > >>>>>>>>>>> :
> >>> > > >>>>>>>>>>> Hi Robert,
> >>> > > >>>>>>>>>>>
> >>> > > >>>>>>>>>>> thanks for taking care of this. +1 to your suggested
> >>> steps.
> >>> > > >>>>>>>>>>>
> >>> > > >>>>>>>>>>> Regards,
> >>> > > >>>>>>>>>>> Timo
> >>> > > >>>>>>>>>>>
> >>> > > >>>>>>>>>>>
> >>> > > >>>>>>>>>>> Am 30.04.19 um 10:42 schrieb Robert Metzger:
> >>> > > >>>>>>>>>>>> @Stephan: I agree. Auto-closing PRs is quite
> aggressive.
> >>> > > >>>>>>>>>>>> I will only do that for PRs without JIRA ID or
> >>> "[hotfix]" in
> >>> > > the
> >>> > > >>>>>>>>>> title.
> >>> > > >>>>>>>>>>>> We can always revisit this at a later stage.
> >>> > > >>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>
> >>> > > >>>>>>>>>>>> I'm proposing the following steps:
> >>> > > >>>>>>>>>>>>
> >>> > > >>>>>>>>>>>> 1. I update the contribution guide
> >>> > > >>>>>>>>>>>> 2. Update Flinkbot to close invalid PRs, and show
> >>> warnings
> >>> > on
> >>> > > >>>>>>>>>>>> PRs
> >>> > > >>>>>>>>>> with
> >>> > > >>>>>>>>>>>> unassigned JIRAs
> >>> > > >>>>>>>>>>>> 3. We ask Infra to change the permissions of our JIRA
> so
> >>> > that:
> >>> > > >>>>>>>>>>>>       a) only committers can assign users to tickets
> >>> > > >>>>>>>>>>>>       b) contributors can't assign users to tickets
> >>> > > >>>>>>>>>>>> 4. We remove all existing contributors
> >>> > > >>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>
> >>> > > >>>>>>>>>>>> On Wed, Apr 24, 2019 at 11:17 AM vino yang
> >>> > > >>>>>>>>>>>> <[hidden email]>
> >>> > > >>>>>>>>>>> wrote:
> >>> > > >>>>>>>>>>>>> also +1 for option 2.
> >>> > > >>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>> I think auto-close a PR sometimes a bit impertinency.
> >>> > > >>>>>>>>>>>>> The reasons just like Stephan mentioned.
> >>> > > >>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>> Stephan Ewen <[hidden email]> 于2019年4月24日周三
> >>> > > >>>>>>>>>>>>> 下午4:08写道：
> >>> > > >>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>> About auto-closing PRs from unassigned issues,
> >>> consider
> >>> > the
> >>> > > >>>>>>>>>> following
> >>> > > >>>>>>>>>>>>> case
> >>> > > >>>>>>>>>>>>>> that has happened quite a bit.
> >>> > > >>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>       - a user reports a small bug and immediately
> >>> wants
> >>> > to
> >>> > > >>>>>> provide a
> >>> > > >>>>>>>>>> fix
> >>> > > >>>>>>>>>>> for
> >>> > > >>>>>>>>>>>>>> it
> >>> > > >>>>>>>>>>>>>>       - it makes sense to not stall the user for a
> few
> >>> > days
> >>> > > >>>>>>>>>>>>>> until a
> >>> > > >>>>>>>>>>> committer
> >>> > > >>>>>>>>>>>>>> assigned the issue
> >>> > > >>>>>>>>>>>>>>       - not auto-closing the PR would at least allow
> >>> the
> >>> > > >>>>>>>>>>>>>> user to
> >>> > > >>>>>>>>>> provide
> >>> > > >>>>>>>>>>>>> their
> >>> > > >>>>>>>>>>>>>> patch.
> >>> > > >>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>> On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen
> >>> > > >>>>>>>>>>>>>> <[hidden email]>
> >>> > > >>>>>>>>>>> wrote:
> >>> > > >>>>>>>>>>>>>>> +1 for option #2
> >>> > > >>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>> Seems to me that this does not contradict option
> #1,
> >>> it
> >>> > > only
> >>> > > >>>>>>>>>> extends
> >>> > > >>>>>>>>>>>>> this
> >>> > > >>>>>>>>>>>>>>> a bit. I think there is a good case for that, to
> help
> >>> > > >>>>>>>>>>>>>>> frequent
> >>> > > >>>>>>>>>>>>>> contributors
> >>> > > >>>>>>>>>>>>>>> on a way to committership.
> >>> > > >>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>> @Konstantin: Trivial fixes (typos, docs, javadocs,
> >>> ...)
> >>> > > >>>>>>>>>>>>>>> should
> >>> > > >>>>>>>>>> still
> >>> > > >>>>>>>>>>> be
> >>> > > >>>>>>>>>>>>>>> possible as "hotfixes".
> >>> > > >>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>> On Mon, Apr 15, 2019 at 3:14 PM Timo Walther <
> >>> > > >>>>>> [hidden email]>
> >>> > > >>>>>>>>>>>>> wrote:
> >>> > > >>>>>>>>>>>>>>>> I think this really depends on the contribution.
> >>> > > >>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>> Sometimes "triviality" means that people just want
> >>> to
> >>> > fix
> >>> > > a
> >>> > > >>>>>> typo
> >>> > > >>>>>>>>>> in
> >>> > > >>>>>>>>>>>>> some
> >>> > > >>>>>>>>>>>>>>>> docs. For this, a hotfix PR is sufficient and does
> >>> not
> >>> > > >>>>>>>>>>>>>>>> need a
> >>> > > >>>>>>>>>> JIRA
> >>> > > >>>>>>>>>>>>>> issue.
> >>> > > >>>>>>>>>>>>>>>> However, sometimes "triviality" is only trivial at
> >>> first
> >>> > > >>>>>>>>>>>>>>>> glance
> >>> > > >>>>>>>>>> but
> >>> > > >>>>>>>>>>>>>>>> introduces side effects. In any case, any
> >>> contribution
> >>> > > >>>>>>>>>>>>>>>> needs to
> >>> > > >>>>>>>>>> be
> >>> > > >>>>>>>>>>>>>>>> reviewed and merged by a committer so follow-up
> >>> > responses
> >>> > > >>>>>>>>>>>>>>>> and
> >>> > > >>>>>>>>>>>>> follow-up
> >>> > > >>>>>>>>>>>>>>>> work might always be required. But you are right,
> >>> > > committers
> >>> > > >>>>>>>>>> need to
> >>> > > >>>>>>>>>>>>>>>> respond quicker in any case.
> >>> > > >>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>> Timo
> >>> > > >>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>> Am 15.04.19 um 14:54 schrieb Konstantin Knauf:
> >>> > > >>>>>>>>>>>>>>>>> Hi everyone,
> >>> > > >>>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>>> just my two cents:  as a non-committer I
> >>> appreciate a
> >>> > > >>>>>>>>>> lightweight,
> >>> > > >>>>>>>>>>>>>>>>> frictionless process for trivial changes or small
> >>> fixes
> >>> > > >>>>>> without
> >>> > > >>>>>>>>>> the
> >>> > > >>>>>>>>>>>>>>>> need to
> >>> > > >>>>>>>>>>>>>>>>> approach a committer beforehand. If it takes 5
> >>> days, so
> >>> > > >>>>>>>>>>>>>>>>> that I
> >>> > > >>>>>>>>>> can
> >>> > > >>>>>>>>>>>>>> start
> >>> > > >>>>>>>>>>>>>>>>> with a triviality, I might not bother in the
> first
> >>> > > >>>>>>>>>>>>>>>>> place. So,
> >>> > > >>>>>> in
> >>> > > >>>>>>>>>>>>> order
> >>> > > >>>>>>>>>>>>>>>> for
> >>> > > >>>>>>>>>>>>>>>>> this not to backfire by making the community more
> >>> > > >>>>>>>>>>>>>>>>> exclusive,
> >>> > > >>>>>> we
> >>> > > >>>>>>>>>> need
> >>> > > >>>>>>>>>>>>>>>> more
> >>> > > >>>>>>>>>>>>>>>>> timely responses & follow ups by committers after
> >>> the
> >>> > > >>>>>>>>>>>>>>>>> change
> >>> > > >>>>>> to
> >>> > > >>>>>>>>>> the
> >>> > > >>>>>>>>>>>>>>>>> workflow. Having said that, I am slightly leaning
> >>> > towards
> >>> > > >>>>>>>>>> Andrey's
> >>> > > >>>>>>>>>>>>>>>>> interpretation of option 2.
> >>> > > >>>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>>> Cheers,
> >>> > > >>>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>>> Konstantin
> >>> > > >>>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>>> On Mon, Apr 15, 2019 at 1:39 PM Andrey Zagrebin <
> >>> > > >>>>>>>>>>>>> [hidden email]
> >>> > > >>>>>>>>>>>>>>>>> wrote:
> >>> > > >>>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>>>> @Robert thanks for pointing out and sorry for
> >>> > > >>>>>>>>>>>>>>>>>> confusion. The
> >>> > > >>>>>>>>>>>>> correct
> >>> > > >>>>>>>>>>>>>>>> text:
> >>> > > >>>>>>>>>>>>>>>>>> +1 for option 1.
> >>> > > >>>>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>>>> I also do not mind option 2, after 1-2
> >>> contributions,
> >>> > > any
> >>> > > >>>>>>>>>>>>> contributor
> >>> > > >>>>>>>>>>>>>>>> could
> >>> > > >>>>>>>>>>>>>>>>>> just ask the committer (who merged those
> >>> > contributions)
> >>> > > >>>>>>>>>>>>>>>>>> about
> >>> > > >>>>>>>>>>>>>>>> contributor
> >>> > > >>>>>>>>>>>>>>>>>> permissions.
> >>> > > >>>>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>>>> Best,
> >>> > > >>>>>>>>>>>>>>>>>> Andrey
> >>> > > >>>>>>>>>>>>>>>>>>
> >>> > > >>>>>>>>>>>>>>>>>> On Mon, Apr 15, 2019 at 10:34 AM Feng LI <
> >>> > > >>>>>>>>>> [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)
> >>> > > >>>>>>>>>>>>>>>>>>>
> >>> > > >>>
> >>> > > >>
> >>> > >
> >>> > >
> >>> >
> >>>
> >>
>