@Fabian: I don't think this is a big problem. Moving away from "giving everybody contributor permissions" to "giving it to some people" is not risky. I would leave this decision to the committers who are working with a person.
We should bring this discussion to a conclusion and implement the changes to JIRA. Nobody has raised any objections to the overall idea. Points raised: 1. We need to update the contribution guide and describe the workflow. 2. I brought up changing Flinkbot so that it auto-closes PRs without somebody assigned in JIRA. Who wants to work on an update of the contribution guide? If there's no volunteers, I'm happy to take care of this. On Fri, Mar 15, 2019 at 9:20 AM Fabian Hueske <fhue...@gmail.com> wrote: > 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 > > >>>>>>> > > >>>>>>> > > >>>>>> > > > > >
