Open Stack

As a relatively new member of the openstack community I think the idea of a
mentorship program is a good one; I'd like to throw my hat in the ring if
the kolla community needs a guinea-pig to try this on. :)

Rich

On Wed, Apr 12, 2017 at 7:53 PM Matt Riedemann <mriedemos at gmail.com> wrote:

> On 4/12/2017 3:40 PM, Steven Dake (stdake) wrote:
> > Matt,
> >
> > Thanks for the response.  It is helpful.
> >
> > Regards
> > -steve
> >
> > -----Original Message-----
> > From: Matt Riedemann <mriedemos at gmail.com>
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> > Date: Wednesday, April 12, 2017 at 4:36 PM
> > To: "openstack-dev at lists.openstack.org" <
> openstack-dev at lists.openstack.org>
> > Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer
> mentorship program for Kolla deliverables
> >
> >     On 4/12/2017 11:59 AM, Steven Dake (stdake) wrote:
> >     > Hey folks,
> >     >
> >     >
> >     >
> >     > In today’s Kolla team meeting, the idea was proposed of adopting
> nova’s
> >     > “protocore” mentorship program for Kolla.  We would like to know
> what
> >     > nova has learned from this effort.
> >     >
> >     >
> >     >
> >     > In today’s Kolla meeting we had broad consensus on the following:
> >     >
> >     > 1)       Kolla has participants that want to be core reviewers
> >     >
> >     > 2)       These participants don’t know how to become core reviewers
> >     >
> >     > 3)       The core reviewers in Kolla should mentor “protocore”
> reviewers
> >     > on how to do good reviews
> >     >
> >     >
> >     >
> >     > From that, we concluded some form of mentorship program for
> potential
> >     > core reviewers was in order.  We got into some debate about
> _/how/_ the
> >     > program should be rolled out.  Let’s use this thread to discuss
> how it
> >     > should be rolled out since that seems to be the sticking point of
> the
> >     > discussion.  I saw no dissent in the discussion that the basic
> concepts
> >     > were a negative change.
> >     >
> >     >
> >     >
> >     > I am aware that nova uses a +1 review from a “protocore” and a
> +2/+w
> >     > from a core reviewer prior to merge.  Nova cores – would you mind
> >     > defining your process (on the ml is fine) more thoroughly and your
> >     > experiences so we can learn from you?
> >     >
> >     >
> >     >
> >     > All kolla contributors, feel free to debate the **how** such a
> >     > mentorship program should be rolled out.  I think we have a lot to
> learn
> >     > from our peers in the OpenStack community and learning from their
> >     > experiences may be helpful.
> >     >
> >     >
> >     >
> >     > Regards
> >     >
> >     > -steve
> >     >
> >     >
> >     >
> >     >
> >     >
> >     >
> __________________________________________________________________________
> >     > OpenStack Development Mailing List (not for usage questions)
> >     > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >     >
> >
> >     Nova has this thing? That's news to me. :)
> >
> >     I don't think Nova has a formal process for something like this.
> There
> >     was talk at the BCN summit about giving some people +2 rights on
> parts
> >     of the tree but not full core on everything. We never implemented
> that.
> >
> >     Maybe what you're referring to is how we consider a +1 from a domain
> >     expert like a +2, or at least something that's good to have before
> cores
> >     are looking into the change in more detail? For example, gibi is the
> >     lead for the versioned notifications effort and we/I generally look
> for
> >     his +1 on a change before digging into it, or approving it. We have
> >     similar unofficial things like this in other parts of Nova, or
> subteams,
> >     like Timofey and Pawel with the live migration subteam.
> >
> >     To be sure, someone that is leading a subteam effort and is looked to
> >     for their opinion on a whole series of changes eventually gets into
> the
> >     conversation when we're talking about potential core reviewers, in
> part
> >     because, at least I personally, am looking for not only strong code
> >     review skills but also leadership/ownership within the project,
> because
> >     those are also the people that tend to stick around awhile so I'm
> more
> >     comfortable investing my time into them (and building a trust
> >     relationship with them).
> >
> >     So that's all unofficial non-formal stuff and basically grew up
> >     organically around the subteam efforts that started several releases
> >     ago. I don't know if this helps you or not.
> >
> >     --
> >
> >     Thanks,
> >
> >     Matt
> >
> >
>  __________________________________________________________________________
> >     OpenStack Development Mailing List (not for usage questions)
> >     Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> By the way, I should add, while we look for a +1 from a subteam or
> domain expert, it does not equate to a +2 so that a core can come along
> and +2/+W. We still require 2 +2s.
>
> --
>
> Thanks,
>
> Matt
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170413/2fe5a2c6/attachment.html>