Hi all!
This thread is dedicated to discuss the tooling we want to use for the reviews. It is spun out of the proposal *"A more structured approach to reviews and contributions".* *Suggestions brought up so far* *Use comments / template with checklist* - Easy to do - Manual, a bit of reviewer overhead, reviewers needs to know the process *Use a bot * - Automatically add the review questions to each new PR - Further details? *Use GitHub labels* - Searchable - possibly not obvious to new contributors - Any restrictions? Do members need to apply at ASF infra to have permissions to edit github labels? |
As a new contributor I cared about how to make my contribution accepted by the community, some questions:
1) When will it get reviewed? Is there a rule about review timeline? 2) There are long backlog of pull requests, What happened if a pull request not get noticed, do we have some mechanism to make it moving forward, like a pull request will be assigned a owner of reviewer? Or we have a review queue and a pull request will be get handled fairly. Jin > On Sep 20, 2018, at 12:56 PM, Stephan Ewen <[hidden email]> wrote: > > Hi all! > > This thread is dedicated to discuss the tooling we want to use for the > reviews. > It is spun out of the proposal *"A more structured approach to reviews and > contributions".* > > > *Suggestions brought up so far* > > > *Use comments / template with checklist* > > - Easy to do > - Manual, a bit of reviewer overhead, reviewers needs to know the process > > *Use a bot * > > - Automatically add the review questions to each new PR > - Further details? > > *Use GitHub labels* > > - Searchable > - possibly not obvious to new contributors > - Any restrictions? Do members need to apply at ASF infra to have > permissions to edit github labels? |
Hi Jin Sun,
Earlier this year, I also had these questions when I started contributing code to Flink. In fact, the timing of a PR being reviewed will be related to the priority of the problem solved by the PR. And when you indicate the module to which it belongs in the title of the PR, like "[FLINK-xxxx][module] XXXX", the person in charge of the relevant module or the contributor who is familiar with it will find it easier. To Stephan: Maybe we can open a separate mail thread (after all, the current discussion thread is about a specific topic) to hear the contributors about PR review related questions and doubts. Perhaps some of their feedback will help the community improve the way they review. Thanks, vino. Jin Sun <[hidden email]> 于2018年9月22日周六 上午6:40写道: > As a new contributor I cared about how to make my contribution accepted by > the community, some questions: > 1) When will it get reviewed? Is there a rule about review timeline? > 2) There are long backlog of pull requests, What happened if a pull > request not get noticed, do we have some mechanism to make it moving > forward, like a pull request will be assigned a owner of reviewer? Or we > have a review queue and a pull request will be get handled fairly. > > Jin > > > > On Sep 20, 2018, at 12:56 PM, Stephan Ewen <[hidden email]> wrote: > > > > Hi all! > > > > This thread is dedicated to discuss the tooling we want to use for the > > reviews. > > It is spun out of the proposal *"A more structured approach to reviews > and > > contributions".* > > > > > > *Suggestions brought up so far* > > > > > > *Use comments / template with checklist* > > > > - Easy to do > > - Manual, a bit of reviewer overhead, reviewers needs to know the > process > > > > *Use a bot * > > > > - Automatically add the review questions to each new PR > > - Further details? > > > > *Use GitHub labels* > > > > - Searchable > > - possibly not obvious to new contributors > > - Any restrictions? Do members need to apply at ASF infra to have > > permissions to edit github labels? > > |
In Beam, we have a bot that regularly nags people about inactive PRs and also closes them after long inactivity.
And we use the github feature for assigning reviewers in github. Sometimes it is hard for people to judge how "valuable" a PR is. Maybe some knowledgable people could mark PRs as valuable if they think it's a good addition but if they don't have the review bandwith. Other people can then search for valuable PRs that don't yet a reviewer and review/merge them. Aljoscha > On 22. Sep 2018, at 04:25, vino yang <[hidden email]> wrote: > > Hi Jin Sun, > > Earlier this year, I also had these questions when I started contributing > code to Flink. In fact, the timing of a PR being reviewed will be related > to the priority of the problem solved by the PR. > And when you indicate the module to which it belongs in the title of the > PR, like "[FLINK-xxxx][module] XXXX", the person in charge of the relevant > module or the contributor who is familiar with it will find it easier. > > To Stephan: > > Maybe we can open a separate mail thread (after all, the current discussion > thread is about a specific topic) to hear the contributors about PR review > related questions and doubts. Perhaps some of their feedback will help the > community improve the way they review. > > Thanks, vino. > > Jin Sun <[hidden email]> 于2018年9月22日周六 上午6:40写道: > >> As a new contributor I cared about how to make my contribution accepted by >> the community, some questions: >> 1) When will it get reviewed? Is there a rule about review timeline? >> 2) There are long backlog of pull requests, What happened if a pull >> request not get noticed, do we have some mechanism to make it moving >> forward, like a pull request will be assigned a owner of reviewer? Or we >> have a review queue and a pull request will be get handled fairly. >> >> Jin >> >> >>> On Sep 20, 2018, at 12:56 PM, Stephan Ewen <[hidden email]> wrote: >>> >>> Hi all! >>> >>> This thread is dedicated to discuss the tooling we want to use for the >>> reviews. >>> It is spun out of the proposal *"A more structured approach to reviews >> and >>> contributions".* >>> >>> >>> *Suggestions brought up so far* >>> >>> >>> *Use comments / template with checklist* >>> >>> - Easy to do >>> - Manual, a bit of reviewer overhead, reviewers needs to know the >> process >>> >>> *Use a bot * >>> >>> - Automatically add the review questions to each new PR >>> - Further details? >>> >>> *Use GitHub labels* >>> >>> - Searchable >>> - possibly not obvious to new contributors >>> - Any restrictions? Do members need to apply at ASF infra to have >>> permissions to edit github labels? >> >> |
Hi,
About "valuable", I agree with @Aljoscha that there is no clear standard of judgment about "valuable". But I think the priority may be a more specific indicator, because the JIRA issue also has a "Priority" attribute. Maybe we can tag the PR, for example: use the "Label" function of github, or add the "[Priority]" tag to the PR title? Regarding the closure of inactive PR, I feel that it is more cautious to shut down artificially. Whether it is possible to explicitly assign a PR to a committer familiar with the module, which will reduce the unnecessary ping operation of many contributors. Because some people don't know which committer is familiar with the module he changed. Thanks, vino. Aljoscha Krettek <[hidden email]> 于2018年9月24日周一 下午5:03写道: > In Beam, we have a bot that regularly nags people about inactive PRs and > also closes them after long inactivity. > > And we use the github feature for assigning reviewers in github. > > Sometimes it is hard for people to judge how "valuable" a PR is. Maybe > some knowledgable people could mark PRs as valuable if they think it's a > good addition but if they don't have the review bandwith. Other people can > then search for valuable PRs that don't yet a reviewer and review/merge > them. > > Aljoscha > > > On 22. Sep 2018, at 04:25, vino yang <[hidden email]> wrote: > > > > Hi Jin Sun, > > > > Earlier this year, I also had these questions when I started contributing > > code to Flink. In fact, the timing of a PR being reviewed will be related > > to the priority of the problem solved by the PR. > > And when you indicate the module to which it belongs in the title of the > > PR, like "[FLINK-xxxx][module] XXXX", the person in charge of the > relevant > > module or the contributor who is familiar with it will find it easier. > > > > To Stephan: > > > > Maybe we can open a separate mail thread (after all, the current > discussion > > thread is about a specific topic) to hear the contributors about PR > review > > related questions and doubts. Perhaps some of their feedback will help > the > > community improve the way they review. > > > > Thanks, vino. > > > > Jin Sun <[hidden email]> 于2018年9月22日周六 上午6:40写道: > > > >> As a new contributor I cared about how to make my contribution accepted > by > >> the community, some questions: > >> 1) When will it get reviewed? Is there a rule about review timeline? > >> 2) There are long backlog of pull requests, What happened if a pull > >> request not get noticed, do we have some mechanism to make it moving > >> forward, like a pull request will be assigned a owner of reviewer? Or we > >> have a review queue and a pull request will be get handled fairly. > >> > >> Jin > >> > >> > >>> On Sep 20, 2018, at 12:56 PM, Stephan Ewen <[hidden email]> wrote: > >>> > >>> Hi all! > >>> > >>> This thread is dedicated to discuss the tooling we want to use for the > >>> reviews. > >>> It is spun out of the proposal *"A more structured approach to reviews > >> and > >>> contributions".* > >>> > >>> > >>> *Suggestions brought up so far* > >>> > >>> > >>> *Use comments / template with checklist* > >>> > >>> - Easy to do > >>> - Manual, a bit of reviewer overhead, reviewers needs to know the > >> process > >>> > >>> *Use a bot * > >>> > >>> - Automatically add the review questions to each new PR > >>> - Further details? > >>> > >>> *Use GitHub labels* > >>> > >>> - Searchable > >>> - possibly not obvious to new contributors > >>> - Any restrictions? Do members need to apply at ASF infra to have > >>> permissions to edit github labels? > >> > >> > > |
Hi,
Coming back to the original topic of the thread: How to implement the guided review process. I am in favor of starting with a low-tech solution. We design a review template with a checkbox for the five questions (see [1]) and a link to the detailed description of the review process ([1] will be added to flink.apache.org). Once a PR is opened, anybody (the PR author, a committer, any reviewer, ...) can post the review template as a comment. Ideally this happens shortly after the PR was opened. If we find it necessary, we can later add a bot to automate posting the template as comment. Once the template is posted, the PR can be reviewed by following the process and answering the template questions. When all boxes are ticked off, the PR can be merged. Best, Fabian [1] https://docs.google.com/document/d/1yaX2b9LNh-6LxrAmE23U3D2cRbocGlGKCYnvJd9lVhk/ Am Mo., 24. Sep. 2018 um 12:27 Uhr schrieb vino yang <[hidden email] >: > Hi, > > About "valuable", I agree with @Aljoscha that there is no clear standard of > judgment about "valuable". > But I think the priority may be a more specific indicator, because the JIRA > issue also has a "Priority" attribute. > Maybe we can tag the PR, for example: use the "Label" function of github, > or add the "[Priority]" tag to the PR title? > > Regarding the closure of inactive PR, I feel that it is more cautious to > shut down artificially. > Whether it is possible to explicitly assign a PR to a committer familiar > with the module, which will reduce the unnecessary ping operation of many > contributors. > Because some people don't know which committer is familiar with the module > he changed. > > Thanks, vino. > > Aljoscha Krettek <[hidden email]> 于2018年9月24日周一 下午5:03写道: > > > In Beam, we have a bot that regularly nags people about inactive PRs and > > also closes them after long inactivity. > > > > And we use the github feature for assigning reviewers in github. > > > > Sometimes it is hard for people to judge how "valuable" a PR is. Maybe > > some knowledgable people could mark PRs as valuable if they think it's a > > good addition but if they don't have the review bandwith. Other people > can > > then search for valuable PRs that don't yet a reviewer and review/merge > > them. > > > > Aljoscha > > > > > On 22. Sep 2018, at 04:25, vino yang <[hidden email]> wrote: > > > > > > Hi Jin Sun, > > > > > > Earlier this year, I also had these questions when I started > contributing > > > code to Flink. In fact, the timing of a PR being reviewed will be > related > > > to the priority of the problem solved by the PR. > > > And when you indicate the module to which it belongs in the title of > the > > > PR, like "[FLINK-xxxx][module] XXXX", the person in charge of the > > relevant > > > module or the contributor who is familiar with it will find it easier. > > > > > > To Stephan: > > > > > > Maybe we can open a separate mail thread (after all, the current > > discussion > > > thread is about a specific topic) to hear the contributors about PR > > review > > > related questions and doubts. Perhaps some of their feedback will help > > the > > > community improve the way they review. > > > > > > Thanks, vino. > > > > > > Jin Sun <[hidden email]> 于2018年9月22日周六 上午6:40写道: > > > > > >> As a new contributor I cared about how to make my contribution > accepted > > by > > >> the community, some questions: > > >> 1) When will it get reviewed? Is there a rule about review timeline? > > >> 2) There are long backlog of pull requests, What happened if a pull > > >> request not get noticed, do we have some mechanism to make it moving > > >> forward, like a pull request will be assigned a owner of reviewer? Or > we > > >> have a review queue and a pull request will be get handled fairly. > > >> > > >> Jin > > >> > > >> > > >>> On Sep 20, 2018, at 12:56 PM, Stephan Ewen <[hidden email]> wrote: > > >>> > > >>> Hi all! > > >>> > > >>> This thread is dedicated to discuss the tooling we want to use for > the > > >>> reviews. > > >>> It is spun out of the proposal *"A more structured approach to > reviews > > >> and > > >>> contributions".* > > >>> > > >>> > > >>> *Suggestions brought up so far* > > >>> > > >>> > > >>> *Use comments / template with checklist* > > >>> > > >>> - Easy to do > > >>> - Manual, a bit of reviewer overhead, reviewers needs to know the > > >> process > > >>> > > >>> *Use a bot * > > >>> > > >>> - Automatically add the review questions to each new PR > > >>> - Further details? > > >>> > > >>> *Use GitHub labels* > > >>> > > >>> - Searchable > > >>> - possibly not obvious to new contributors > > >>> - Any restrictions? Do members need to apply at ASF infra to have > > >>> permissions to edit github labels? > > >> > > >> > > > > > |
Hi everyone,
Instead of manually adding the review progress template as a comment to every new PR, we could also append it to the PR description template. The benefits would be: + no need to add it manually since it is automatically added to each PR + the template is versioned in the Flink Git repository + contributors can learn about the review process before opening a PR On the downside, the template grows a bit at the end. What do you think? Best, Fabian Am Mo., 24. Sep. 2018 um 15:51 Uhr schrieb Fabian Hueske <[hidden email] >: > Hi, > > Coming back to the original topic of the thread: How to implement the > guided review process. > > I am in favor of starting with a low-tech solution. > We design a review template with a checkbox for the five questions (see > [1]) and a link to the detailed description of the review process ([1] will > be added to flink.apache.org). > Once a PR is opened, anybody (the PR author, a committer, any reviewer, > ...) can post the review template as a comment. Ideally this happens > shortly after the PR was opened. > If we find it necessary, we can later add a bot to automate posting the > template as comment. > > Once the template is posted, the PR can be reviewed by following the > process and answering the template questions. > When all boxes are ticked off, the PR can be merged. > > Best, > Fabian > > > > > > [1] > https://docs.google.com/document/d/1yaX2b9LNh-6LxrAmE23U3D2cRbocGlGKCYnvJd9lVhk/ > > > Am Mo., 24. Sep. 2018 um 12:27 Uhr schrieb vino yang < > [hidden email]>: > >> Hi, >> >> About "valuable", I agree with @Aljoscha that there is no clear standard >> of >> judgment about "valuable". >> But I think the priority may be a more specific indicator, because the >> JIRA >> issue also has a "Priority" attribute. >> Maybe we can tag the PR, for example: use the "Label" function of github, >> or add the "[Priority]" tag to the PR title? >> >> Regarding the closure of inactive PR, I feel that it is more cautious to >> shut down artificially. >> Whether it is possible to explicitly assign a PR to a committer familiar >> with the module, which will reduce the unnecessary ping operation of many >> contributors. >> Because some people don't know which committer is familiar with the module >> he changed. >> >> Thanks, vino. >> >> Aljoscha Krettek <[hidden email]> 于2018年9月24日周一 下午5:03写道: >> >> > In Beam, we have a bot that regularly nags people about inactive PRs and >> > also closes them after long inactivity. >> > >> > And we use the github feature for assigning reviewers in github. >> > >> > Sometimes it is hard for people to judge how "valuable" a PR is. Maybe >> > some knowledgable people could mark PRs as valuable if they think it's a >> > good addition but if they don't have the review bandwith. Other people >> can >> > then search for valuable PRs that don't yet a reviewer and review/merge >> > them. >> > >> > Aljoscha >> > >> > > On 22. Sep 2018, at 04:25, vino yang <[hidden email]> wrote: >> > > >> > > Hi Jin Sun, >> > > >> > > Earlier this year, I also had these questions when I started >> contributing >> > > code to Flink. In fact, the timing of a PR being reviewed will be >> related >> > > to the priority of the problem solved by the PR. >> > > And when you indicate the module to which it belongs in the title of >> the >> > > PR, like "[FLINK-xxxx][module] XXXX", the person in charge of the >> > relevant >> > > module or the contributor who is familiar with it will find it easier. >> > > >> > > To Stephan: >> > > >> > > Maybe we can open a separate mail thread (after all, the current >> > discussion >> > > thread is about a specific topic) to hear the contributors about PR >> > review >> > > related questions and doubts. Perhaps some of their feedback will help >> > the >> > > community improve the way they review. >> > > >> > > Thanks, vino. >> > > >> > > Jin Sun <[hidden email]> 于2018年9月22日周六 上午6:40写道: >> > > >> > >> As a new contributor I cared about how to make my contribution >> accepted >> > by >> > >> the community, some questions: >> > >> 1) When will it get reviewed? Is there a rule about review timeline? >> > >> 2) There are long backlog of pull requests, What happened if a pull >> > >> request not get noticed, do we have some mechanism to make it moving >> > >> forward, like a pull request will be assigned a owner of reviewer? >> Or we >> > >> have a review queue and a pull request will be get handled fairly. >> > >> >> > >> Jin >> > >> >> > >> >> > >>> On Sep 20, 2018, at 12:56 PM, Stephan Ewen <[hidden email]> >> wrote: >> > >>> >> > >>> Hi all! >> > >>> >> > >>> This thread is dedicated to discuss the tooling we want to use for >> the >> > >>> reviews. >> > >>> It is spun out of the proposal *"A more structured approach to >> reviews >> > >> and >> > >>> contributions".* >> > >>> >> > >>> >> > >>> *Suggestions brought up so far* >> > >>> >> > >>> >> > >>> *Use comments / template with checklist* >> > >>> >> > >>> - Easy to do >> > >>> - Manual, a bit of reviewer overhead, reviewers needs to know the >> > >> process >> > >>> >> > >>> *Use a bot * >> > >>> >> > >>> - Automatically add the review questions to each new PR >> > >>> - Further details? >> > >>> >> > >>> *Use GitHub labels* >> > >>> >> > >>> - Searchable >> > >>> - possibly not obvious to new contributors >> > >>> - Any restrictions? Do members need to apply at ASF infra to have >> > >>> permissions to edit github labels? >> > >> >> > >> >> > >> > >> > |
+1,
Agree to use the PR template. Fabian Hueske <[hidden email]> 于2018年10月17日周三 上午12:48写道: > Hi everyone, > > Instead of manually adding the review progress template as a comment to > every new PR, we could also append it to the PR description template. > The benefits would be: > + no need to add it manually since it is automatically added to each PR > + the template is versioned in the Flink Git repository > + contributors can learn about the review process before opening a PR > > On the downside, the template grows a bit at the end. > > What do you think? > > Best, Fabian > > Am Mo., 24. Sep. 2018 um 15:51 Uhr schrieb Fabian Hueske < > [hidden email] > >: > > > Hi, > > > > Coming back to the original topic of the thread: How to implement the > > guided review process. > > > > I am in favor of starting with a low-tech solution. > > We design a review template with a checkbox for the five questions (see > > [1]) and a link to the detailed description of the review process ([1] > will > > be added to flink.apache.org). > > Once a PR is opened, anybody (the PR author, a committer, any reviewer, > > ...) can post the review template as a comment. Ideally this happens > > shortly after the PR was opened. > > If we find it necessary, we can later add a bot to automate posting the > > template as comment. > > > > Once the template is posted, the PR can be reviewed by following the > > process and answering the template questions. > > When all boxes are ticked off, the PR can be merged. > > > > Best, > > Fabian > > > > > > > > > > > > [1] > > > https://docs.google.com/document/d/1yaX2b9LNh-6LxrAmE23U3D2cRbocGlGKCYnvJd9lVhk/ > > > > > > Am Mo., 24. Sep. 2018 um 12:27 Uhr schrieb vino yang < > > [hidden email]>: > > > >> Hi, > >> > >> About "valuable", I agree with @Aljoscha that there is no clear standard > >> of > >> judgment about "valuable". > >> But I think the priority may be a more specific indicator, because the > >> JIRA > >> issue also has a "Priority" attribute. > >> Maybe we can tag the PR, for example: use the "Label" function of > github, > >> or add the "[Priority]" tag to the PR title? > >> > >> Regarding the closure of inactive PR, I feel that it is more cautious to > >> shut down artificially. > >> Whether it is possible to explicitly assign a PR to a committer familiar > >> with the module, which will reduce the unnecessary ping operation of > many > >> contributors. > >> Because some people don't know which committer is familiar with the > module > >> he changed. > >> > >> Thanks, vino. > >> > >> Aljoscha Krettek <[hidden email]> 于2018年9月24日周一 下午5:03写道: > >> > >> > In Beam, we have a bot that regularly nags people about inactive PRs > and > >> > also closes them after long inactivity. > >> > > >> > And we use the github feature for assigning reviewers in github. > >> > > >> > Sometimes it is hard for people to judge how "valuable" a PR is. Maybe > >> > some knowledgable people could mark PRs as valuable if they think > it's a > >> > good addition but if they don't have the review bandwith. Other people > >> can > >> > then search for valuable PRs that don't yet a reviewer and > review/merge > >> > them. > >> > > >> > Aljoscha > >> > > >> > > On 22. Sep 2018, at 04:25, vino yang <[hidden email]> wrote: > >> > > > >> > > Hi Jin Sun, > >> > > > >> > > Earlier this year, I also had these questions when I started > >> contributing > >> > > code to Flink. In fact, the timing of a PR being reviewed will be > >> related > >> > > to the priority of the problem solved by the PR. > >> > > And when you indicate the module to which it belongs in the title of > >> the > >> > > PR, like "[FLINK-xxxx][module] XXXX", the person in charge of the > >> > relevant > >> > > module or the contributor who is familiar with it will find it > easier. > >> > > > >> > > To Stephan: > >> > > > >> > > Maybe we can open a separate mail thread (after all, the current > >> > discussion > >> > > thread is about a specific topic) to hear the contributors about PR > >> > review > >> > > related questions and doubts. Perhaps some of their feedback will > help > >> > the > >> > > community improve the way they review. > >> > > > >> > > Thanks, vino. > >> > > > >> > > Jin Sun <[hidden email]> 于2018年9月22日周六 上午6:40写道: > >> > > > >> > >> As a new contributor I cared about how to make my contribution > >> accepted > >> > by > >> > >> the community, some questions: > >> > >> 1) When will it get reviewed? Is there a rule about review > timeline? > >> > >> 2) There are long backlog of pull requests, What happened if a pull > >> > >> request not get noticed, do we have some mechanism to make it > moving > >> > >> forward, like a pull request will be assigned a owner of reviewer? > >> Or we > >> > >> have a review queue and a pull request will be get handled fairly. > >> > >> > >> > >> Jin > >> > >> > >> > >> > >> > >>> On Sep 20, 2018, at 12:56 PM, Stephan Ewen <[hidden email]> > >> wrote: > >> > >>> > >> > >>> Hi all! > >> > >>> > >> > >>> This thread is dedicated to discuss the tooling we want to use for > >> the > >> > >>> reviews. > >> > >>> It is spun out of the proposal *"A more structured approach to > >> reviews > >> > >> and > >> > >>> contributions".* > >> > >>> > >> > >>> > >> > >>> *Suggestions brought up so far* > >> > >>> > >> > >>> > >> > >>> *Use comments / template with checklist* > >> > >>> > >> > >>> - Easy to do > >> > >>> - Manual, a bit of reviewer overhead, reviewers needs to know the > >> > >> process > >> > >>> > >> > >>> *Use a bot * > >> > >>> > >> > >>> - Automatically add the review questions to each new PR > >> > >>> - Further details? > >> > >>> > >> > >>> *Use GitHub labels* > >> > >>> > >> > >>> - Searchable > >> > >>> - possibly not obvious to new contributors > >> > >>> - Any restrictions? Do members need to apply at ASF infra to have > >> > >>> permissions to edit github labels? > >> > >> > >> > >> > >> > > >> > > >> > > > |
Hi Fabian,
+1 for your proposal. For the downside, I think after adding the review process template, the pull request template would be high level into 3 parts: 1. Greeting and community guiding. 2. User completed template. 3. Reviewer complete template. If we can visually separate them, i.e., help a new contributor regard the whole template into 3 parts, I think this downside is not so critical. For some previous attempt, see also [1]. Best, tison. [1] https://github.com/apache/flink/pull/6722 vino yang <[hidden email]> 于2018年10月17日周三 上午9:57写道: > +1, > > Agree to use the PR template. > > Fabian Hueske <[hidden email]> 于2018年10月17日周三 上午12:48写道: > > > Hi everyone, > > > > Instead of manually adding the review progress template as a comment to > > every new PR, we could also append it to the PR description template. > > The benefits would be: > > + no need to add it manually since it is automatically added to each PR > > + the template is versioned in the Flink Git repository > > + contributors can learn about the review process before opening a PR > > > > On the downside, the template grows a bit at the end. > > > > What do you think? > > > > Best, Fabian > > > > Am Mo., 24. Sep. 2018 um 15:51 Uhr schrieb Fabian Hueske < > > [hidden email] > > >: > > > > > Hi, > > > > > > Coming back to the original topic of the thread: How to implement the > > > guided review process. > > > > > > I am in favor of starting with a low-tech solution. > > > We design a review template with a checkbox for the five questions (see > > > [1]) and a link to the detailed description of the review process ([1] > > will > > > be added to flink.apache.org). > > > Once a PR is opened, anybody (the PR author, a committer, any reviewer, > > > ...) can post the review template as a comment. Ideally this happens > > > shortly after the PR was opened. > > > If we find it necessary, we can later add a bot to automate posting the > > > template as comment. > > > > > > Once the template is posted, the PR can be reviewed by following the > > > process and answering the template questions. > > > When all boxes are ticked off, the PR can be merged. > > > > > > Best, > > > Fabian > > > > > > > > > > > > > > > > > > [1] > > > > > > https://docs.google.com/document/d/1yaX2b9LNh-6LxrAmE23U3D2cRbocGlGKCYnvJd9lVhk/ > > > > > > > > > Am Mo., 24. Sep. 2018 um 12:27 Uhr schrieb vino yang < > > > [hidden email]>: > > > > > >> Hi, > > >> > > >> About "valuable", I agree with @Aljoscha that there is no clear > standard > > >> of > > >> judgment about "valuable". > > >> But I think the priority may be a more specific indicator, because the > > >> JIRA > > >> issue also has a "Priority" attribute. > > >> Maybe we can tag the PR, for example: use the "Label" function of > > github, > > >> or add the "[Priority]" tag to the PR title? > > >> > > >> Regarding the closure of inactive PR, I feel that it is more cautious > to > > >> shut down artificially. > > >> Whether it is possible to explicitly assign a PR to a committer > familiar > > >> with the module, which will reduce the unnecessary ping operation of > > many > > >> contributors. > > >> Because some people don't know which committer is familiar with the > > module > > >> he changed. > > >> > > >> Thanks, vino. > > >> > > >> Aljoscha Krettek <[hidden email]> 于2018年9月24日周一 下午5:03写道: > > >> > > >> > In Beam, we have a bot that regularly nags people about inactive PRs > > and > > >> > also closes them after long inactivity. > > >> > > > >> > And we use the github feature for assigning reviewers in github. > > >> > > > >> > Sometimes it is hard for people to judge how "valuable" a PR is. > Maybe > > >> > some knowledgable people could mark PRs as valuable if they think > > it's a > > >> > good addition but if they don't have the review bandwith. Other > people > > >> can > > >> > then search for valuable PRs that don't yet a reviewer and > > review/merge > > >> > them. > > >> > > > >> > Aljoscha > > >> > > > >> > > On 22. Sep 2018, at 04:25, vino yang <[hidden email]> > wrote: > > >> > > > > >> > > Hi Jin Sun, > > >> > > > > >> > > Earlier this year, I also had these questions when I started > > >> contributing > > >> > > code to Flink. In fact, the timing of a PR being reviewed will be > > >> related > > >> > > to the priority of the problem solved by the PR. > > >> > > And when you indicate the module to which it belongs in the title > of > > >> the > > >> > > PR, like "[FLINK-xxxx][module] XXXX", the person in charge of the > > >> > relevant > > >> > > module or the contributor who is familiar with it will find it > > easier. > > >> > > > > >> > > To Stephan: > > >> > > > > >> > > Maybe we can open a separate mail thread (after all, the current > > >> > discussion > > >> > > thread is about a specific topic) to hear the contributors about > PR > > >> > review > > >> > > related questions and doubts. Perhaps some of their feedback will > > help > > >> > the > > >> > > community improve the way they review. > > >> > > > > >> > > Thanks, vino. > > >> > > > > >> > > Jin Sun <[hidden email]> 于2018年9月22日周六 上午6:40写道: > > >> > > > > >> > >> As a new contributor I cared about how to make my contribution > > >> accepted > > >> > by > > >> > >> the community, some questions: > > >> > >> 1) When will it get reviewed? Is there a rule about review > > timeline? > > >> > >> 2) There are long backlog of pull requests, What happened if a > pull > > >> > >> request not get noticed, do we have some mechanism to make it > > moving > > >> > >> forward, like a pull request will be assigned a owner of > reviewer? > > >> Or we > > >> > >> have a review queue and a pull request will be get handled > fairly. > > >> > >> > > >> > >> Jin > > >> > >> > > >> > >> > > >> > >>> On Sep 20, 2018, at 12:56 PM, Stephan Ewen <[hidden email]> > > >> wrote: > > >> > >>> > > >> > >>> Hi all! > > >> > >>> > > >> > >>> This thread is dedicated to discuss the tooling we want to use > for > > >> the > > >> > >>> reviews. > > >> > >>> It is spun out of the proposal *"A more structured approach to > > >> reviews > > >> > >> and > > >> > >>> contributions".* > > >> > >>> > > >> > >>> > > >> > >>> *Suggestions brought up so far* > > >> > >>> > > >> > >>> > > >> > >>> *Use comments / template with checklist* > > >> > >>> > > >> > >>> - Easy to do > > >> > >>> - Manual, a bit of reviewer overhead, reviewers needs to know > the > > >> > >> process > > >> > >>> > > >> > >>> *Use a bot * > > >> > >>> > > >> > >>> - Automatically add the review questions to each new PR > > >> > >>> - Further details? > > >> > >>> > > >> > >>> *Use GitHub labels* > > >> > >>> > > >> > >>> - Searchable > > >> > >>> - possibly not obvious to new contributors > > >> > >>> - Any restrictions? Do members need to apply at ASF infra to > have > > >> > >>> permissions to edit github labels? > > >> > >> > > >> > >> > > >> > > > >> > > > >> > > > > > > |
+1
On Tue, Oct 16, 2018 at 7:51 PM Tzu-Li Chen <[hidden email]> wrote: > Hi Fabian, > > +1 for your proposal. > > For the downside, I think after adding the review process template, > the pull request template would be high level into 3 parts: > > 1. Greeting and community guiding. > 2. User completed template. > 3. Reviewer complete template. > > If we can visually separate them, i.e., help a new contributor regard the > whole template into 3 parts, I think this downside is not so critical. For > some previous attempt, see also [1]. > > Best, > tison. > > [1] https://github.com/apache/flink/pull/6722 > > > vino yang <[hidden email]> 于2018年10月17日周三 上午9:57写道: > > > +1, > > > > Agree to use the PR template. > > > > Fabian Hueske <[hidden email]> 于2018年10月17日周三 上午12:48写道: > > > > > Hi everyone, > > > > > > Instead of manually adding the review progress template as a comment to > > > every new PR, we could also append it to the PR description template. > > > The benefits would be: > > > + no need to add it manually since it is automatically added to each PR > > > + the template is versioned in the Flink Git repository > > > + contributors can learn about the review process before opening a PR > > > > > > On the downside, the template grows a bit at the end. > > > > > > What do you think? > > > > > > Best, Fabian > > > > > > Am Mo., 24. Sep. 2018 um 15:51 Uhr schrieb Fabian Hueske < > > > [hidden email] > > > >: > > > > > > > Hi, > > > > > > > > Coming back to the original topic of the thread: How to implement the > > > > guided review process. > > > > > > > > I am in favor of starting with a low-tech solution. > > > > We design a review template with a checkbox for the five questions > (see > > > > [1]) and a link to the detailed description of the review process > ([1] > > > will > > > > be added to flink.apache.org). > > > > Once a PR is opened, anybody (the PR author, a committer, any > reviewer, > > > > ...) can post the review template as a comment. Ideally this happens > > > > shortly after the PR was opened. > > > > If we find it necessary, we can later add a bot to automate posting > the > > > > template as comment. > > > > > > > > Once the template is posted, the PR can be reviewed by following the > > > > process and answering the template questions. > > > > When all boxes are ticked off, the PR can be merged. > > > > > > > > Best, > > > > Fabian > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://docs.google.com/document/d/1yaX2b9LNh-6LxrAmE23U3D2cRbocGlGKCYnvJd9lVhk/ > > > > > > > > > > > > Am Mo., 24. Sep. 2018 um 12:27 Uhr schrieb vino yang < > > > > [hidden email]>: > > > > > > > >> Hi, > > > >> > > > >> About "valuable", I agree with @Aljoscha that there is no clear > > standard > > > >> of > > > >> judgment about "valuable". > > > >> But I think the priority may be a more specific indicator, because > the > > > >> JIRA > > > >> issue also has a "Priority" attribute. > > > >> Maybe we can tag the PR, for example: use the "Label" function of > > > github, > > > >> or add the "[Priority]" tag to the PR title? > > > >> > > > >> Regarding the closure of inactive PR, I feel that it is more > cautious > > to > > > >> shut down artificially. > > > >> Whether it is possible to explicitly assign a PR to a committer > > familiar > > > >> with the module, which will reduce the unnecessary ping operation of > > > many > > > >> contributors. > > > >> Because some people don't know which committer is familiar with the > > > module > > > >> he changed. > > > >> > > > >> Thanks, vino. > > > >> > > > >> Aljoscha Krettek <[hidden email]> 于2018年9月24日周一 下午5:03写道: > > > >> > > > >> > In Beam, we have a bot that regularly nags people about inactive > PRs > > > and > > > >> > also closes them after long inactivity. > > > >> > > > > >> > And we use the github feature for assigning reviewers in github. > > > >> > > > > >> > Sometimes it is hard for people to judge how "valuable" a PR is. > > Maybe > > > >> > some knowledgable people could mark PRs as valuable if they think > > > it's a > > > >> > good addition but if they don't have the review bandwith. Other > > people > > > >> can > > > >> > then search for valuable PRs that don't yet a reviewer and > > > review/merge > > > >> > them. > > > >> > > > > >> > Aljoscha > > > >> > > > > >> > > On 22. Sep 2018, at 04:25, vino yang <[hidden email]> > > wrote: > > > >> > > > > > >> > > Hi Jin Sun, > > > >> > > > > > >> > > Earlier this year, I also had these questions when I started > > > >> contributing > > > >> > > code to Flink. In fact, the timing of a PR being reviewed will > be > > > >> related > > > >> > > to the priority of the problem solved by the PR. > > > >> > > And when you indicate the module to which it belongs in the > title > > of > > > >> the > > > >> > > PR, like "[FLINK-xxxx][module] XXXX", the person in charge of > the > > > >> > relevant > > > >> > > module or the contributor who is familiar with it will find it > > > easier. > > > >> > > > > > >> > > To Stephan: > > > >> > > > > > >> > > Maybe we can open a separate mail thread (after all, the current > > > >> > discussion > > > >> > > thread is about a specific topic) to hear the contributors about > > PR > > > >> > review > > > >> > > related questions and doubts. Perhaps some of their feedback > will > > > help > > > >> > the > > > >> > > community improve the way they review. > > > >> > > > > > >> > > Thanks, vino. > > > >> > > > > > >> > > Jin Sun <[hidden email]> 于2018年9月22日周六 上午6:40写道: > > > >> > > > > > >> > >> As a new contributor I cared about how to make my contribution > > > >> accepted > > > >> > by > > > >> > >> the community, some questions: > > > >> > >> 1) When will it get reviewed? Is there a rule about review > > > timeline? > > > >> > >> 2) There are long backlog of pull requests, What happened if a > > pull > > > >> > >> request not get noticed, do we have some mechanism to make it > > > moving > > > >> > >> forward, like a pull request will be assigned a owner of > > reviewer? > > > >> Or we > > > >> > >> have a review queue and a pull request will be get handled > > fairly. > > > >> > >> > > > >> > >> Jin > > > >> > >> > > > >> > >> > > > >> > >>> On Sep 20, 2018, at 12:56 PM, Stephan Ewen <[hidden email]> > > > >> wrote: > > > >> > >>> > > > >> > >>> Hi all! > > > >> > >>> > > > >> > >>> This thread is dedicated to discuss the tooling we want to use > > for > > > >> the > > > >> > >>> reviews. > > > >> > >>> It is spun out of the proposal *"A more structured approach to > > > >> reviews > > > >> > >> and > > > >> > >>> contributions".* > > > >> > >>> > > > >> > >>> > > > >> > >>> *Suggestions brought up so far* > > > >> > >>> > > > >> > >>> > > > >> > >>> *Use comments / template with checklist* > > > >> > >>> > > > >> > >>> - Easy to do > > > >> > >>> - Manual, a bit of reviewer overhead, reviewers needs to know > > the > > > >> > >> process > > > >> > >>> > > > >> > >>> *Use a bot * > > > >> > >>> > > > >> > >>> - Automatically add the review questions to each new PR > > > >> > >>> - Further details? > > > >> > >>> > > > >> > >>> *Use GitHub labels* > > > >> > >>> > > > >> > >>> - Searchable > > > >> > >>> - possibly not obvious to new contributors > > > >> > >>> - Any restrictions? Do members need to apply at ASF infra to > > have > > > >> > >>> permissions to edit github labels? > > > >> > >> > > > >> > >> > > > >> > > > > >> > > > > >> > > > > > > > > > > -- Thanks, Jin SUN |
Hi,
I'm slightly prefer the bot option. The bot can post the review template automatically. But I do agree that we can start with a low-tech solution and add a bot later if find it helpful. Best, Hequn On Wed, Oct 17, 2018 at 11:17 AM Jin Sun <[hidden email]> wrote: > +1 > > On Tue, Oct 16, 2018 at 7:51 PM Tzu-Li Chen <[hidden email]> wrote: > > > Hi Fabian, > > > > +1 for your proposal. > > > > For the downside, I think after adding the review process template, > > the pull request template would be high level into 3 parts: > > > > 1. Greeting and community guiding. > > 2. User completed template. > > 3. Reviewer complete template. > > > > If we can visually separate them, i.e., help a new contributor regard the > > whole template into 3 parts, I think this downside is not so critical. > For > > some previous attempt, see also [1]. > > > > Best, > > tison. > > > > [1] https://github.com/apache/flink/pull/6722 > > > > > > vino yang <[hidden email]> 于2018年10月17日周三 上午9:57写道: > > > > > +1, > > > > > > Agree to use the PR template. > > > > > > Fabian Hueske <[hidden email]> 于2018年10月17日周三 上午12:48写道: > > > > > > > Hi everyone, > > > > > > > > Instead of manually adding the review progress template as a comment > to > > > > every new PR, we could also append it to the PR description template. > > > > The benefits would be: > > > > + no need to add it manually since it is automatically added to each > PR > > > > + the template is versioned in the Flink Git repository > > > > + contributors can learn about the review process before opening a PR > > > > > > > > On the downside, the template grows a bit at the end. > > > > > > > > What do you think? > > > > > > > > Best, Fabian > > > > > > > > Am Mo., 24. Sep. 2018 um 15:51 Uhr schrieb Fabian Hueske < > > > > [hidden email] > > > > >: > > > > > > > > > Hi, > > > > > > > > > > Coming back to the original topic of the thread: How to implement > the > > > > > guided review process. > > > > > > > > > > I am in favor of starting with a low-tech solution. > > > > > We design a review template with a checkbox for the five questions > > (see > > > > > [1]) and a link to the detailed description of the review process > > ([1] > > > > will > > > > > be added to flink.apache.org). > > > > > Once a PR is opened, anybody (the PR author, a committer, any > > reviewer, > > > > > ...) can post the review template as a comment. Ideally this > happens > > > > > shortly after the PR was opened. > > > > > If we find it necessary, we can later add a bot to automate posting > > the > > > > > template as comment. > > > > > > > > > > Once the template is posted, the PR can be reviewed by following > the > > > > > process and answering the template questions. > > > > > When all boxes are ticked off, the PR can be merged. > > > > > > > > > > Best, > > > > > Fabian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > https://docs.google.com/document/d/1yaX2b9LNh-6LxrAmE23U3D2cRbocGlGKCYnvJd9lVhk/ > > > > > > > > > > > > > > > Am Mo., 24. Sep. 2018 um 12:27 Uhr schrieb vino yang < > > > > > [hidden email]>: > > > > > > > > > >> Hi, > > > > >> > > > > >> About "valuable", I agree with @Aljoscha that there is no clear > > > standard > > > > >> of > > > > >> judgment about "valuable". > > > > >> But I think the priority may be a more specific indicator, because > > the > > > > >> JIRA > > > > >> issue also has a "Priority" attribute. > > > > >> Maybe we can tag the PR, for example: use the "Label" function of > > > > github, > > > > >> or add the "[Priority]" tag to the PR title? > > > > >> > > > > >> Regarding the closure of inactive PR, I feel that it is more > > cautious > > > to > > > > >> shut down artificially. > > > > >> Whether it is possible to explicitly assign a PR to a committer > > > familiar > > > > >> with the module, which will reduce the unnecessary ping operation > of > > > > many > > > > >> contributors. > > > > >> Because some people don't know which committer is familiar with > the > > > > module > > > > >> he changed. > > > > >> > > > > >> Thanks, vino. > > > > >> > > > > >> Aljoscha Krettek <[hidden email]> 于2018年9月24日周一 下午5:03写道: > > > > >> > > > > >> > In Beam, we have a bot that regularly nags people about inactive > > PRs > > > > and > > > > >> > also closes them after long inactivity. > > > > >> > > > > > >> > And we use the github feature for assigning reviewers in github. > > > > >> > > > > > >> > Sometimes it is hard for people to judge how "valuable" a PR is. > > > Maybe > > > > >> > some knowledgable people could mark PRs as valuable if they > think > > > > it's a > > > > >> > good addition but if they don't have the review bandwith. Other > > > people > > > > >> can > > > > >> > then search for valuable PRs that don't yet a reviewer and > > > > review/merge > > > > >> > them. > > > > >> > > > > > >> > Aljoscha > > > > >> > > > > > >> > > On 22. Sep 2018, at 04:25, vino yang <[hidden email]> > > > wrote: > > > > >> > > > > > > >> > > Hi Jin Sun, > > > > >> > > > > > > >> > > Earlier this year, I also had these questions when I started > > > > >> contributing > > > > >> > > code to Flink. In fact, the timing of a PR being reviewed will > > be > > > > >> related > > > > >> > > to the priority of the problem solved by the PR. > > > > >> > > And when you indicate the module to which it belongs in the > > title > > > of > > > > >> the > > > > >> > > PR, like "[FLINK-xxxx][module] XXXX", the person in charge of > > the > > > > >> > relevant > > > > >> > > module or the contributor who is familiar with it will find it > > > > easier. > > > > >> > > > > > > >> > > To Stephan: > > > > >> > > > > > > >> > > Maybe we can open a separate mail thread (after all, the > current > > > > >> > discussion > > > > >> > > thread is about a specific topic) to hear the contributors > about > > > PR > > > > >> > review > > > > >> > > related questions and doubts. Perhaps some of their feedback > > will > > > > help > > > > >> > the > > > > >> > > community improve the way they review. > > > > >> > > > > > > >> > > Thanks, vino. > > > > >> > > > > > > >> > > Jin Sun <[hidden email]> 于2018年9月22日周六 上午6:40写道: > > > > >> > > > > > > >> > >> As a new contributor I cared about how to make my > contribution > > > > >> accepted > > > > >> > by > > > > >> > >> the community, some questions: > > > > >> > >> 1) When will it get reviewed? Is there a rule about review > > > > timeline? > > > > >> > >> 2) There are long backlog of pull requests, What happened if > a > > > pull > > > > >> > >> request not get noticed, do we have some mechanism to make it > > > > moving > > > > >> > >> forward, like a pull request will be assigned a owner of > > > reviewer? > > > > >> Or we > > > > >> > >> have a review queue and a pull request will be get handled > > > fairly. > > > > >> > >> > > > > >> > >> Jin > > > > >> > >> > > > > >> > >> > > > > >> > >>> On Sep 20, 2018, at 12:56 PM, Stephan Ewen < > [hidden email]> > > > > >> wrote: > > > > >> > >>> > > > > >> > >>> Hi all! > > > > >> > >>> > > > > >> > >>> This thread is dedicated to discuss the tooling we want to > use > > > for > > > > >> the > > > > >> > >>> reviews. > > > > >> > >>> It is spun out of the proposal *"A more structured approach > to > > > > >> reviews > > > > >> > >> and > > > > >> > >>> contributions".* > > > > >> > >>> > > > > >> > >>> > > > > >> > >>> *Suggestions brought up so far* > > > > >> > >>> > > > > >> > >>> > > > > >> > >>> *Use comments / template with checklist* > > > > >> > >>> > > > > >> > >>> - Easy to do > > > > >> > >>> - Manual, a bit of reviewer overhead, reviewers needs to > know > > > the > > > > >> > >> process > > > > >> > >>> > > > > >> > >>> *Use a bot * > > > > >> > >>> > > > > >> > >>> - Automatically add the review questions to each new PR > > > > >> > >>> - Further details? > > > > >> > >>> > > > > >> > >>> *Use GitHub labels* > > > > >> > >>> > > > > >> > >>> - Searchable > > > > >> > >>> - possibly not obvious to new contributors > > > > >> > >>> - Any restrictions? Do members need to apply at ASF infra to > > > have > > > > >> > >>> permissions to edit github labels? > > > > >> > >> > > > > >> > >> > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > -- > Thanks, > Jin SUN > |
In reply to this post by Stephan Ewen
I like @Fabian Hueske <[hidden email]> 's proposal, currently design the
template is pretty good idea. Because the template is convenient for contributors to follow the norms to community contributions. About templates, I think we also need an JIRA description template, In particular, in the case of current JIRA break previous users’ programs and setups, the contributions must describe them in detail in JIRA description. And we should make a discussion, get at least one Committed consensus in the JIRA discussion before dive into code. Best, Jincheng Stephan Ewen <[hidden email]> 于2018年9月21日周五 上午3:56写道: > Hi all! > > This thread is dedicated to discuss the tooling we want to use for the > reviews. > It is spun out of the proposal *"A more structured approach to reviews and > contributions".* > > > *Suggestions brought up so far* > > > *Use comments / template with checklist* > > - Easy to do > - Manual, a bit of reviewer overhead, reviewers needs to know the process > > *Use a bot * > > - Automatically add the review questions to each new PR > - Further details? > > *Use GitHub labels* > > - Searchable > - possibly not obvious to new contributors > - Any restrictions? Do members need to apply at ASF infra to have > permissions to edit github labels? > |
Hi,
I opened a PR to extend the PR description template [1]. @jincheng sun <[hidden email]>, I'd suggest to start a separate discussion about a template for Jira ticket. Let's try to keep this thread focused on the tooling to support the review process. Thanks, Fabian [1] https://github.com/apache/flink/pull/6873 Am Do., 18. Okt. 2018 um 07:34 Uhr schrieb jincheng sun < [hidden email]>: > I like @Fabian Hueske <[hidden email]> 's proposal, currently design > the > template is pretty good idea. Because the template is convenient for > contributors to follow the norms to community contributions. About > templates, I think we also need an JIRA description template, > In particular, in the case of current JIRA break previous users’ programs > and setups, the contributions must describe them in detail in JIRA > description. And we should make a discussion, get at least one Committed > consensus in the JIRA discussion before dive into code. > > Best, > Jincheng > > Stephan Ewen <[hidden email]> 于2018年9月21日周五 上午3:56写道: > > > Hi all! > > > > This thread is dedicated to discuss the tooling we want to use for the > > reviews. > > It is spun out of the proposal *"A more structured approach to reviews > and > > contributions".* > > > > > > *Suggestions brought up so far* > > > > > > *Use comments / template with checklist* > > > > - Easy to do > > - Manual, a bit of reviewer overhead, reviewers needs to know the > process > > > > *Use a bot * > > > > - Automatically add the review questions to each new PR > > - Further details? > > > > *Use GitHub labels* > > > > - Searchable > > - possibly not obvious to new contributors > > - Any restrictions? Do members need to apply at ASF infra to have > > permissions to edit github labels? > > > |
Sounds good! @Fabian Hueske <[hidden email]>
Fabian Hueske <[hidden email]> 于2018年10月18日周四 下午4:24写道: > Hi, > > I opened a PR to extend the PR description template [1]. > > @jincheng sun <[hidden email]>, I'd suggest to start a separate > discussion about a template for Jira ticket. Let's try to keep this thread > focused on the tooling to support the review process. > > Thanks, Fabian > > [1] https://github.com/apache/flink/pull/6873 > > Am Do., 18. Okt. 2018 um 07:34 Uhr schrieb jincheng sun < > [hidden email]>: > >> I like @Fabian Hueske <[hidden email]> 's proposal, currently design >> the >> template is pretty good idea. Because the template is convenient for >> contributors to follow the norms to community contributions. About >> templates, I think we also need an JIRA description template, >> In particular, in the case of current JIRA break previous users’ programs >> and setups, the contributions must describe them in detail in JIRA >> description. And we should make a discussion, get at least one Committed >> consensus in the JIRA discussion before dive into code. >> >> Best, >> Jincheng >> >> Stephan Ewen <[hidden email]> 于2018年9月21日周五 上午3:56写道: >> >> > Hi all! >> > >> > This thread is dedicated to discuss the tooling we want to use for the >> > reviews. >> > It is spun out of the proposal *"A more structured approach to reviews >> and >> > contributions".* >> > >> > >> > *Suggestions brought up so far* >> > >> > >> > *Use comments / template with checklist* >> > >> > - Easy to do >> > - Manual, a bit of reviewer overhead, reviewers needs to know the >> process >> > >> > *Use a bot * >> > >> > - Automatically add the review questions to each new PR >> > - Further details? >> > >> > *Use GitHub labels* >> > >> > - Searchable >> > - possibly not obvious to new contributors >> > - Any restrictions? Do members need to apply at ASF infra to have >> > permissions to edit github labels? >> > >> > |
Free forum by Nabble | Edit this page |