Hi Tison, I also thought about this. Making a person a "Contributor" is required for being an "Assignable User", so normal Jira accounts can't be assigned to a ticket.
We could make every Jira user an "Assignable User", but restrict assigning a ticket to people with committer permissions. There are some other permissions attached to the "Contributor" role, such as "Closing" and "Editing" (including "Transition", "Logging work", etc.). I think we should keep the "Contributor" role, but we could be (as you propose) make it more restrictive. Maybe "invite only" for people who are apparently active in our Jira. Best, Robert On Wed, Mar 6, 2019 at 11:02 AM ZiLi Chen <wander4...@gmail.com> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
