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)
