Hi devs, Just now I find that one not a contributor can file issue and participant discussion. One becomes contributor can additionally assign an issue to a person and modify fields of any issues.
For a more restrictive JIRA workflow, maybe we achieve it by making it a bit more restrictive granting contributor permission? Best, tison. Robert Metzger <rmetz...@apache.org> 于2019年2月27日周三 下午9:53写道： > I like this idea and I would like to try it to see if it solves the > problem. > > I can also offer to add a functionality to the Flinkbot to automatically > close pull requests which have been opened against a unassigned JIRA > ticket. > Being rejected by an automated system, which just applies a rule is nicer > than being rejected by a person. > > > On Wed, Feb 27, 2019 at 1:45 PM Stephan Ewen <se...@apache.org> wrote: > > > @Chesnay - yes, this is possible, according to infra. > > > > On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen <wander4...@gmail.com> wrote: > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > >
