Open Stack

On 09/12/13 11:31 +0000, Steven Hardy wrote:
>Hi all,
>
>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
>reviewers):
>
>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
months).

- 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).


-Angus

>
>Steve
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev