Jump to: navigation, search

Difference between revisions of "Nova/Mentoring"

(What should I work on?)
(Work Items for New Contributors)
 
(44 intermediate revisions by 6 users not shown)
Line 1: Line 1:
So you want to give more involved with Nova? Or you are new to Nova and wondering where to start?
+
=== How to Get Involved ===
 +
As the involvement process is pretty consistent, we've moved that information to the [http://docs.openstack.org/developer/nova/how_to_get_involved.html Developer Reference Guide]. This page covers more in-flux items like who to contact and a rotating list of tasks that are good for new contributors.
  
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.
+
Nova is a huge project with a lot going on, so don't expect to grok everything. You should pick a few areas to focus on while you're learning the lay of the land, or you'll get overwhelmed pretty quickly.
  
Any questions, please ask! If you are unsure who to ask, then please contact the [[Nova#People|Mentoring Czar]].
+
==== Team Priorities ====
 +
The team priorities are documented per cycle at http://specs.openstack.org/openstack/nova-specs/#priorities
  
[[Category:Compute]]
+
==== Attend the Nova Team Meeting ====
__TOC__
+
The Nova team has weekly meetings at alternating times to accomodate different time zones. Attend this meeting, or read the logs to stay up to date. Work items often come up that you can volunteer to take on, or at least offer to help the person who has volunteered for it.
  
== How do I get started? ==
+
The Nova meeting agenda and links to past meetings are posted at https://wiki.openstack.org/wiki/Meetings/Nova
  
There are quite a few global docs on this:
+
==== Join a Subteam ====
* http://www.openstack.org/assets/welcome-guide/OpenStackWelcomeGuide.pdf
+
Nova is a big project and we have several subteams that are focused on specific efforts. Each of these subteams has a weekly meeting. If you are interested in getting involved with a subteam you can either attend the weekly meeting or keep up with the meeting logs if the time is inconvenient for you. During these meetings, subteams might mention tasks they need done and if the task isn't ideal for a new contributor, you may be able to pair with a current contributor who can delegate work to you. You can also offer to help someone out with documentation or test coverage, for instance.
* https://wiki.openstack.org/wiki/How_To_Contribute
 
* http://www.openstack.org/community/
 
  
 +
Each subteam has a primary organizer. If you can't attend a subteam's meeting to introduce yourself, reach out to the subteam's organizer or a member of the subteam working on the thing you are interested in, and introduce yourself to them.
  
There is more general info, non Nova specific info here:
+
The list of subteams is posted at https://wiki.openstack.org/wiki/Nova#Active_Sub-teams
* https://wiki.openstack.org/wiki/Mentors
 
* https://wiki.openstack.org/wiki/OpenStack_Upstream_Training
 
  
=== What should I work on? ===
+
==== Subteam Patches and Bugs ====
 +
Subteams are encouraged to use this etherpad to highlight their priority patches and bugs for review: https://etherpad.openstack.org/p/stein-nova-subteam-tracking
  
So you are starting out your Nova journey, where is a good place to start?
+
==== Attend the [https://www.openstack.org/ptg Project Teams Gathering] or [https://wiki.openstack.org/wiki/Forum Summit Forum] ====
 +
Meeting the other contributors face to face is really helpful. Even if you are just starting out, being present during the discussions can provide a lot of context. Try to review items that are published in the agenda for these meetings beforehand so you have some context prior to going in. During the meetings, take really good notes and ask clarifying questions outside of the main discussion. After the meeting, summarize the keys issues in your notes so you can follow subsequent discussions. Pick some areas to follow reviews on and even if you don't feel comfortable contributing a +1, make sure you at least understand the proposal or the code change itself.
  
Bugs are a great way to cut your Nova teeth:
+
=== Who to Contact ===
https://bugs.launchpad.net/nova/+bugs?field.tag=low-hanging-fruit
+
If you have questions about the information on this page, please feel free to reach out to the [https://wiki.openstack.org/wiki/Nova#People PTL] on IRC in the #openstack-nova channel.
  
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 :
+
==== IRC ====
https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking L56 and below
+
Although people show as logged in on IRC they may not be available. When reaching out, you can either mention the person by name in the #openstack-nova channel or message them directly. When messaging in the #openstack-nova channel, please just mention the person's name and then ask your question. There is no need to do "hi" or "hello" to get their attention. If they do not answer right away, this gives others present the opportunity to assist you. If the person does not respond, you can message them directly and sometimes that will indicate their away status. If you still do not continue to get a response, then email them with your question.
  
We also have a list of low hanging fruit work available: https://etherpad.openstack.org/p/nova-low-hanging-fruit
+
==== Email ====
 +
When emailing with questions about joining the team, the PTL can most easily assist you if you provide the following information:
 +
* What topic areas most interest you about Nova
 +
* Areas in Nova where you are most interested in contributing
 +
* Any other OpenStack contribution experience
 +
* Any other Open Source project experience (or if you don't have any, then please mention that)
 +
* Would this be volunteer work or is this part of a job expectation from your employer (ie, were you hired specifically to work on OpenStack or Nova as a developer?)
  
=== How do I get my feature in? ===
+
This is not a job application and you don't have to impress anyone. This information is just to assist in identifying project areas in the team that might be a good fit for your interests and experience.
  
The best way of getting your feature in is... well it depends.
+
=== Work Items for New Contributors ===
 +
The following is a list of areas with projects ideal for new contributors to participate in.
  
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.
+
==== Fixing Bugs ====
 +
While working on bugs is a normally a good way to get to know a new code base, that can be really tricky in Nova. Randomly submitting patches for bugs without talking to anyone is probably the least effective way to contribute to Nova. Always introduce yourself to the Nova team on IRC in #openstack-nova and ask about a bug before working on it.
  
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.
+
===== Picking up a Bug =====
 +
If you find a bug you want to work on, first ask in the #openstack-nova channel before assigning it to yourself. This serves a few purposes:
 +
* Introduces you to the team
 +
* Announces your intent to work on a bug, so others won't work on it
 +
* Allows you to get context so your change is more likely to get approved
  
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.
+
You can assign yourself the bug in 2 ways: 1) manually assign it in Launchpad or 2) submit a change referencing the bug ("Closes-Bug: 1234")
  
For more details on our process, please see: https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#How_do_I_get_my_code_merged.3F
+
When you assign a bug to yourself in Launchpad, you have 2 weeks to submit a patch before you will be unassigned.
  
=== What is expected of a good contributor? ===
+
===== Recommended Tags =====
 +
We use Launchpad as our bug tracker and bugs that have been verified are tagged to categorize them.
  
TODO - need more info on this
+
Here is a list of tags with bugs that might be good for new contributors:
 +
* needs-functional-test: https://bugs.launchpad.net/nova/+bugs?field.tag=needs-functional-test
 +
* api-ref: https://bugs.launchpad.net/nova/+bugs?field.tag=api-ref
 +
* doc: https://bugs.launchpad.net/nova/+bugs?field.tag=doc
 +
* testing: https://bugs.launchpad.net/nova/+bugs?field.tag=testing
 +
* api: https://bugs.launchpad.net/nova/+bugs?field.tag=api
  
== Top Tips for working with the Nova community ==
+
===== Low-Hanging-Fruit =====
 +
Bugs tagged with "Low Hanging Fruit"  are not usually good for new contributors. Try to use one of the tags above instead.
 +
A list of low hanging fruit bugs is available here, if you're looking for something more advanced: https://bugs.launchpad.net/nova/+bugs?field.tag=low-hanging-fruit
  
Here are some top tips around engaging with the Nova community:
+
===== Reviews looking for owners =====
* 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|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#people|Nova PTL]]'s job to help you
 
** ...but if you don't ask, its hard for them to help you
 
  
== Process ==
+
There is an etherpad for reviews looking for new owners: https://etherpad.openstack.org/p/nova-reviews-looking-for-owner. This is a list of reviews that have had un-addressed feedback for a long time and look to be abandoned by their original owners. They have a good chance of merging if someone takes them over.
 
 
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
 
 
 
 
 
To learn more about Nova's process, please read this:
 
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule
 
 
 
=== 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.
 
 
 
== Why do code reviews if I am not in nova-core? ==
 
 
 
Code reviews are the life blood of the Nova developer community.
 
 
 
There is a good discussion on how you do good reviews, and how anyone can be a reviewer:
 
http://docs.openstack.org/infra/manual/developers.html#peer-review
 
 
 
In the draft process guide, I discuss how doing reviews can help get your code merged faster:
 
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#How_can_I_get_my_code_merged_faster.3F
 
 
 
Lets look at some of the top reasons why participating with code reviews really helps you:
 
* Doing more reviews, and seeing what other reviewers notice, will help you better understand what is expected of code that gets merged into master
 
* Having more non-core people do great reviews, leaves less review work for the core reviewers to do, so we are able get more code merged
 
* Empathy is one of the keys to a happy community. If you are used to doing code reviews, you will better understand the comments you get when people review your code. As you do more code reviews, and see what others notice, you will get a better idea of what people are looking for when then apply a +2 to your code.
 
* TODO - needs more detail
 
 
 
 
 
What are the most useful types of code review comments? Well here are a few to the top ones:
 
* Fundamental flaws are the biggest thing to spot. Does the patch break a whole set of existing users, or an existing feature?
 
* Consistency of behaviour is really important. Does this bit of code do things differently to where similar things happen else where in Nova?
 
* Is the code easy to maintain, well tested and easy to read? Code is read order of magnitude times more than it is written, so optimise for the reader of the code, not the writer.
 
* TODO - what others should go here?
 
 
 
 
 
Lets look at some problems people hit when starting out doing code reviews:
 
* My +1 doesn't mean anything, why should I bother?
 
** So your +1 really does help. Some really useful -1 votes that lead to a +1 vote helps get code into a position
 
* When to use -1 vs 0 vs +1
 
** Please see the guidelines here: http://docs.openstack.org/infra/manual/developers.html#peer-review
 
* I have already reviewed this code internally, no point in adding a +1 externally?
 
** Please talk to your company about doing all code reviews in the public, that is a much better way to get involved. showing how the code has evolved upstream, is much better than trying to 'perfect' code internally, before uploading for public review. You can use Draft mode, and mark things as WIP if you prefer, but please do the reviews upstream.
 
* Where do I start? What should I review?
 
** There are various tools, but a good place to start is: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
 
** Depending on the time in the cycle, its worth looking at NeedsCodeReview blueprints: https://blueprints.launchpad.net/nova/liberty
 
** Maybe take a look at things you want to see merged, bug fixes and features, or little code fixes
 
** Look for things that have been waiting a long time for a review: http://5885fef486164bb8596d-41634d3e64ee11f37e8658ed1b4d12ec.r44.cf3.rackcdn.com/nova-openreviews.html
 
** If you get through the above lists, try other tools, such as: http://status.openstack.org/reviews
 
* TODO - I think there is more to add here
 
 
 
== How to do great code reviews? ==
 
 
 
http://docs.openstack.org/infra/manual/developers.html#peer-review
 
 
 
For more tips, please see: https://wiki.openstack.org/wiki/Nova/Mentoring#Why_do_code_reviews_if_I_am_not_in_nova-core.3F
 
 
 
== 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|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 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
 
 
 
Spec reviews are always a step ahead of the normal code reviews. Follow the above links for some great information on specs/reviews.
 
 
 
The following could be some important tips:
 
 
 
1. The specs are published as html documents. Ensure that the author has a proper render of the same via the .rst file.
 
 
 
2. More often than not, it's important to know that there are no overlaps across multiple specs.
 
 
 
3. Ensure that a proper dependency of the spec is identified. For example - a user desired feature that requires a proper base enablement should be a dependent
 
spec.
 
 
 
4. Ask for clarity on changes that appear ambiguous to you.
 
 
 
5. Every release nova gets a huge set of spec proposals and that's a huge task for the limited set of nova cores to complete. Helping the cores with additional
 
reviews is always a great thing.
 
 
 
== 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:
 
* Consider leading and existing [[Nova#Nova_subteams|Nova sub team]] or creating a new [[Nova#Nova_subteams|Nova sub team]]?
 
* Consider becoming a [[Nova/BugTriage#Step_2:_Triage_Tagged_Bugs|Bug tag owner]]
 
* Contact the PTL about becoming a [[Nova#People|Czar]].
 

Latest revision as of 15:09, 13 June 2019

How to Get Involved

As the involvement process is pretty consistent, we've moved that information to the Developer Reference Guide. This page covers more in-flux items like who to contact and a rotating list of tasks that are good for new contributors.

Nova is a huge project with a lot going on, so don't expect to grok everything. You should pick a few areas to focus on while you're learning the lay of the land, or you'll get overwhelmed pretty quickly.

Team Priorities

The team priorities are documented per cycle at http://specs.openstack.org/openstack/nova-specs/#priorities

Attend the Nova Team Meeting

The Nova team has weekly meetings at alternating times to accomodate different time zones. Attend this meeting, or read the logs to stay up to date. Work items often come up that you can volunteer to take on, or at least offer to help the person who has volunteered for it.

The Nova meeting agenda and links to past meetings are posted at https://wiki.openstack.org/wiki/Meetings/Nova

Join a Subteam

Nova is a big project and we have several subteams that are focused on specific efforts. Each of these subteams has a weekly meeting. If you are interested in getting involved with a subteam you can either attend the weekly meeting or keep up with the meeting logs if the time is inconvenient for you. During these meetings, subteams might mention tasks they need done and if the task isn't ideal for a new contributor, you may be able to pair with a current contributor who can delegate work to you. You can also offer to help someone out with documentation or test coverage, for instance.

Each subteam has a primary organizer. If you can't attend a subteam's meeting to introduce yourself, reach out to the subteam's organizer or a member of the subteam working on the thing you are interested in, and introduce yourself to them.

The list of subteams is posted at https://wiki.openstack.org/wiki/Nova#Active_Sub-teams

Subteam Patches and Bugs

Subteams are encouraged to use this etherpad to highlight their priority patches and bugs for review: https://etherpad.openstack.org/p/stein-nova-subteam-tracking

Attend the Project Teams Gathering or Summit Forum

Meeting the other contributors face to face is really helpful. Even if you are just starting out, being present during the discussions can provide a lot of context. Try to review items that are published in the agenda for these meetings beforehand so you have some context prior to going in. During the meetings, take really good notes and ask clarifying questions outside of the main discussion. After the meeting, summarize the keys issues in your notes so you can follow subsequent discussions. Pick some areas to follow reviews on and even if you don't feel comfortable contributing a +1, make sure you at least understand the proposal or the code change itself.

Who to Contact

If you have questions about the information on this page, please feel free to reach out to the PTL on IRC in the #openstack-nova channel.

IRC

Although people show as logged in on IRC they may not be available. When reaching out, you can either mention the person by name in the #openstack-nova channel or message them directly. When messaging in the #openstack-nova channel, please just mention the person's name and then ask your question. There is no need to do "hi" or "hello" to get their attention. If they do not answer right away, this gives others present the opportunity to assist you. If the person does not respond, you can message them directly and sometimes that will indicate their away status. If you still do not continue to get a response, then email them with your question.

Email

When emailing with questions about joining the team, the PTL can most easily assist you if you provide the following information:

  • What topic areas most interest you about Nova
  • Areas in Nova where you are most interested in contributing
  • Any other OpenStack contribution experience
  • Any other Open Source project experience (or if you don't have any, then please mention that)
  • Would this be volunteer work or is this part of a job expectation from your employer (ie, were you hired specifically to work on OpenStack or Nova as a developer?)

This is not a job application and you don't have to impress anyone. This information is just to assist in identifying project areas in the team that might be a good fit for your interests and experience.

Work Items for New Contributors

The following is a list of areas with projects ideal for new contributors to participate in.

Fixing Bugs

While working on bugs is a normally a good way to get to know a new code base, that can be really tricky in Nova. Randomly submitting patches for bugs without talking to anyone is probably the least effective way to contribute to Nova. Always introduce yourself to the Nova team on IRC in #openstack-nova and ask about a bug before working on it.

Picking up a Bug

If you find a bug you want to work on, first ask in the #openstack-nova channel before assigning it to yourself. This serves a few purposes:

  • Introduces you to the team
  • Announces your intent to work on a bug, so others won't work on it
  • Allows you to get context so your change is more likely to get approved

You can assign yourself the bug in 2 ways: 1) manually assign it in Launchpad or 2) submit a change referencing the bug ("Closes-Bug: 1234")

When you assign a bug to yourself in Launchpad, you have 2 weeks to submit a patch before you will be unassigned.

Recommended Tags

We use Launchpad as our bug tracker and bugs that have been verified are tagged to categorize them.

Here is a list of tags with bugs that might be good for new contributors:

Low-Hanging-Fruit

Bugs tagged with "Low Hanging Fruit" are not usually good for new contributors. Try to use one of the tags above instead. A list of low hanging fruit bugs is available here, if you're looking for something more advanced: https://bugs.launchpad.net/nova/+bugs?field.tag=low-hanging-fruit

Reviews looking for owners

There is an etherpad for reviews looking for new owners: https://etherpad.openstack.org/p/nova-reviews-looking-for-owner. This is a list of reviews that have had un-addressed feedback for a long time and look to be abandoned by their original owners. They have a good chance of merging if someone takes them over.