Hi, @Hequn It might be hard to separate JIRAs into conditional and unconditional ones.
Even if INFRA supports such separation, we meet the problem that whether a contributor is granted to decide the type of a JIRA. If so, then contributors might tend to create JIRAs as unconditional; and if not, we fallback that a contributor ask a committer for setting the JIRA as unconditional, which is no better than ask a committer for assigning to the contributor. @Timo "More discussion before opening a PR" sounds good. However, it requires more effort/participation from committer's side. From my own side, it's exciting to see our committers become more active :-) Best, tison. Chesnay Schepler <ches...@apache.org> 于2019年2月27日周三 下午5:06写道： > We currently cannot change the JIRA permissions. Have you asked INFRA > whether it is possible to setup a Flink-specific permission scheme? > > On 25.02.2019 14:23, Timo Walther 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 > > > > > >
