Jump to: navigation, search

Nova/Mentoring

< Nova
Revision as of 10:45, 23 June 2015 by Sudipto (talk | contribs) (How to do great code reviews?)

So you want to give more involved with Nova? Or you are new to Nova and wondering where to start?

We are working on building easy ways for you to get help and ideas on how to learn more about Nova and how the Nova community works.

Any questions, please ask! If you are unsure who to ask, then please contact the Mentoring Czar.

How do I get started?

There are quite a few global docs on this:

What should I work on?

So you are starting out your Nova journey, where is a good place to start?

Bugs are a great way to cut your Nova teeth: https://bugs.launchpad.net/nova/+bugs?field.tag=low-hanging-fruit

Also, we guess that you probably want to understand how Nova works before changing anything ? Good news, we have a solution for you! Code reviews are usually the best way for ramping up on a project and get and compare feedback on what's bad or what's cool. For that, you can help us. We have a list of trivial bugs that are waiting reviews : https://etherpad.openstack.org/p/liberty-nova-priorities-tracking L25 and below

We also have a list of low hanging fruit work available: https://etherpad.openstack.org/p/nova-low-hanging-fruit

How do I get my feature in?

The best way of getting your feature in is... well it depends.

First concentrate on solving your problem and/or use case, don't fixate on getting the code you have working merged. Its likely things will need significant re-work after you discuss how your needs match up with all the existing ways Nova is currently being used. The good news, is this process should leave you with a feature thats more flexible and doesn't lock you into your current way of thinking.

A key part of getting code merged, is helping with reviewing other people's code. Great reviews of others code will help free up more core reviewer time to look at your own patches. In addition, you will understand how the review is thinking when they review your code.

Also, work out if any on going efforts are blocking your feature and helping out speeding those up. The spec review process should help with this effort.

What is expected of a good contributor?

TODO - need more info on this

Top Tips for working with the Nova community

Here are some top tips around engaging with the Nova community:

  • IRC
    • we talk a lot in #openstack-nova
    • do ask us questions in there, and we will try to help you
    • not sure about asking questions? feel free to listen in around other people's questions
    • we recommend you setup an IRC bouncer: https://wiki.openstack.org/wiki/IRC
  • Email
    • Use the [nova] tag in the mailing lists
    • Filtering on [nova] and [all] can help tame the list
  • Be Open
    • i.e. don't review your teams code in private, do it publicly in gerrit
    • i.e. be ready to talk about openly about problems you are having, not "theoretical" issues
    • that way you can start to gain the trust of the wider community
  • Got a problem? Please ask!
    • Please raise any problems and ask questions early
    • we want to help you before you are frustrated or annoyed
    • unsure who to ask? Just ask in IRC, or check out the list of Nova people
  • Talk about problems first, then solutions
    • Nova is a big project. At first, it can be hard to see the big picture
    • Don't think about "merging your patch", instead think about "solving your problem"
    • conversations are more productive that way
  • Its not the decision thats important, its the reason behind it thats important
    • Don't like the way the community is going?
    • Please ask why we ware going that way, and please engage with the debate
    • If you don't, we are unable to learn from what you have to offer
  • No one will decide, this is stuck, who can help me?
    • its rare, but it happens
    • its the Nova PTL's job to help you
    • ...but if you don't ask, its hard for them to help you

Process

It can feel like you are faced with a wall of process. We are a big community, to make sure the right communication happens, we do use a minimal amount of process.

If you find something that doesn't make sense, please:

  • ask questions to find out *why* it happens
  • if you know of a better way to do it, please speak up
  • one "better way" might be to remove the process if it no longer helps

Why bother with any process?

Why is it worth creating a bug or blueprint to track your code review? This may seem like silly process, but there is usually a good reason behind it.

We have lots of code to review, and we have tools to try and get to really important code reviews first. If yours is really important, but not picked up by our tools, its possible you just get lost in the bottom of a big queue.

If you have a bug fix, you have done loads of work to identify the issue, and test out your fix, and submit it. By adding a bug report, you are making it easier for other folks who hit the same problem to find your work, possibly saving them the hours of pain you went through. With any luck that gives all those people the time to fix different bugs, all that might have affected you, if you had not given them the time go fix it.

Its similar with blueprints. You have worked out how to scratch your itch, lets tell others about that great new feature you have added, so they can use that. Also, it stops someone with a similar idea going through all the pain of creating a feature only to find you already have that feature ready and up for review, or merged into the latest release.

Hopefully this gives you an idea why we have applied a small layer of process to what we are doing. Having said all this, we need to unlearn old habits to move forward, there may be better ways to do things, and we are open to trying them. Please help be part of the solution.

How do I become nova-core?

You don't have to be nova-core to be a valued member of the Nova community. There are many, many ways you can help. Every quality review that helps someone get their patch closer to being ready to merge helps everyone get their code merged faster.

The first step to becoming nova-core is learning how to be an active member of the Nova community, including learning how to do great code reviews. For more details see Nova/CoreTeam#Membership_Expectations

If you feel like you have the time to commit to all the nova-core membership expectations, reach out the Nova PTL who will be able to find you an existing member of nova-core to help mentor you. If all goes well, and you seem like a good candidate, your mentor will contact the rest of the nova-core team to ask them to start looking at your reviews, so they are able to vote for you, if you get nominated for join nova-core.

We encourage all mentoring, where possible, to occur on #openstack-nova so everyone can learn and benefit from your discussions.

The above mentoring is available to every one who wants to learn how to better code reviews, even if you don't ever want to commit to becoming nova-core. If you already have a mentor, that's great, the process is only there for folks who are still trying to find a mentor. Being admitted to the mentoring program no way guarantees you will become a member of nova-core eventually, its here to help you improve, and help you have the sort of involvement and conversations that can lead to becoming a member of nova-core.

How to do great code reviews?

http://docs.openstack.org/infra/manual/developers.html#peer-review

There are some great set of tips in the above link. In addition to this, there are various facets to a code review. It's better to follow a rough set of steps if you are starting up for the first time:

1. Try to pick up an area based on your interest. Comments on syntactical changes are important as much as knowing a given domain is.

2. Look out for test coverage of the production code. We would want to ensure that we achieve near 100% Unit Test coverage.

3. Getting into the middle of a review with 50 odd patches which have been already reviewed, could be tricky at the start.

4. Look at the overall aspect of the fix - whether it impacts any upgrade scenarios, whether it aligns with the goal of the functional area, or if it has a DocImpact/APIImpact.

How to do great nova-spec reviews?

http://specs.openstack.org/openstack/nova-specs/specs/liberty/template.html

http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html#when-is-a-blueprint-needed

More details coming soon...

How to do great bug triage?

https://wiki.openstack.org/wiki/Nova/BugTriage

More details coming soon...

How to step up into a project leadership role?

There are many ways to help lead the Nova project: