Really nice idea Timo, Thanks for taking the initiative to open this discussion.
Although a side-effect, I consider it a big argument about my +1 the fact that now we create backpressure whenever needed at the JIRA level, rather than at the open PR level. The reason is that not accepting a PR after the contributor has spent cycles working on an issue, it can be a lot more demotivating than just waiting on the JIRA assignment to be completed. +1 from my side, Kostas On Mon, Feb 25, 2019 at 2:23 PM Timo Walther <twal...@apache.org> 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 > >
