I like the idea of pushing more for "discuss before opening a PR", and this could help with that part. We have to be clear though that this is not meant as a way to discourage contributions.
If we decide to switch to that mode, I think we need to - Concurrently update the contribution guide and help contributors understand the new workflow - Have a way to make sure that issues where someone offers help get a timely response (whatever the outcome is). The latter point is tricky. On Mon, Feb 25, 2019 at 3:54 PM Dawid Wysakowicz <dwysakow...@apache.org> wrote: > Hi, > > I think this is very valuable discussion and thank you for starting it. > > In general I am +1 for this proposal. I think though we must make it very > clear that this will require a careful handling by committers. There are at > least two cases that come to my mind that we need to be aware of: > > - this will require strict handling and good communication on PRs > opened without corresponding JIRA/without being assigned on a JIRA, this > happens quite a lot, > - we must make sure this will not increase the number of hotfixes, > - committers should be active with mentoring efforts (probably more > than we are currently). I agree that currently there are many PRs being > opened that lack consensus, proper description etc. There is though a > number of simpler fixes that are solved and merged quite fast now, which > might not get enough attention. The new process will require us to accept > such contribution twice (first allow contributor to work on it, second on > the PR itself). Right now if we see that this contribution is indeed a > simple one it happens only once on already opened PR. > > As I said I am +1 for those changes, but we should try hard so that this > effort improves contributors experience rather than make it harder. > > Best, > > Dawid > On 25/02/2019 15:31, Kostas Kloudas wrote: > > 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> > <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 > >
