So you want to get more involved with Masakari? Or you are new to Masakari 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 Masakari and how the Masakari community works.
There are quite a few global docs on this:
There is more general info, non Masakari specific info here:
So you are starting out your Masakari journey, where is a good place to start?
If you'd like to learn how Masakari works before changing anything (good idea!), we recommend looking for reviews with -1s and -2s and seeing why they got down voted. Once you have some understanding, start reviewing patches. It's OK to ask people to explain things you don't understand. It's also OK to see some potential problems but put a +0.
Once you're ready to write code, take a look at some of the work already marked as low-hanging fruit:
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. It’s likely things will need significant re-work after you discuss how your needs match up with all the existing ways Masakari is currently being used. The good news, is this process should leave you with a feature that's 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 ongoing efforts are blocking your feature and helping out speeding those up. The spec review process should help with this effort.
For more details on our process, please see:
TODO - need more info on this
Here are some top tips around engaging with the Masakari community:
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:
To learn more about Masakari's process, please read
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, it's 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.
It's 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.
Code reviews are the life blood of the 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:
Let’s look at some of the top reasons why participating with code reviews really helps you:
What are the most useful types of code review comments? Well here are a few to the top ones:
Let's look at some problems people hit when starting out doing code reviews:
For more tips, please see: Why do code reviews if I am not in masakari-core?
You don't have to be masakari-core to be a valued member of the Masakari 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 masakari-core is learning how to be an active member of the Masakari community, including learning how to do great code reviews.
If you feel like you have the time to commit to all the masakari-core membership expectations, reach out to the Masakari PTL who will be able to find you an existing member of masakari-core to help mentor you. If all goes well, and you seem like a good candidate, your mentor will contact the rest of the masakari-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 masakari-core.
We encourage all mentoring, where possible, to occur on #openstack-masakari so everyone can learn and benefit from your discussions.
The above mentoring is available to everyone who wants to learn how to better code reviews, even if you don't ever want to commit to becoming masakari-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 masakari-core eventually, it's here to help you improve, and help you have the sort of involvement and conversations that can lead to becoming a member of masakari-core.