Hello all, Brin Zhang has been actively contributing to Cyborg in various areas, adding new features, improving quality, reviewing patches, and generally helping others in the community. Despite the relatively short time, he has been one of the most prolific contributors, and brings an enthusiastic and active mindset. I would like to thank him and acknowledge his significant contributions by proposing him as a core reviewer for Cyborg. Shogo Saito has been active in Cyborg since Train release. He has been driving the Cyborg client improvements, including its revamp to use OpenStackSDK. Previously he was instrumental in the transition to Python 3, testing and fixing issues in the process. As he has access to real FPGA hardware, he brings a users’ perspective and also tests Cyborg with real hardware. I would like to thank and acknowledge him for his steady valuable contributions, and propose him as a core reviewer for Cyborg. Some of the currently listed core reviewers have not been participating for a lengthy period of time. It is proposed that those who have had no contributions for the past 18 months – i.e. no participation in meetings, no code contributions and no reviews – be removed from the list of core reviewers. If no objections are made known by March 20, I will make the changes proposed above. Thanks. Regards, Sundar
Big +1 for Brin and shogo's nomination and well deserved :) I'm a little bit concerned over the 18 months period. The original rule we setup is volunteer step down, since this is a small team we want to acknowledge everyone that has made significant contributions. Some of the inactive core reviewers like Justin Kilpatrick have moved on a long time ago, and I don't see people like him could do any harm to the project. But if the core reviewer has a size limit in the system, that would be reasonable to replace the inactive ones with the new recruits :) Just my two cents On Wed, Mar 11, 2020 at 10:19 PM Nadathur, Sundar <sundar.nadathur@intel.com> wrote:
Hello all, Brin Zhang has been actively contributing to Cyborg in various areas, adding new features, improving quality, reviewing patches, and generally helping others in the community. Despite the relatively short time, he has been one of the most prolific contributors, and brings an enthusiastic and active mindset. I would like to thank him and acknowledge his significant contributions by proposing him as a core reviewer for Cyborg.
Shogo Saito has been active in Cyborg since Train release. He has been driving the Cyborg client improvements, including its revamp to use OpenStackSDK. Previously he was instrumental in the transition to Python 3, testing and fixing issues in the process. As he has access to real FPGA hardware, he brings a users’ perspective and also tests Cyborg with real hardware. I would like to thank and acknowledge him for his steady valuable contributions, and propose him as a core reviewer for Cyborg.
Some of the currently listed core reviewers have not been participating for a lengthy period of time. It is proposed that those who have had no contributions for the past 18 months – i.e. no participation in meetings, no code contributions and no reviews – be removed from the list of core reviewers.
If no objections are made known by March 20, I will make the changes proposed above.
Thanks.
Regards, Sundar
-- Zhipeng (Howard) Huang Principle Engineer OpenStack, Kubernetes, CNCF, LF Edge, ONNX, Kubeflow, OpenSDS, Open Service Broker API, OCP, Hyperledger, ETSI, SNIA, DMTF, W3C
Big +1 for Brin and shogo's nomination and well deserved :)
I'm a little bit concerned over the 18 months period. The original rule we setup is volunteer step down, since this is a small team we want to acknowledge everyone that has made significant contributions. Some of the inactive core reviewers like Justin Kilpatrick have moved on a long time ago, and I don't see people like him could do any harm to the project.
But if the core reviewer has a size limit in the system, that would be reasonable to replace the inactive ones with the new recruits :) it is generally considerd best pratice to maintian the core team adding or removing
On Thu, 2020-03-12 at 00:17 +0800, Zhipeng Huang wrote: people based on there activity. if a core is removed due to in activity and they come back they can always be restored but it give a bad perception if a project has like 20 core but only 2 are active. as a new contibutor you dont know which ones are active and it can be frustrating to reach out to them and get no responce. also just form a project healt point of view it make the project look like its more diverse or more active then it actully is which is also not generally a good thing. that said core can step down if they feel like they can contribute time anymore when ever they like so and if a core is steping a way for a few months but intends to come back they can also say that in advance and there is no harm in leaving them for a cycle or two but in general after a period of in activity (usally more then a full release/6months) i think its good to reduce back down the core team.
Just my two cents
On Wed, Mar 11, 2020 at 10:19 PM Nadathur, Sundar <sundar.nadathur@intel.com> wrote:
Hello all, Brin Zhang has been actively contributing to Cyborg in various areas, adding new features, improving quality, reviewing patches, and generally helping others in the community. Despite the relatively short time, he has been one of the most prolific contributors, and brings an enthusiastic and active mindset. I would like to thank him and acknowledge his significant contributions by proposing him as a core reviewer for Cyborg.
Shogo Saito has been active in Cyborg since Train release. He has been driving the Cyborg client improvements, including its revamp to use OpenStackSDK. Previously he was instrumental in the transition to Python 3, testing and fixing issues in the process. As he has access to real FPGA hardware, he brings a users’ perspective and also tests Cyborg with real hardware. I would like to thank and acknowledge him for his steady valuable contributions, and propose him as a core reviewer for Cyborg.
Some of the currently listed core reviewers have not been participating for a lengthy period of time. It is proposed that those who have had no contributions for the past 18 months – i.e. no participation in meetings, no code contributions and no reviews – be removed from the list of core reviewers.
If no objections are made known by March 20, I will make the changes proposed above.
Thanks.
Regards, Sundar
Hi Sean, This is a good point on making clarity on the contributor side, wasn't thinking about that. Re "be restored" my thoughts were that if anyone comes back, and not as core member, they should follow the process and be nominated/elected again. If a previous inactive core being deleted and then come back just restored, it is also problematic :) That is also why I suggested not to presumptively remove inactive cores. On Thu, Mar 12, 2020 at 12:37 AM Sean Mooney <smooney@redhat.com> wrote:
Big +1 for Brin and shogo's nomination and well deserved :)
I'm a little bit concerned over the 18 months period. The original rule we setup is volunteer step down, since this is a small team we want to acknowledge everyone that has made significant contributions. Some of the inactive core reviewers like Justin Kilpatrick have moved on a long time ago, and I don't see people like him could do any harm to the project.
But if the core reviewer has a size limit in the system, that would be reasonable to replace the inactive ones with the new recruits :) it is generally considerd best pratice to maintian the core team adding or removing
On Thu, 2020-03-12 at 00:17 +0800, Zhipeng Huang wrote: people based on there activity. if a core is removed due to in activity and they come back they can always be restored but it give a bad perception if a project has like 20 core but only 2 are active. as a new contibutor you dont know which ones are active and it can be frustrating to reach out to them and get no responce. also just form a project healt point of view it make the project look like its more diverse or more active then it actully is which is also not generally a good thing.
that said core can step down if they feel like they can contribute time anymore when ever they like so and if a core is steping a way for a few months but intends to come back they can also say that in advance and there is no harm in leaving them for a cycle or two but in general after a period of in activity (usally more then a full release/6months) i think its good to reduce back down the core team.
Just my two cents
On Wed, Mar 11, 2020 at 10:19 PM Nadathur, Sundar <
sundar.nadathur@intel.com>
wrote:
Hello all, Brin Zhang has been actively contributing to Cyborg in various areas, adding new features, improving quality, reviewing patches, and generally helping others in the community. Despite the relatively short time, he has been one of the most prolific contributors, and brings an enthusiastic and active mindset. I would like to thank him and acknowledge his significant contributions by proposing him as a core reviewer for Cyborg.
Shogo Saito has been active in Cyborg since Train release. He has been driving the Cyborg client improvements, including its revamp to use OpenStackSDK. Previously he was instrumental in the transition to Python 3, testing and fixing issues in the process. As he has access to real FPGA hardware, he brings a users’ perspective and also tests Cyborg with real hardware. I would like to thank and acknowledge him for his steady valuable contributions, and propose him as a core reviewer for Cyborg.
Some of the currently listed core reviewers have not been participating for a lengthy period of time. It is proposed that those who have had no contributions for the past 18 months – i.e. no participation in meetings, no code contributions and no reviews – be removed from the list of core reviewers.
If no objections are made known by March 20, I will make the changes proposed above.
Thanks.
Regards, Sundar
-- Zhipeng (Howard) Huang Principle Engineer OpenStack, Kubernetes, CNCF, LF Edge, ONNX, Kubeflow, OpenSDS, Open Service Broker API, OCP, Hyperledger, ETSI, SNIA, DMTF, W3C
From: Sean Mooney <smooney@redhat.com> Sent: Wednesday, March 11, 2020 9:37 AM
Big +1 for Brin and shogo's nomination and well deserved :)
I'm a little bit concerned over the 18 months period. The original rule we setup is volunteer step down, since this is a small team we want to acknowledge everyone that has made significant contributions. Some of the inactive core reviewers like Justin Kilpatrick have moved on a long time ago, and I don't see people like him could do any harm to
On Thu, 2020-03-12 at 00:17 +0800, Zhipeng Huang wrote: the project.
But if the core reviewer has a size limit in the system, that would be reasonable to replace the inactive ones with the new recruits :)
it is generally considerd best pratice to maintian the core team adding or removing people based on there activity. if a core is removed due to in activity and they come back they can always be restored but it give a bad perception if a project has like 20 core but only 2 are active. as a new contibutor you dont know which ones are active and it can be frustrating to reach out to them and get no responce. also just form a project healt point of view it make the project look like its more diverse or more active then it actully is which is also not generally a good thing.
that said core can step down if they feel like they can contribute time anymore when ever they like so and if a core is steping a way for a few months but intends to come back they can also say that in advance and there is no harm in leaving them for a cycle or two but in general after a period of in activity (usally more then a full release/6months) i think its good to reduce back down the core team.
Just my two cents
As of now, Cyborg core team officially has 12 members [1]. That is hardly small. Justin Kilpatrick seems to be gone for good; he didn't respond to my emails. Rushil Chugh confirmed that he is not working on OpenStack anymore and asked to step down as core. With due thanks to him for his contributions, I'll go ahead. Those are the two cores I had in mind. Agree with Sean that it is better to keep the list of core reviewers up to date. With all the changes in Cyborg over the past 18 months, it will be tough for a person to jump in after a long hiatus and resume as a core reviewer. Even if they want to come back, it is better for them to come up to speed first. Given this background, if there is any objection to the removal of these two cores, please let me know. [1] https://review.opendev.org/#/admin/groups/1243,members Regards, Sundar
On Wed, Mar 11, 2020 at 10:19 PM Nadathur, Sundar <sundar.nadathur@intel.com> wrote:
Hello all, Brin Zhang has been actively contributing to Cyborg in various areas, adding new features, improving quality, reviewing patches, and generally helping others in the community. Despite the relatively short time, he has been one of the most prolific contributors, and brings an enthusiastic and active mindset. I would like to thank him and acknowledge his significant contributions by proposing him as a core reviewer for Cyborg.
Shogo Saito has been active in Cyborg since Train release. He has been driving the Cyborg client improvements, including its revamp to use OpenStackSDK. Previously he was instrumental in the transition to Python 3, testing and fixing issues in the process. As he has access to real FPGA hardware, he brings a users’ perspective and also tests Cyborg with real hardware. I would like to thank and acknowledge him for his steady valuable contributions, and propose him as a core reviewer for Cyborg.
Some of the currently listed core reviewers have not been participating for a lengthy period of time. It is proposed that those who have had no contributions for the past 18 months – i.e. no participation in meetings, no code contributions and no reviews – be removed from the list of core reviewers.
If no objections are made known by March 20, I will make the changes proposed above.
Thanks.
Regards, Sundar
I have no particular objection about removing these particular two previous active cores, however I do concern that when we start to build a new precedence, we should do it right which means we should have an agreed set of metrics that provides the objective qualification of the "core removal" process. The original proposed qualification is "18 months no participation in meetings, no code contributions and no reviews", I would like that we could make the clarification that: - Is it a consecutive 18 months period with the construed "absence criteria" met ? - For the "absence criteria", could we settle upon a set of exhaustive metrics: no meeting, no code contribution, no review, no email discussion participation, anything more ? - If there were a set of agreed "absence criteria"s, what are the logical connection between these pre-conditions ? Is it an "AND" (all of the pre-conditions shall be satisfied) or just "OR" (only one of the pre-conditions satisfies) Once we have a concrete rule setup, we are good to go with a current core reviewer vote for the record of removing, as far as I understand :) Due process is very important. On Thu, Mar 12, 2020 at 8:40 AM Nadathur, Sundar <sundar.nadathur@intel.com> wrote:
From: Sean Mooney <smooney@redhat.com> Sent: Wednesday, March 11, 2020 9:37 AM
Big +1 for Brin and shogo's nomination and well deserved :)
I'm a little bit concerned over the 18 months period. The original rule we setup is volunteer step down, since this is a small team we want to acknowledge everyone that has made significant contributions. Some of the inactive core reviewers like Justin Kilpatrick have moved on a long time ago, and I don't see people like him could do any harm to
On Thu, 2020-03-12 at 00:17 +0800, Zhipeng Huang wrote: the project.
But if the core reviewer has a size limit in the system, that would be reasonable to replace the inactive ones with the new recruits :)
it is generally considerd best pratice to maintian the core team adding or removing people based on there activity. if a core is removed due to in activity and they come back they can always be restored but it give a bad perception if a project has like 20 core but only 2 are active. as a new contibutor you dont know which ones are active and it can be frustrating to reach out to them and get no responce. also just form a project healt point of view it make the project look like its more diverse or more active then it actully is which is also not generally a good thing.
that said core can step down if they feel like they can contribute time anymore when ever they like so and if a core is steping a way for a few months but intends to come back they can also say that in advance and there is no harm in leaving them for a cycle or two but in general after a period of in activity (usally more then a full release/6months) i think its good to reduce back down the core team.
Just my two cents
As of now, Cyborg core team officially has 12 members [1]. That is hardly small.
Justin Kilpatrick seems to be gone for good; he didn't respond to my emails. Rushil Chugh confirmed that he is not working on OpenStack anymore and asked to step down as core. With due thanks to him for his contributions, I'll go ahead.
Those are the two cores I had in mind. Agree with Sean that it is better to keep the list of core reviewers up to date. With all the changes in Cyborg over the past 18 months, it will be tough for a person to jump in after a long hiatus and resume as a core reviewer. Even if they want to come back, it is better for them to come up to speed first.
Given this background, if there is any objection to the removal of these two cores, please let me know.
[1] https://review.opendev.org/#/admin/groups/1243,members
Regards, Sundar
On Wed, Mar 11, 2020 at 10:19 PM Nadathur, Sundar <sundar.nadathur@intel.com> wrote:
Hello all, Brin Zhang has been actively contributing to Cyborg in various areas, adding new features, improving quality, reviewing patches, and generally helping others in the community. Despite the relatively short time, he has been one of the most prolific contributors, and brings an enthusiastic and active mindset. I would like to thank him and acknowledge his significant contributions by proposing him as a core reviewer for Cyborg.
Shogo Saito has been active in Cyborg since Train release. He has been driving the Cyborg client improvements, including its revamp to use OpenStackSDK. Previously he was instrumental in the transition to Python 3, testing and fixing issues in the process. As he has access to real FPGA hardware, he brings a users’ perspective and also tests Cyborg with real hardware. I would like to thank and acknowledge him for his steady valuable contributions, and propose him as a core reviewer for Cyborg.
Some of the currently listed core reviewers have not been participating for a lengthy period of time. It is proposed that those who have had no contributions for the past 18 months – i.e. no participation in meetings, no code contributions and no reviews – be removed from the list of core reviewers.
If no objections are made known by March 20, I will make the changes proposed above.
Thanks.
Regards, Sundar
-- Zhipeng (Howard) Huang Principle Engineer OpenStack, Kubernetes, CNCF, LF Edge, ONNX, Kubeflow, OpenSDS, Open Service Broker API, OCP, Hyperledger, ETSI, SNIA, DMTF, W3C
I have no particular objection about removing these particular two previous active cores, however I do concern that when we start to build a new precedence, we should do it right which means we should have an agreed set of metrics that provides the objective qualification of the "core removal" process.
The original proposed qualification is "18 months no participation in meetings, no code contributions and no reviews", I would like that we could make the clarification that:
- Is it a consecutive 18 months period with the construed "absence criteria" met ? i would think 18 months is slightly too long, it certely should not be longer then that. between 12 and 18 feels right to me. after about 2 cycle things can have changed significantly after 3 even more so. 6 monts feels way to sort but 12 to 18 i think is about right. - For the "absence criteria", could we settle upon a set of exhaustive metrics: no meeting, no code contribution, no review, no email discussion participation, anything more ?
- If there were a set of agreed "absence criteria"s, what are the logical connection between these pre-conditions ? Is it an "AND" (all of the pre-conditions shall be satisfied) or just "OR" (only one of the pre-conditions satisfies)
Once we have a concrete rule setup, we are good to go with a current core reviewer vote for the record of removing, as far as I understand :) well any core can step down without any kind of vote at any time.
On Thu, 2020-03-12 at 15:55 +0800, Zhipeng Huang wrote: the only metric for being a core rerviewer for being a core review should be based on well code reviews. code contibution without review should not be a consideration to keep core reviewer status. meeting, irc and email is also not really relevent with one exception. if cyborg was to do a virtual pre-ptg where specs desigin was disucssed and review on the mailing list via eamil, placmenet and nova have tried this in the last cycle or two, then i would consider that the same as gerrit review. i should qulify this that the metric should not be based on the number of reviews alone but rather how how detailed and well reasoned the comments are should be a large factor. a large number of +1 with no comment is generally an anti patteren fro considering some as a core. asking questions to clarify the design choices and confrim the authors intent and your understanding are in sync and make sense is perfectly valid to do while also +1 because you belive in your view the patch is correct and should be encurraged over +1 and no comment. the +1/-1 ratio should also be a factor. its if someone always +1s and never -1 they likely are not reviewing correctly other factors such as email participation, meeting attendence, irc presence or other community partisatpation are supporting factors that suggest a good candiate for becomeing a core but on there own should not be a vaild critia for granting or retaining core reviewer role in a project. my understanding of the above is derived form the definition of what a core review is https://docs.openstack.org/project-team-guide/open-development.html#core-rev... the review critia https://docs.openstack.org/project-team-guide/open-development.html#reviews-... https://docs.openstack.org/project-team-guide/review-the-openstack-way.html and my general experience with contributing to different openstack project. The core reviewer role withing a project while similar in some repects to a maintianer role in other opensouce models is not the same. a maintainers role tends to focus more on code authorship in addtion to review which is not a factor in the core reviewer role in openstack. if you never write a singel line of code but make detail and technically correct reviews in openstack that makes you an amazing core reviewer. conversly closing 100 bugs in a release with commits and doing no code review would make you a good maintainer but a bad core reviewer, you would be an invaluable contibutor for all your bug fixing work but no a good reviewer which s the focus of the core reviewer role. they just need to go to https://review.opendev.org/#/admin/groups/1243,members tick there name and remove them selvs and well tell the rest of the team so they know. unless the person being removed object or there is an object to the 2 people being proposed by one of the core team i don't think there is a reason to wait in this case but that is up to the core team to decide.
Due process is very important.
actually i would think that haveing concreate rules like this probably are not useful but if you do write them down you should stick with them.
On Thu, Mar 12, 2020 at 8:40 AM Nadathur, Sundar <sundar.nadathur@intel.com> wrote:
From: Sean Mooney <smooney@redhat.com> Sent: Wednesday, March 11, 2020 9:37 AM
On Thu, 2020-03-12 at 00:17 +0800, Zhipeng Huang wrote:
Big +1 for Brin and shogo's nomination and well deserved :)
I'm a little bit concerned over the 18 months period. The original rule we setup is volunteer step down, since this is a small team we want to acknowledge everyone that has made significant contributions. Some of the inactive core reviewers like Justin Kilpatrick have moved on a long time ago, and I don't see people like him could do any harm
to
the project.
But if the core reviewer has a size limit in the system, that would be reasonable to replace the inactive ones with the new recruits :)
it is generally considerd best pratice to maintian the core team adding
or
removing people based on there activity. if a core is removed due to in activity and they come back they can always be restored but it give a bad perception if a project has like 20 core but only 2 are active. as a new contibutor you dont know which ones are active and it can be frustrating
to
reach out to them and get no responce. also just form a project healt point of view it make the project look
like its
more diverse or more active then it actully is which is also not
generally a
good thing.
that said core can step down if they feel like they can contribute time anymore when ever they like so and if a core is steping a way for a few months but intends to come back they can also say that in advance and
there
is no harm in leaving them for a cycle or two but in general after a
period of
in activity (usally more then a full release/6months) i think its good
to reduce
back down the core team.
Just my two cents
As of now, Cyborg core team officially has 12 members [1]. That is hardly small.
Justin Kilpatrick seems to be gone for good; he didn't respond to my emails. Rushil Chugh confirmed that he is not working on OpenStack anymore and asked to step down as core. With due thanks to him for his contributions, I'll go ahead.
Those are the two cores I had in mind. Agree with Sean that it is better to keep the list of core reviewers up to date. With all the changes in Cyborg over the past 18 months, it will be tough for a person to jump in after a long hiatus and resume as a core reviewer. Even if they want to come back, it is better for them to come up to speed first.
Given this background, if there is any objection to the removal of these two cores, please let me know.
[1] https://review.opendev.org/#/admin/groups/1243,members
Regards, Sundar
On Wed, Mar 11, 2020 at 10:19 PM Nadathur, Sundar <sundar.nadathur@intel.com> wrote:
Hello all, Brin Zhang has been actively contributing to Cyborg in various areas, adding new features, improving quality, reviewing patches, and generally helping others in the community. Despite the relatively short time, he has been one of the most prolific contributors, and brings an enthusiastic and active mindset. I would like to thank him and acknowledge his significant contributions by
proposing him as a core reviewer for Cyborg.
Shogo Saito has been active in Cyborg since Train release. He has been driving the Cyborg client improvements, including its revamp to use OpenStackSDK. Previously he was instrumental in the transition to Python 3, testing and fixing issues in the process. As he has access to real FPGA hardware, he brings a users’ perspective and also tests Cyborg with real hardware. I would like to thank and acknowledge him for his steady valuable contributions, and propose
him
as a core reviewer for Cyborg.
Some of the currently listed core reviewers have not been participating for a lengthy period of time. It is proposed that those who have had no contributions for the past 18 months – i.e. no participation in meetings, no code contributions and no reviews – be removed from the list of core reviewers.
If no objections are made known by March 20, I will make the changes proposed above.
Thanks.
Regards, Sundar
I like what Sean proposed, and a cycle bound time criteria (2 cycles or 12 months) would be very good, and if we center the quality criteria on meaningful reviews would largely reduced the burden of unnecessary computations. I agree that we should document this and stick to it. For me "12 months + no meaningful review" would be a good enough concrete criteria, for removing the non-active core reviewer in a non-voluntarily step down fashion. On Thu, Mar 12, 2020 at 7:48 PM Sean Mooney <smooney@redhat.com> wrote:
I have no particular objection about removing these particular two
active cores, however I do concern that when we start to build a new precedence, we should do it right which means we should have an agreed set of metrics that provides the objective qualification of the "core removal" process.
The original proposed qualification is "18 months no participation in meetings, no code contributions and no reviews", I would like that we could make the clarification that:
- Is it a consecutive 18 months period with the construed "absence criteria" met ? i would think 18 months is slightly too long, it certely should not be longer then that. between 12 and 18 feels right to me. after about 2 cycle things can have changed significantly after 3 even more so. 6 monts feels way to sort but 12 to 18 i think is about right. - For the "absence criteria", could we settle upon a set of exhaustive metrics: no meeting, no code contribution, no review, no email discussion participation, anything more ?
On Thu, 2020-03-12 at 15:55 +0800, Zhipeng Huang wrote: previous the only metric for being a core rerviewer for being a core review should be based on well code reviews. code contibution without review should not be a consideration to keep core reviewer status. meeting, irc and email is also not really relevent with one exception. if cyborg was to do a virtual pre-ptg where specs desigin was disucssed and review on the mailing list via eamil, placmenet and nova have tried this in the last cycle or two, then i would consider that the same as gerrit review.
i should qulify this that the metric should not be based on the number of reviews alone but rather how how detailed and well reasoned the comments are should be a large factor. a large number of +1 with no comment is generally an anti patteren fro considering some as a core. asking questions to clarify the design choices and confrim the authors intent and your understanding are in sync and make sense is perfectly valid to do while also +1 because you belive in your view the patch is correct and should be encurraged over +1 and no comment.
the +1/-1 ratio should also be a factor. its if someone always +1s and never -1 they likely are not reviewing correctly
other factors such as email participation, meeting attendence, irc presence or other community partisatpation are supporting factors that suggest a good candiate for becomeing a core but on there own should not be a vaild critia for granting or retaining core reviewer role in a project.
my understanding of the above is derived form the definition of what a core review is
https://docs.openstack.org/project-team-guide/open-development.html#core-rev... the review critia https://docs.openstack.org/project-team-guide/open-development.html#reviews-... https://docs.openstack.org/project-team-guide/review-the-openstack-way.html and my general experience with contributing to different openstack project. The core reviewer role withing a project while similar in some repects to a maintianer role in other opensouce models is not the same. a maintainers role tends to focus more on code authorship in addtion to review which is not a factor in the core reviewer role in openstack. if you never write a singel line of code but make detail and technically correct reviews in openstack that makes you an amazing core reviewer. conversly closing 100 bugs in a release with commits and doing no code review would make you a good maintainer but a bad core reviewer, you would be an invaluable contibutor for all your bug fixing work but no a good reviewer which s the focus of the core reviewer role.
- If there were a set of agreed "absence criteria"s, what are the logical connection between these pre-conditions ? Is it an "AND" (all of the pre-conditions shall be satisfied) or just "OR" (only one of the pre-conditions satisfies)
Once we have a concrete rule setup, we are good to go with a current core reviewer vote for the record of removing, as far as I understand :) well any core can step down without any kind of vote at any time. they just need to go to https://review.opendev.org/#/admin/groups/1243,members tick there name and remove them selvs and well tell the rest of the team so they know.
unless the person being removed object or there is an object to the 2 people being proposed by one of the core team i don't think there is a reason to wait in this case but that is up to the core team to decide.
Due process is very important.
actually i would think that haveing concreate rules like this probably are not useful but if you do write them down you should stick with them.
On Thu, Mar 12, 2020 at 8:40 AM Nadathur, Sundar <
wrote:
From: Sean Mooney <smooney@redhat.com> Sent: Wednesday, March 11, 2020 9:37 AM
On Thu, 2020-03-12 at 00:17 +0800, Zhipeng Huang wrote:
Big +1 for Brin and shogo's nomination and well deserved :)
I'm a little bit concerned over the 18 months period. The original rule we setup is volunteer step down, since this is a small team we want to acknowledge everyone that has made significant
contributions.
Some of the inactive core reviewers like Justin Kilpatrick have moved on a long time ago, and I don't see people like him could do any harm
to
the project.
But if the core reviewer has a size limit in the system, that
would be
reasonable to replace the inactive ones with the new recruits :)
it is generally considerd best pratice to maintian the core team adding
or
removing people based on there activity. if a core is removed due to in activity and they come back they can always be restored but it give a bad perception if a project has like 20 core but only 2 are active. as a new contibutor you dont know which ones are active and it can be frustrating
to
reach out to them and get no responce. also just form a project healt point of view it make the project look
like its
more diverse or more active then it actully is which is also not
generally a
good thing.
that said core can step down if they feel like they can contribute time anymore when ever they like so and if a core is steping a way for a few months but intends to come back they can also say that in advance and
there
is no harm in leaving them for a cycle or two but in general after a
period of
in activity (usally more then a full release/6months) i think its good
to reduce
back down the core team.
Just my two cents
As of now, Cyborg core team officially has 12 members [1]. That is hardly small.
Justin Kilpatrick seems to be gone for good; he didn't respond to my emails. Rushil Chugh confirmed that he is not working on OpenStack anymore and asked to step down as core. With due thanks to him for his contributions, I'll go ahead.
Those are the two cores I had in mind. Agree with Sean that it is better to keep the list of core reviewers up to date. With all the changes in Cyborg over the past 18 months, it will be tough for a person to jump in after a long hiatus and resume as a core reviewer. Even if they want to come back, it is better for them to come up to speed first.
Given this background, if there is any objection to the removal of
two cores, please let me know.
[1] https://review.opendev.org/#/admin/groups/1243,members
Regards, Sundar
On Wed, Mar 11, 2020 at 10:19 PM Nadathur, Sundar <sundar.nadathur@intel.com> wrote:
Hello all, Brin Zhang has been actively contributing to Cyborg in various areas, adding new features, improving quality, reviewing patches, and generally helping others in the community. Despite the relatively short time, he has been one of the most prolific contributors, and brings an enthusiastic and active mindset. I would like to thank him and acknowledge his significant contributions by
proposing him as a core reviewer for Cyborg.
Shogo Saito has been active in Cyborg since Train release. He has been driving the Cyborg client improvements, including its
revamp to
use OpenStackSDK. Previously he was instrumental in the
to Python 3, testing and fixing issues in the process. As he has access to real FPGA hardware, he brings a users’ perspective and also tests Cyborg with real hardware. I would like to thank and acknowledge him for his steady valuable contributions, and
sundar.nadathur@intel.com> these transition propose
him
as a core reviewer for Cyborg.
Some of the currently listed core reviewers have not been participating for a lengthy period of time. It is proposed that those who have had no contributions for the past 18 months –
i.e. no
participation in meetings, no code contributions and no reviews – be removed from the list of core reviewers.
If no objections are made known by March 20, I will make the changes proposed above.
Thanks.
Regards, Sundar
-- Zhipeng (Howard) Huang Principle Engineer OpenStack, Kubernetes, CNCF, LF Edge, ONNX, Kubeflow, OpenSDS, Open Service Broker API, OCP, Hyperledger, ETSI, SNIA, DMTF, W3C
From: Zhipeng Huang <zhipengh512@gmail.com> Sent: Thursday, March 12, 2020 6:21 AM
I like what Sean proposed, and a cycle bound time criteria (2 cycles or 12 months) would be very good, and if we center the quality criteria on meaningful reviews would largely reduced the burden of unnecessary computations.
I agree that we should document this and stick to it. For me "12 months + no meaningful review" would be a good enough concrete criteria, for removing the non-active core reviewer in a non-voluntarily step down fashion.
I have no particular objection about removing these particular two previous active cores, however I do concern that when we start to build a new precedence, we should do it right which means we should have an agreed set of metrics that provides the objective qualification of the "core removal" process.
The original proposed qualification is "18 months no participation in meetings, no code contributions and no reviews", I would like that we could make the clarification that:
- Is it a consecutive 18 months period with the construed "absence criteria" met ? i would think 18 months is slightly too long, it certely should not be longer then that. between 12 and 18 feels right to me. after about 2 cycle things can have changed significantly after 3 even more so. 6 monts feels way to sort but 12 to 18 i think is about right. - For the "absence criteria", could we settle upon a set of exhaustive metrics: no meeting, no code contribution, no review, no email discussion participation, anything more ?
- If there were a set of agreed "absence criteria"s, what are the logical connection between these pre-conditions ? Is it an "AND" (all of the pre-conditions shall be satisfied) or just "OR" (only one of the pre-conditions satisfies)
Once we have a concrete rule setup, we are good to go with a current core reviewer vote for the record of removing, as far as I understand :) well any core can step down without any kind of vote at any time.
Apart from a specific period for reviewing the, um, reviews, I would suggest talking to the reviewer in question to understand any exigent circumstances and their intentions, esp. if there are other factors like meanigful patch contributions and active attendance in meetings/PTG/etc. After all, a person may have spent months preparing to be a core reviewer, and it would be a shame to let all that drop. If the person is unreachable or explicitly indicates a desire to step down, as has happened in this situation, there would be solid grounds to take their name off. Regards, Sundar On Thu, Mar 12, 2020 at 7:48 PM Sean Mooney <smooney@redhat.com<mailto:smooney@redhat.com>> wrote: On Thu, 2020-03-12 at 15:55 +0800, Zhipeng Huang wrote: the only metric for being a core rerviewer for being a core review should be based on well code reviews. code contibution without review should not be a consideration to keep core reviewer status. meeting, irc and email is also not really relevent with one exception. if cyborg was to do a virtual pre-ptg where specs desigin was disucssed and review on the mailing list via eamil, placmenet and nova have tried this in the last cycle or two, then i would consider that the same as gerrit review. i should qulify this that the metric should not be based on the number of reviews alone but rather how how detailed and well reasoned the comments are should be a large factor. a large number of +1 with no comment is generally an anti patteren fro considering some as a core. asking questions to clarify the design choices and confrim the authors intent and your understanding are in sync and make sense is perfectly valid to do while also +1 because you belive in your view the patch is correct and should be encurraged over +1 and no comment. the +1/-1 ratio should also be a factor. its if someone always +1s and never -1 they likely are not reviewing correctly other factors such as email participation, meeting attendence, irc presence or other community partisatpation are supporting factors that suggest a good candiate for becomeing a core but on there own should not be a vaild critia for granting or retaining core reviewer role in a project. my understanding of the above is derived form the definition of what a core review is https://docs.openstack.org/project-team-guide/open-development.html#core-rev... the review critia https://docs.openstack.org/project-team-guide/open-development.html#reviews-... https://docs.openstack.org/project-team-guide/review-the-openstack-way.html and my general experience with contributing to different openstack project. The core reviewer role withing a project while similar in some repects to a maintianer role in other opensouce models is not the same. a maintainers role tends to focus more on code authorship in addtion to review which is not a factor in the core reviewer role in openstack. if you never write a singel line of code but make detail and technically correct reviews in openstack that makes you an amazing core reviewer. conversly closing 100 bugs in a release with commits and doing no code review would make you a good maintainer but a bad core reviewer, you would be an invaluable contibutor for all your bug fixing work but no a good reviewer which s the focus of the core reviewer role. they just need to go to https://review.opendev.org/#/admin/groups/1243,members tick there name and remove them selvs and well tell the rest of the team so they know. unless the person being removed object or there is an object to the 2 people being proposed by one of the core team i don't think there is a reason to wait in this case but that is up to the core team to decide.
Due process is very important.
actually i would think that haveing concreate rules like this probably are not useful but if you do write them down you should stick with them.
On Thu, Mar 12, 2020 at 8:40 AM Nadathur, Sundar <sundar.nadathur@intel.com<mailto:sundar.nadathur@intel.com>> wrote:
From: Sean Mooney <smooney@redhat.com<mailto:smooney@redhat.com>> Sent: Wednesday, March 11, 2020 9:37 AM
On Thu, 2020-03-12 at 00:17 +0800, Zhipeng Huang wrote:
Big +1 for Brin and shogo's nomination and well deserved :)
I'm a little bit concerned over the 18 months period. The original rule we setup is volunteer step down, since this is a small team we want to acknowledge everyone that has made significant contributions. Some of the inactive core reviewers like Justin Kilpatrick have moved on a long time ago, and I don't see people like him could do any harm
to
the project.
But if the core reviewer has a size limit in the system, that would be reasonable to replace the inactive ones with the new recruits :)
it is generally considerd best pratice to maintian the core team adding
or
removing people based on there activity. if a core is removed due to in activity and they come back they can always be restored but it give a bad perception if a project has like 20 core but only 2 are active. as a new contibutor you dont know which ones are active and it can be frustrating
to
reach out to them and get no responce. also just form a project healt point of view it make the project look
like its
more diverse or more active then it actully is which is also not
generally a
good thing.
that said core can step down if they feel like they can contribute time anymore when ever they like so and if a core is steping a way for a few months but intends to come back they can also say that in advance and
there
is no harm in leaving them for a cycle or two but in general after a
period of
in activity (usally more then a full release/6months) i think its good
to reduce
back down the core team.
Just my two cents
As of now, Cyborg core team officially has 12 members [1]. That is hardly small.
Justin Kilpatrick seems to be gone for good; he didn't respond to my emails. Rushil Chugh confirmed that he is not working on OpenStack anymore and asked to step down as core. With due thanks to him for his contributions, I'll go ahead.
Those are the two cores I had in mind. Agree with Sean that it is better to keep the list of core reviewers up to date. With all the changes in Cyborg over the past 18 months, it will be tough for a person to jump in after a long hiatus and resume as a core reviewer. Even if they want to come back, it is better for them to come up to speed first.
Given this background, if there is any objection to the removal of these two cores, please let me know.
[1] https://review.opendev.org/#/admin/groups/1243,members
Regards, Sundar
On Wed, Mar 11, 2020 at 10:19 PM Nadathur, Sundar <sundar.nadathur@intel.com<mailto:sundar.nadathur@intel.com>> wrote:
Hello all, Brin Zhang has been actively contributing to Cyborg in various areas, adding new features, improving quality, reviewing patches, and generally helping others in the community. Despite the relatively short time, he has been one of the most prolific contributors, and brings an enthusiastic and active mindset. I would like to thank him and acknowledge his significant contributions by
proposing him as a core reviewer for Cyborg.
Shogo Saito has been active in Cyborg since Train release. He has been driving the Cyborg client improvements, including its revamp to use OpenStackSDK. Previously he was instrumental in the transition to Python 3, testing and fixing issues in the process. As he has access to real FPGA hardware, he brings a users’ perspective and also tests Cyborg with real hardware. I would like to thank and acknowledge him for his steady valuable contributions, and propose
him
as a core reviewer for Cyborg.
Some of the currently listed core reviewers have not been participating for a lengthy period of time. It is proposed that those who have had no contributions for the past 18 months – i.e. no participation in meetings, no code contributions and no reviews – be removed from the list of core reviewers.
If no objections are made known by March 20, I will make the changes proposed above.
Thanks.
Regards, Sundar
-- Zhipeng (Howard) Huang Principle Engineer OpenStack, Kubernetes, CNCF, LF Edge, ONNX, Kubeflow, OpenSDS, Open Service Broker API, OCP, Hyperledger, ETSI, SNIA, DMTF, W3C
On Thu, 2020-03-12 at 23:48 +0000, Nadathur, Sundar wrote:
From: Zhipeng Huang <zhipengh512@gmail.com> Sent: Thursday, March 12, 2020 6:21 AM
I like what Sean proposed, and a cycle bound time criteria (2 cycles or 12 months) would be very good, and if we center the quality criteria on meaningful reviews would largely reduced the burden of unnecessary computations. I agree that we should document this and stick to it. For me "12 months + no meaningful review" would be a good enough concrete criteria, for removing the non-active core reviewer in a non-voluntarily step down fashion.
Apart from a specific period for reviewing the, um, reviews, I would suggest talking to the reviewer in question to understand any exigent circumstances and their intentions, esp. if there are other factors like meanigful patch contributions and active attendance in meetings/PTG/etc. After all, a person may have spent months preparing to be a core reviewer, and it would be a shame to let all that drop.
If the person is unreachable or explicitly indicates a desire to step down, as has happened in this situation, there would be solid grounds to take their name off.
yep reaching out to them before doing anything else is both politte and pragmatic. we reach out before propsoeing some one as a core to ensure they are ok with it it makes total sense to reach out to people before propoesing reomving someone and ya or factor in life migth affect why a person has to be inactive although if it gets to the point of 2-3 cylces or 12-18 months where they cant partisapte then its likely they will continue to be unable to participate and review.
Regards, Sundar
On Thu, Mar 12, 2020 at 7:48 PM Sean Mooney <smooney@redhat.com<mailto:smooney@redhat.com>> wrote: On Thu, 2020-03-12 at 15:55 +0800, Zhipeng Huang wrote:
I have no particular objection about removing these particular two previous active cores, however I do concern that when we start to build a new precedence, we should do it right which means we should have an agreed set of metrics that provides the objective qualification of the "core removal" process.
The original proposed qualification is "18 months no participation in meetings, no code contributions and no reviews", I would like that we could make the clarification that:
- Is it a consecutive 18 months period with the construed "absence criteria" met ?
i would think 18 months is slightly too long, it certely should not be longer then that. between 12 and 18 feels right to me. after about 2 cycle things can have changed significantly after 3 even more so. 6 monts feels way to sort but 12 to 18 i think is about right.
- For the "absence criteria", could we settle upon a set of exhaustive metrics: no meeting, no code contribution, no review, no email discussion participation, anything more ?
the only metric for being a core rerviewer for being a core review should be based on well code reviews. code contibution without review should not be a consideration to keep core reviewer status. meeting, irc and email is also not really relevent with one exception. if cyborg was to do a virtual pre-ptg where specs desigin was disucssed and review on the mailing list via eamil, placmenet and nova have tried this in the last cycle or two, then i would consider that the same as gerrit review.
i should qulify this that the metric should not be based on the number of reviews alone but rather how how detailed and well reasoned the comments are should be a large factor. a large number of +1 with no comment is generally an anti patteren fro considering some as a core. asking questions to clarify the design choices and confrim the authors intent and your understanding are in sync and make sense is perfectly valid to do while also +1 because you belive in your view the patch is correct and should be encurraged over +1 and no comment.
the +1/-1 ratio should also be a factor. its if someone always +1s and never -1 they likely are not reviewing correctly
other factors such as email participation, meeting attendence, irc presence or other community partisatpation are supporting factors that suggest a good candiate for becomeing a core but on there own should not be a vaild critia for granting or retaining core reviewer role in a project.
my understanding of the above is derived form the definition of what a core review is https://docs.openstack.org/project-team-guide/open-development.html#core-rev... the review critia https://docs.openstack.org/project-team-guide/open-development.html#reviews-... https://docs.openstack.org/project-team-guide/review-the-openstack-way.html and my general experience with contributing to different openstack project. The core reviewer role withing a project while similar in some repects to a maintianer role in other opensouce models is not the same. a maintainers role tends to focus more on code authorship in addtion to review which is not a factor in the core reviewer role in openstack. if you never write a singel line of code but make detail and technically correct reviews in openstack that makes you an amazing core reviewer. conversly closing 100 bugs in a release with commits and doing no code review would make you a good maintainer but a bad core reviewer, you would be an invaluable contibutor for all your bug fixing work but no a good reviewer which s the focus of the core reviewer role.
- If there were a set of agreed "absence criteria"s, what are the logical connection between these pre-conditions ? Is it an "AND" (all of the pre-conditions shall be satisfied) or just "OR" (only one of the pre-conditions satisfies)
Once we have a concrete rule setup, we are good to go with a current core reviewer vote for the record of removing, as far as I understand :)
well any core can step down without any kind of vote at any time. they just need to go to https://review.opendev.org/#/admin/groups/1243,members tick there name and remove them selvs and well tell the rest of the team so they know.
unless the person being removed object or there is an object to the 2 people being proposed by one of the core team i don't think there is a reason to wait in this case but that is up to the core team to decide.
Due process is very important.
actually i would think that haveing concreate rules like this probably are not useful but if you do write them down you should stick with them.
On Thu, Mar 12, 2020 at 8:40 AM Nadathur, Sundar <sundar.nadathur@intel.com<mailto:sundar.nadathur@intel.com>> wrote:
From: Sean Mooney <smooney@redhat.com<mailto:smooney@redhat.com>> Sent: Wednesday, March 11, 2020 9:37 AM
On Thu, 2020-03-12 at 00:17 +0800, Zhipeng Huang wrote:
Big +1 for Brin and shogo's nomination and well deserved :)
I'm a little bit concerned over the 18 months period. The original rule we setup is volunteer step down, since this is a small team we want to acknowledge everyone that has made significant contributions. Some of the inactive core reviewers like Justin Kilpatrick have moved on a long time ago, and I don't see people like him could do any harm
to
the project.
But if the core reviewer has a size limit in the system, that would be reasonable to replace the inactive ones with the new recruits :)
it is generally considerd best pratice to maintian the core team adding
or
removing people based on there activity. if a core is removed due to in activity and they come back they can always be restored but it give a bad perception if a project has like 20 core but only 2 are active. as a new contibutor you dont know which ones are active and it can be frustrating
to
reach out to them and get no responce. also just form a project healt point of view it make the project look
like its
more diverse or more active then it actully is which is also not
generally a
good thing.
that said core can step down if they feel like they can contribute time anymore when ever they like so and if a core is steping a way for a few months but intends to come back they can also say that in advance and
there
is no harm in leaving them for a cycle or two but in general after a
period of
in activity (usally more then a full release/6months) i think its good
to reduce
back down the core team.
Just my two cents
As of now, Cyborg core team officially has 12 members [1]. That is hardly small.
Justin Kilpatrick seems to be gone for good; he didn't respond to my emails. Rushil Chugh confirmed that he is not working on OpenStack anymore and asked to step down as core. With due thanks to him for his contributions, I'll go ahead.
Those are the two cores I had in mind. Agree with Sean that it is better to keep the list of core reviewers up to date. With all the changes in Cyborg over the past 18 months, it will be tough for a person to jump in after a long hiatus and resume as a core reviewer. Even if they want to come back, it is better for them to come up to speed first.
Given this background, if there is any objection to the removal of these two cores, please let me know.
[1] https://review.opendev.org/#/admin/groups/1243,members
Regards, Sundar
On Wed, Mar 11, 2020 at 10:19 PM Nadathur, Sundar <sundar.nadathur@intel.com<mailto:sundar.nadathur@intel.com>> wrote:
Hello all, Brin Zhang has been actively contributing to Cyborg in various areas, adding new features, improving quality, reviewing patches, and generally helping others in the community. Despite the relatively short time, he has been one of the most prolific contributors, and brings an enthusiastic and active mindset. I would like to thank him and acknowledge his significant contributions by
proposing him as a core reviewer for Cyborg.
Shogo Saito has been active in Cyborg since Train release. He has been driving the Cyborg client improvements, including its revamp to use OpenStackSDK. Previously he was instrumental in the transition to Python 3, testing and fixing issues in the process. As he has access to real FPGA hardware, he brings a users’ perspective and also tests Cyborg with real hardware. I would like to thank and acknowledge him for his steady valuable contributions, and propose
him
as a core reviewer for Cyborg.
Some of the currently listed core reviewers have not been participating for a lengthy period of time. It is proposed that those who have had no contributions for the past 18 months – i.e. no participation in meetings, no code contributions and no reviews – be removed from the list of core reviewers.
If no objections are made known by March 20, I will make the changes proposed above.
Thanks.
Regards, Sundar
-- Zhipeng (Howard) Huang
Principle Engineer OpenStack, Kubernetes, CNCF, LF Edge, ONNX, Kubeflow, OpenSDS, Open Service Broker API, OCP, Hyperledger, ETSI, SNIA, DMTF, W3C
participants (3)
-
Nadathur, Sundar
-
Sean Mooney
-
Zhipeng Huang