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
