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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
