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