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 <rmetz...@apache.org>
wrote:
This is the Jira ticket I opened
https://issues.apache.org/jira/browse/INFRA-18644 a long time ago :)
On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler <ches...@apache.org>
wrote:
@Robert what's the state here?
On 24/06/2019 16:16, Robert Metzger wrote:
Hey all,
I would like to drive this discussion to an end soon.
I've just merged the updated contribution guide to the Flink website:
https://flink.apache.org/contributing/contribute-code.html
I will now ask Apache IINFRA to change the permissions in our Jira.
Here's the updated TODO list:
1. I update the contribution guide DONE
2. Update Flinkbot to close invalid PRs, and show warnings on PRs
with
unassigned JIRAs IN PROGRESS
3. We ask Infra to change the permissions of our JIRA so that: IN
PROGRESS
a) only committers can assign users to tickets
b) contributors can't assign users to tickets
c) Every registered JIRA user is an assignable user in FLINK
On Fri, May 24, 2019 at 9:18 AM Robert Metzger <rmetz...@apache.org>
wrote:
Hey,
I started working on step 1 and proposed some changes to the Flink
website: https://github.com/apache/flink-web/pull/217
On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger <rmetz...@apache.org>
wrote:
Hi Fabian,
You are right, I made a mistake. I don't think it makes sense to
introduce a new permission class. This will make the life of JIRA
admins
unnecessarily complicated.
I updated the task list:
1. I update the contribution guide
2. Update Flinkbot to close invalid PRs, and show warnings on
PRs with
unassigned JIRAs
3. We ask Infra to change the permissions of our JIRA so that:
a) only committers can assign users to tickets
b) contributors can't assign users to tickets
c) Every registered JIRA user is an assignable user in FLINK
4. We remove all existing contributors
On Tue, Apr 30, 2019 at 12:00 PM Fabian Hueske <fhue...@gmail.com>
wrote:
Hi Robert,
If I understood the decision correctly, we also need to ask
Infra to
make
everybody an assignable user, right?
Or do we want to add a new permission class "Assignable User" such
that
everyone still needs to ask for the right Jira permissions?
Fabian
Am Di., 30. Apr. 2019 um 10:46 Uhr schrieb Timo Walther <
twal...@apache.org
:
Hi Robert,
thanks for taking care of this. +1 to your suggested steps.
Regards,
Timo
Am 30.04.19 um 10:42 schrieb Robert Metzger:
@Stephan: I agree. Auto-closing PRs is quite aggressive.
I will only do that for PRs without JIRA ID or "[hotfix]" in the
title.
We can always revisit this at a later stage.
I'm proposing the following steps:
1. I update the contribution guide
2. Update Flinkbot to close invalid PRs, and show warnings on
PRs
with
unassigned JIRAs
3. We ask Infra to change the permissions of our JIRA so that:
a) only committers can assign users to tickets
b) contributors can't assign users to tickets
4. We remove all existing contributors
On Wed, Apr 24, 2019 at 11:17 AM vino yang
<yanghua1...@gmail.com>
wrote:
also +1 for option 2.
I think auto-close a PR sometimes a bit impertinency.
The reasons just like Stephan mentioned.
Stephan Ewen <se...@apache.org> 于2019年4月24日周三
下午4:08写道：
About auto-closing PRs from unassigned issues, consider the
following
case
that has happened quite a bit.
- a user reports a small bug and immediately wants to
provide a
fix
for
it
- it makes sense to not stall the user for a few days
until a
committer
assigned the issue
- not auto-closing the PR would at least allow the
user to
provide
their
patch.
On Wed, Apr 24, 2019 at 10:00 AM Stephan Ewen
<se...@apache.org>
wrote:
+1 for option #2
Seems to me that this does not contradict option #1, it only
extends
this
a bit. I think there is a good case for that, to help
frequent
contributors
on a way to committership.
@Konstantin: Trivial fixes (typos, docs, javadocs, ...)
should
still
be
possible as "hotfixes".
On Mon, Apr 15, 2019 at 3:14 PM Timo Walther <
twal...@apache.org>
wrote:
I think this really depends on the contribution.
Sometimes "triviality" means that people just want to fix a
typo
in
some
docs. For this, a hotfix PR is sufficient and does not
need a
JIRA
issue.
However, sometimes "triviality" is only trivial at first
glance
but
introduces side effects. In any case, any contribution
needs to
be
reviewed and merged by a committer so follow-up responses
and
follow-up
work might always be required. But you are right, committers
need to
respond quicker in any case.
Timo
Am 15.04.19 um 14:54 schrieb Konstantin Knauf:
Hi everyone,
just my two cents: as a non-committer I appreciate a
lightweight,
frictionless process for trivial changes or small fixes
without
the
need to
approach a committer beforehand. If it takes 5 days, so
that I
can
start
with a triviality, I might not bother in the first
place. So,
in
order
for
this not to backfire by making the community more
exclusive,
we
need
more
timely responses & follow ups by committers after the
change
to
the
workflow. Having said that, I am slightly leaning towards
Andrey's
interpretation of option 2.
Cheers,
Konstantin
On Mon, Apr 15, 2019 at 1:39 PM Andrey Zagrebin <
and...@ververica.com
wrote:
@Robert thanks for pointing out and sorry for
confusion. The
correct
text:
+1 for option 1.
I also do not mind option 2, after 1-2 contributions, any
contributor
could
just ask the committer (who merged those contributions)
about
contributor
permissions.
Best,
Andrey
On Mon, Apr 15, 2019 at 10:34 AM Feng LI <
nemoking...@gmail.com>
wrote:
Hello there,
New to the community. Just thought you might want some
inputs
from
new
comers too.
I prefer option 2, where you need to prove the ability
and
commitment
with
commits before contributor permission is assigned.
Cheers,
Feng
Le lun. 15 avr. 2019 à 09:17, Robert Metzger <
rmetz...@apache.org
a
écrit :
@Andrey: You mention "option 2" two times, I guess
one of
the two
uses
of
"option 2" contains a typo?
On Wed, Apr 10, 2019 at 10:33 AM Andrey Zagrebin <
and...@ververica.com
wrote:
Hi all,
+1 for option 2.
I also do not mind option 2, after 1-2
contributions, any
contributor
could
just ask the committer (who merged those contributions)
about
contributor
permissions.
Best,
Andrey
On Wed, Apr 10, 2019 at 3:58 AM Robert Metzger <
rmetz...@apache.org
wrote:
I'm +1 on option 1.
On Tue, Apr 9, 2019 at 1:58 AM Timo Walther <
twal...@apache.org>
wrote:
Hi everyone,
I'd like to bring up this discussion thread again. In
summary, I
think
we all agreed on improving the JIRA workflow to move
design/consensus
discussions from PRs to the issues first, before
implementing
them.
Two options have been proposed:
1. Only committers can assign people to issues.
PRs of
unassigned
issues
are closed automatically.
2. Committers upgrade assignable users to
contributors
as
an
intermediate step towards committership.
I would prefer option 1 as some people also mentioned
that
option 2
requires some standadized processes otherwise it
would
be
difficult
to
communicate why somebody is a contributor and some
somebody is
not.
What do you think?
Regards,
Timo
Am 18.03.19 um 14:25 schrieb Robert Metzger:
@Fabian: I don't think this is a big problem. Moving
away
from
"giving
everybody contributor permissions" to "giving it to
some
people"
is
not
risky.
I would leave this decision to the committers who
are
working
with
a
person.
We should bring this discussion to a conclusion and
implement
the
changes
to JIRA.
Nobody has raised any objections to the overall
idea.
Points raised:
1. We need to update the contribution guide and
describe
the
workflow.
2. I brought up changing Flinkbot so that it
auto-closes
PRs
without
somebody assigned in JIRA.
Who wants to work on an update of the contribution
guide?
If there's no volunteers, I'm happy to take care of
this.
On Fri, Mar 15, 2019 at 9:20 AM Fabian Hueske <
fhue...@gmail.com
wrote:
Hi,
I'm not sure about adding an additional stage.
Who's going to decide when to "promote" a user to a
contributor,
i.e.,
grant assigning permission?
Best, Fabian
Am Do., 14. März 2019 um 13:50 Uhr schrieb Timo
Walther
<
twal...@apache.org
:
Hi Robert,
I also like the idea of making every Jira user an
"Assignable
User",
but
restrict assigning a ticket to people with
committer
permissions.
Instead of giving contributor permissions to
everyone,
we
could
have
a
more staged approach from user, to contributor,
and
finally
to
committer.
Once people worked on a couple of JIRA issues,
we can
make
them
contributors.
What do you think?
Regards,
Timo
Am 06.03.19 um 12:33 schrieb Robert Metzger:
Hi Tison,
I also thought about this.
Making a person a "Contributor" is required for
being
an
"Assignable
User",
so normal Jira accounts can't be assigned to a
ticket.
We could make every Jira user an "Assignable
User",
but
restrict
assigning
a ticket to people with committer permissions.
There are some other permissions attached to the
"Contributor"
role,
such
as "Closing" and "Editing" (including
"Transition",
"Logging
work",
etc.).
I think we should keep the "Contributor" role,
but
we
could
be
(as
you
propose) make it more restrictive. Maybe "invite
only" for
people
who
are
apparently active in our Jira.
Best,
Robert
On Wed, Mar 6, 2019 at 11:02 AM ZiLi Chen <
wander4...@gmail.com
wrote:
Hi devs,
Just now I find that one not a contributor
can file
issue
and
participant
discussion.
One becomes contributor can additionally
assign an
issue
to a
person
and
modify fields of any issues.
For a more restrictive JIRA workflow, maybe we
achieve it
by
making
it a
bit more
restrictive granting contributor permission?
Best,
tison.
Robert Metzger <rmetz...@apache.org>
于2019年2月27日周三
下午9:53写道：
I like this idea and I would like to try it
to see
if it
solves
the
problem.
I can also offer to add a functionality to the
Flinkbot
to
automatically
close pull requests which have been opened
against a
unassigned
JIRA
ticket.
Being rejected by an automated system, which
just
applies
a
rule
is
nicer
than being rejected by a person.
On Wed, Feb 27, 2019 at 1:45 PM Stephan Ewen <
se...@apache.org>
wrote:
@Chesnay - yes, this is possible, according to
infra.
On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <
wander4...@gmail.com
wrote:
Hi,
@Hequn
It might be hard to separate JIRAs into
conditional
and
unconditional
ones.
Even if INFRA supports such separation, we
meet
the
problem
that
whether
a contributor is granted to decide the
type of a
JIRA.
If
so,
then
contributors might
tend to create JIRAs as unconditional; and if
not, we
fallback
that a
contributor
ask a committer for setting the JIRA as
unconditional,
which
is
no
better
than
ask a committer for assigning to the
contributor.
@Timo
"More discussion before opening a PR" sounds
good.
However,
it
requires
more
effort/participation from committer's
side. From
my
own
side,
it's
exciting
to
see our committers become more active :-)
Best,
tison.
Chesnay Schepler <ches...@apache.org>
于2019年2月27日周三
下午5:06写道：
We currently cannot change the JIRA
permissions.
Have
you
asked
INFRA
whether it is possible to setup a
Flink-specific
permission
scheme?
On 25.02.2019 14:23, Timo Walther wrote:
Hi everyone,
as some of you might have noticed during
the
last
weeks,
the
Flink
community grew quite a bit. A lot of people
have
applied
for
contributor permissions and started
working on
issues,
which
is
great
for the growth of Flink!
However, we've also observed that managing
JIRA
and
coordinate
work
and responsibilities becomes more
complex as
more
people
are
joining.
Here are some observations to examplify the
current
challenges:
- There is a high number of concurrent
discussion
about
new
features
or important refactorings.
- JIRA issues are being created for
components
to:
- represent an implementation plan
(e.g.
of a
FLIP)
- track progress of the feature by
splitting
it
into a
finer
granularity
- coordinate work between
contributors/contributor
teams
- Lack of guidance for new contributors:
Contributors
don't
know
which
issues to pick but are motivated to work on
something.
- Contributors pick issues that:
- require very good (historical)
knowledge of
a
component
- need to be implemented in a timely
fashion
as
they
block
other
contributors or a Flink release
- have implicit dependencies on
other
changes
- Contributors open pull requests with a
bad
description,
without
consensus, or an unsatisfactory
architecture.
Shortcomings
that
could
have been solved in JIRA before.
- Committers don't open issues because they
fear
that
some
"random"
contributor picks it up or assign many
issues
to
themselves
to
"protect" them. Even though they don't have
the
capacity
to
solve
all
of them.
I propose to make our JIRA a bit more
restrictive:
- Don't allow contributors to assign
issues to
themselves.
This
forces
them to find supporters first. As
mentioned in
the
contribution
guidelines [1]: "reach consensus with the
community".
Only
committers
can assign people to issues.
- Don't allow contributors to set a fixed
version or
release
notes.
Only committers should do that after
merging
the
contribution.
- Don't allow contributors to set a blocker
priority.
The
release
manager should decide about that.
As a nice side-effect, it might also impact
the
number
of
stale
pull
requests by moving the consensus and design
discussion
to
an
earlier
phase in the process.
What do you think? Feel free to propose
more
workflow
improvements.
Of
course we need to check with INFRA if
this can
be
represented
in
our
JIRA.
Thanks,
Timo
[1]
https://flink.apache.org/contribute-code.html
--
Feng (Sent from my phone)
