Open Stack

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-reviewers
the review critia https://docs.openstack.org/project-team-guide/open-development.html#reviews-guidelines
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 at intel.com>
> wrote:
> 
> > 
> > > From: Sean Mooney <smooney at 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 at 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
> > 
> > 
> 
>