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
