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> 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
>>
>>
signature.asc
Description: OpenPGP digital signature
