Browse Source

Update contributor guide for Queens

Change-Id: Ia72ffc571041000deeea31229438c434005a5515
Takashi NATSUME 4 years ago
  1. 8
  2. 22


@ -56,7 +56,7 @@ you don't understand. It's also OK to see some potential problems but put a +0.
Another way is to look for a subteam you'd like to get involved with and review
their patches. See:
Once you're ready to write code, take a look at some of the work already marked
as low-hanging fruit:
@ -264,7 +264,7 @@ reviews:
- Where do I start? What should I review?
- There are various tools, but a good place to start is:
- Depending on the time in the cycle, it's worth looking at
NeedsCodeReview blueprints:
@ -326,9 +326,9 @@ becoming a member of nova-core.
How to do great nova-spec reviews?
Spec reviews are always a step ahead of the normal code reviews. Follow
the above links for some great information on specs/reviews.


@ -36,8 +36,8 @@ If you are new to Nova, please read this first: :ref:`getting_involved`.
Dates overview
For Pike, please see:
For Queens, please see:
.. note: Throughout this document any link which references the name of a
release cycle in the link can usually be changed to the name of the
@ -98,10 +98,10 @@ Why we have a Spec Freeze:
bounding is a useful way to limit the number of submissions
By the freeze date, we expect all blueprints that will be approved for the
cycle to be listed on launchpad and all relevant specs to be merged. For Pike,
blueprints can be found at and
specs at
cycle to be listed on launchpad and all relevant specs to be merged.
For Queens, blueprints can be found at and specs at
Starting with Liberty, we are keeping a backlog open for submission at all
times. Note: the focus is on accepting and agreeing problem statements
@ -125,7 +125,7 @@ Non-priority Feature Freeze
This is a Nova specific process.
This only applies to low priority blueprints in this list:
We currently have a very finite amount of review bandwidth. In order to
make code review time for the agreed community wide priorities, we have
@ -151,7 +151,7 @@
Exception process:
- Please add request in here:
(ideally with core reviewers to sponsor your patch, normally the
folks who have already viewed those patches)
- make sure you make your request before the end of the feature freeze
@ -219,7 +219,7 @@ When do I need a blueprint vs a spec?
For more details see:
To understand this question, we need to understand why blueprints and
specs are useful.
@ -376,7 +376,7 @@ For blueprint and spec features, do everything for blueprint-only
features and also:
- If it's a project or subteam priority, add it to:
- Ensure your spec is approved for the current release cycle.
If your code is a project or subteam priority, the cores interested in
@ -782,7 +782,7 @@ get, and increase the velocity of getting code merged.
The first part is for subgroups to show they can do a great job of
recommending patches. This is starting in here:
Ideally this would be done with gerrit user "tags" rather than an
etherpad. There are some investigations by sdague in how feasible it