Hi, Timo Thanks for putting this together and bring the discussion. +1 to making our JIRAs a bit more restrictive! I think this makes a good point of view. It would be helpful to force the contributors to think more about the issues rather than take it directly or maybe rashly.
One little suggestion: In order not to discourage contributors, maybe we can separate our JIRAs into two categories, the conditional ones and the unconditional ones. Contributors can take the unconditional ones freely while need help from committers to take the conditional ones. Best, Hequn On Wed, Feb 27, 2019 at 1:36 AM Stephan Ewen <se...@apache.org> wrote: > 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 > > > > >
