Hi, I'm not sure about adding an additional stage. Who's going to decide when to "promote" a user to a contributor, i.e., grant assigning permission?
Best, Fabian Am Do., 14. März 2019 um 13:50 Uhr schrieb Timo Walther <twal...@apache.org >: > Hi Robert, > > I also like the idea of making every Jira user an "Assignable User", but > restrict assigning a ticket to people with committer permissions. > > Instead of giving contributor permissions to everyone, we could have a > more staged approach from user, to contributor, and finally to committer. > > Once people worked on a couple of JIRA issues, we can make them > contributors. > > What do you think? > > Regards, > Timo > > Am 06.03.19 um 12:33 schrieb Robert Metzger: > > 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 > >>>>>>> > >>>>>>> > >>>>>> > >
