[openstack-dev] [heat] Core criteria, review stats vs reality
asalkeld at redhat.com
Mon Dec 9 23:52:45 UTC 2013
On 09/12/13 11:31 +0000, Steven Hardy wrote:
>So I've been getting concerned about $subject recently, and based on some
>recent discussions so have some other heat-core folks, so I wanted to start
>a discussion where we can agree and communicate our expectations related to
>nomination for heat-core membership (becuase we do need more core
>The issues I have are:
>- Russell's stats (while very useful) are being used by some projects as
> the principal metric related to -core membership (ref TripleO's monthly
> cull/name&shame, which I am opposed to btw). This is in some cases
> encouraging some stats-seeking in our review process, IMO.
>- Review quality can't be measured mechanically - we have some folks who
> contribute fewer, but very high quality reviews, and are also very active
> contributors (so knowledge of the codebase is not stale). I'd like to
> see these people do more reviews, but removing people from core just
> because they drop below some arbitrary threshold makes no sense to me.
>So if you're aiming for heat-core nomination, here's my personal wish-list,
>but hopefully others can proide their input and we can update the wiki with
>the resulting requirements/guidelines:
>- Make your reviews high-quality. Focus on spotting logical errors,
> reducing duplication, consistency with existing interfaces, opportunities
> for reuse/simplification etc. If every review you do is +1, or -1 for a
> trivial/cosmetic issue, you are not making a strong case for -core IMHO.
>- Send patches. Some folks argue that -core membership is only about
> reviews, I disagree - There are many aspects of reviews which require
> deep knowledge of the code, e.g spotting structural issues, logical
> errors caused by interaction with code not modified by the patch,
> effective use of test infrastructure, etc etc. This deep knowledge comes
> from writing code, not only reviewing it. This also gives us a way to
> verify your understanding and alignment with our sylistic conventions.
>- Fix bugs. Related to the above, help us fix real problems by testing,
> reporting bugs, and fixing them, or take an existing bug and post a patch
> fixing it. Ask an existing team member to direct you if you're not sure
> which bug to tackle. Sending patches doing trivial cosmetic cleanups is
> sometimes worthwhile, but make sure that's not all you do, as we need
> -core folk who can find, report, fix and review real user-impacting
> problems (not just new features). This is also a great way to build
> trust and knowledge if you're aiming to contribute features to Heat.
>- Engage in discussions related to the project (here on the ML, helping
> users on the general list, in #heat on Freenode, attend our weekly
> meeting if it's not an anti-social time in your TZ)
>Anyone have any more thoughts to add here?
Setting a side the mechanism for choosing team-core, I think we should
be re-evaluating more often (some regular interval - maybe every 2
- Personally I'd not be stressed at all about been taken off core one
period and re-add later (if I was busy with something else and
didn't have time for reviews).
- I think this sends a good message that core is not set in stone.
Given some hard work you too can get in core (if you aspire to).
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev