tag:blogger.com,1999:blog-36935022314915182392024-03-15T22:11:45.330-07:00Hack Hack BlogHacking on Code, Food, Crafts, and LifeAugustinahttp://www.blogger.com/profile/01417588491825885974noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-3693502231491518239.post-30571397444175693962016-03-23T16:15:00.000-07:002016-03-23T16:15:00.358-07:00My First Nova MidcycleThe Mitaka Nova Midcycle was held in Bristol, U.K. on January 29-31. I will not be discussing so much of the technical aspects but the experience of the Midcycle from the perspective of a new contributor.<br />
<br />
The Midcycle meetings happen in between the larger OpenStack Summits. The Summits happen every 6 months, so the Midcycles happen every 6 months as well. While generally they are based in the U.S., occasionally they take place outside of the U.S. as in this case. When you work on an OpenStack project team, you should expect to have opportunities to meet and interact with your team mates every 3 months. This is really key for teams who span the globe and who have some members that may never be online at the same time. Face time also is important for providing a personal connection and context among team members, which I believe leads to a deeper emotional investment in the project. This pattern may have originated with the Canonical community, which is where many OpenStack folks came from.<br />
<br />
Anyone can attend the Midcycles, they are public and open. In fact, I'd highly encourage anyone who is interested in getting more involved with a particular team or project to consider attending. These are, however, fast paced working sessions, so don't expect a lot of context or explanation. It is easy enough to prepare for the Midcycle and get context. I'd argue that even members of the team that have been focused on their own projects might benefit from such preparation as well.<br />
<br />
Here are some tips for preparing for the Midcycle (or Design Summit for that matter):<br />
1. Read the priorities document for the current cycle (usually located in an Etherpad, ask in irc)<br />
2. Read over the reviews listed on the priorities document<br />
3. Read the mailing list, particularly paying attention to discussions around high priority items<br />
4. Review recent IRC meeting logs for team and subteam meetings around priority items.<br />
<br />
Following these tips will ensure you're up to speed on discussions around things you might not have been particularly focused on, specifically so you can follow the context of the discussions. Note that people are nice and if you ask they will usually explain things. You want to avoid interrupting the whole group discussion however as there is limited time at these meetings and many of your questions can be answered during breaks.<br />
<br />
The format for the Midcycle was loosely structured. We had an agenda in an Etherpad with topics to discuss, and people took notes on those topics and items were decided, or follow up items were identified and assigned. Anyone could add an item to the Etherpad. The sessions started at 9:30am and ended around 5pm with several short breaks and an hour lunch break in between. Thursday was more of an unconference/open hack day where people just worked on various items and took the opportunity to pair with each other or to discuss things.<br />
<br />
Overall I'd say the Midcycle was an incredibly positive experience. It gives project team members the opportunity to interact outside of the madness of the larger Summit. A key importance of the Midcycle is reinforcing a social bond. The group was friendly and inclusive, going out for dinner and drinks together each evening. Anyone was invited to join but our group tended to stay around 15-20. Many of the Midcycle attendees were locals who had lives and families to attend to. Others were just less interested in the social aspect for their own reasons.<br />
<br />
I originally attended the Nova sessions during the Design Summit. This was my first time meeting many folks on the Nova team and I admit I was incredibly shy. This was my second time meeting many of the Nova folks including some who hadn't been at the summit. At the time of the Mitaka Midcycle, I had been working on Nova for 4 months, participating in both IRC discussions and the mailing list. This time when I introduced myself to people they had some idea of who I was and what I was working on.<br />
<br />
I'm looking forward to seeing everyone again at the Newton Design Summit in April!<br />
<br />Augustinahttp://www.blogger.com/profile/01417588491825885974noreply@blogger.com3tag:blogger.com,1999:blog-3693502231491518239.post-11456619617263818582015-12-15T16:23:00.000-08:002015-12-29T16:03:05.146-08:00My First OpenStack Summit: Tokyo 2015In October I attended my first OpenStack Summit. It's taken me awhile to digest and reflect on my experiences hence this article being published over a month after I got back!<br />
<br />
I'm not new to tech conferences or contributing to OpenSource, so much of the "Summit 101" stuff didn't really apply to me. That being said, it's worth noting that the OpenStack Summit has essentially 2 tracks, one for users that's more marketing focused, and one for contributors that's more developer or operations focused. I spent pretty much all of my time in the Developer Summit, so I can't speak to the other sessions.<br />
<br />
I think the most important thing to remember when attending something like an OpenStack Summit is you need to have something to focus on if you want to get anything out of it. Sure you can float around and fly by the seat of your pants, but at least I'm the type of person that finds it hard to really ingest things unless I have some kind of context or goal to fit it into.<br />
<br />
As a developer, I was hired by my current employer to work on OpenStack Infrastructure upstream projects. After some limited involvement with the Infrastructure team, I started getting involved with Nova (aka Compute). This is largely because I'm more of a traditional Software Engineer and generally found the Nova team to be a better fit for my work style and interests. I feel pretty lucky to be in a work setting where making this kind of transition is so easy compared to other places I've worked! So I guess the first piece of advice I have, if you're hired to work on anything, whether it's upstream on an OpenSource project or on internal proprietary things, if something else catches your interest and seems more relevant to your interests than whatever it is you're currently working on, then definitely look for opportunities to change your focus!<br />
<br />
Going into the Design Summit, I had just started working on Nova about 2 weeks prior. My goal for the Summit was to gain as much context as possible, and to meet with my new team members face to face.<br />
<div>
<br /></div>
<div>
<h3>
What I Learned</h3>
</div>
<div>
<br /></div>
<div>
<h4>
Reviews are Important</h4>
<div>
Even if your goal isn't to become a core member on a project, participating in the review process is really vital to keeping up with what's going on in the project. When you review someone's patch, you have to look at code you might not normally look at and learn how it works in order to provide useful feedback. Reviews help you to understand the code base and to participate in the project. In the long term, if you regularly do useful reviews, you might even be considered for a core role on the project (which could be good or bad depending on how much time you have to spend on the project haha)! I'll write an article that's more in depth on doing reviews.<br />
<br /></div>
</div>
<div>
<h4>
Development Happens in Cycles</h4>
</div>
<div>
Development typically happens in 6 month cycles with milestones identified by the PTL or other core members. This can include a cut off date for proposed specifications and cut off dates for releases. Additionally sometimes there are special sprints for things like bugs and documentation. Teams typically announce this on the mailing list and may link to an etherpad or two with this information.</div>
<div>
<br /></div>
<div>
<h4>
Be the Change</h4>
</div>
<div>
The number one thing I heard repeated during these sessions was "propose a spec and we'll discuss it". If you have an issue and you want it to be a priority, the number one way to get the most out of your face time with the development team is to propose a specification for it. Don't plan on having a presentation with slides or a demonstration as media equipment and switching laptops could be tricky. Have an etherpad ready and have links to a blueprint in launchpad and a spec in review.openstack.org. Even if they are in a draft state, it's an artifact people can look at while you're talking about your thing. Finally, expect to do the work for your change. If you can't do it, then do your best to stir up interest before you present the idea.</div>
<div>
<br /></div>
<div>
<h4>
Where to Find a Team's Priorities</h4>
</div>
<div>
Priorities are the most important items that need to be completed in the next cycle. The goal of the developer sessions in the summit is to discuss issues that are being proposed and determine if they are a priority. If they are not deemed a priority, they can still make it into a release if they have sponsorship, but priorities are going to get the most attention from team members. The team typically provides a link to their priorities list etherpad on the mailing list but you can also find it during sessions. During the last day of the summit, this priority list becomes the agenda as items discussed during the week are revisited.<br />
<br /></div>
<div>
<h4>
Non-priority Items are Important Too</h4>
</div>
<div>
As mentioned before, just because something isn't a priority, it can still get attention and make it into a release. If you are willing to champion the issue and get the work done, the only challenge will be getting core attention to push it through to release. In the worst case scenario, you get all the work done and you don't get the attention you need to get it approved and landed. In that case, you just have to wait until the next summit and pitch it again, reminding everyone that the work is done. The summit will also be a good place to get some face time with core members that can provide feedback that might be more challenging to get remotely with barriers like time zones.<br />
<br /></div>
<div>
<h3>
What Could Be Improved</h3>
</div>
<div>
<br /></div>
<div>
I think the biggest thing that could be improved about the developer summit format is the way communication is facilitated. I was very fortunate and spent most of my sessions with a team that has a PTL who is clearly experienced as a facilitator. Unfortunately that is not true for many of the teams and it creates a very frustrating experience for people whose communication styles do not match an extroverted "high involvement" type but follow a more introverted "high politeness" type [1].<br />
<br />
Basically the PTL pulls up an etherpad with a list of items to discuss. People in the room talk when they want to. Some people tried raising their hands to signal they had something to say and in some cases when the discussion got very involved, were passed over. Or worse, when they did get the chance to speak, they were cut off before they could finish. While this happened less frequently in some sessions than in others, it happened more frequently than it should have. Many valuable insights and opinions were basically lost.<br />
<br />
The most difficult situations happened when people didn't agree on something. I saw some rude behavior that I found rather surprising. Many of us are working for companies who are paying us to be involved in these projects and we are, however indirectly, representing that company. Making backhanded comebacks might make you feel good about yourself in the moment but ultimately it kills discussion and prevents people from listening. I saw this mainly with cross-team discussions where clearly there was some history, but I did see it in at least one team discussion. It's less important for a person to be *right* than it is for the group to come to a good decision about a thing. At the end of the day no one remembers if someone was right or wrong, we remember what was ultimately decided and go on with our business. People do, however, remember if you were a jerk.<br />
<br />
I think some kind of group communication 101 and communication guidelines would be really valuable for both participants and PTL's. Additionally, facilitation training for PTL's and other moderators would help to improve the overall discussion flow a lot. This still surprises me in many industries but in tech especially how we not only tolerate antisocial behavior, but practically celebrate it. A person can be smart and be making valuable contributions but if they are driving away contributors, that's a net loss. Engineers tend to be focused on developing technical skills, not social ones. There are a lot of social basics that we don't seem to possess and this is a problem across the industry, not just in OpenStack.<br />
<br /></div>
<div>
<h3>
What Was Good</h3>
</div>
<div>
<br /></div>
<div>
Everyone I met on the Nova team was super nice and fantastic. I felt as a team they were very welcoming and their sessions were some of the best facilitated that I attended. I actually shared my anxiety about participating in discussions with the PTL. He was very nice about it, admitting he'd felt the same way when he started and was overall very encouraging. Another core contributor I've been working with made a point to call me out when something came up that I'd started helping him with, which also helped to break the ice for me, making it easier for me to introduce myself to others in between sessions.<br />
<br />
I got a ton of context from the Design Summit sessions. I left feeling so much more in touch and in tune with what the community is doing that now when I'm in irc or reading in the mailing list, I have a better idea of what a person is referring to. As a new contributor, I found a couple of things to get involved with and left the summit with a ton of enthusiasm and energy to dive in.<br />
<br />
For me the best thing about the Summit was getting to meet the people, in person, on the team I recently started working. I got to have lunch with a few of them on the last day and I really enjoyed myself.<br />
<br />
In general, everyone was so friendly and I'm really looking forward to the Nova Mid cycle.<br />
<br />
<h3>
Final Thoughts</h3>
<div>
<br /></div>
<div>
I know I ranted a lot about some of the downsides of the Summit, but to be fair, this is not at all unique to the OpenStack community. I don't want to discourage anyone who is thinking about participating, but I don't want people to believe any nonsense from anyone trying to say that OpenStack somehow doesn't have these issues. Everyone has these issues, including every company I've ever worked for. Personally I think the road to improvement is a focus on general inclusiveness rather than targeted demographics. I've provided some ideas on how communication could be improved as a step in that direction and I look forward to seeing how things evolve.</div>
<div>
<br /></div>
<div>
It's truly amazing that companies are seeing the value of Open Source enough to pay people to work on it full time. I'm also amazed that so many employees of so many different companies, representing so many different interests (and nationalities) can come together and work together to build a pretty neat thing that so many people are using! That's a real accomplishment and I'm definitely looking forward to my next Summit.</div>
</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
[1] The labels "High Involvement" and "High Politeness" (aka "High Considerateness") originated with the Sociolinguist Deborah Tannen. You can read a book of her theories, <a href="http://www.amazon.com/Conversational-Style-Analyzing-among-Friends/dp/0195221818" target="_blank">Conversational Style</a>, or <a href="https://en.wikipedia.org/wiki/Deborah_Tannen#Research" target="_blank">here's the short version on Wikipedia</a>.</div>
Augustinahttp://www.blogger.com/profile/01417588491825885974noreply@blogger.comtag:blogger.com,1999:blog-3693502231491518239.post-28492934856396879322015-09-22T13:19:00.000-07:002015-10-07T15:14:09.442-07:00My First OpenStack Infra PatchIn August, I started a new job as an upstream contributor on the OpenStack Infrastructure team! The project is so huge, the average on-boarding time is at least 6 months. My goal for this on-boarding time is to document as much as possible while I still have my "new contributor" perspective. I have been focusing on documentation for various Infra projects, including Nodepool and Disk Image Builder.<br />
<br />
I had my first OpenStack Infrastructure patch merged on September 2nd, 2015! I'd like to share my experiences writing, submitting, and debugging my first patch.<br />
<br />
<h3>
Step 1: Figure out what to patch</h3>
<br />
There's a talk I give about <a href="https://www.youtube.com/watch?v=Ok4MBvWcxOI">how to get started with contributing to the Perl community</a>. Some of the advice I've given there holds true to pretty much any project, but especially any project that is big and overwhelming. Sure, you can submit code as your first patch. For most of us, however, there's a lot of context missing when we interact with a new code-base (and Infra has MANY contexts and code bases). I recommend what I like to call the "Wax-On Wax-Off Paint-the-Fence" approach.<br />
<br />
<i><b>Take on the most ridiculously boring and tedious tasks while you learn how things work.</b></i><br />
<br />
Good examples are things like adding or improving documentation, adding, fixing, or otherwise improving unit tests, or small code tasks like variable or function renames, formatting changes, whitespace cleanup, or logging or other text output format changes. Don't do anything too invasive until you understand how all the pieces fit together. You can't debug a failure if you don't know where to look, and this is especially true for big projects like Infra!<br />
<br />
The team I joined has a policy of assigning an onboarding buddy to new hires. I was lucky to get to work with Greg Haynes. He's done a great job of suggesting tasks like the ones mentioned above that exist in the code bases he's most active in.<br />
<br />
My first patch involved <a href="https://review.openstack.org/#/c/218965/">reformatting text in a README file for one of the elements</a> in <a href="https://review.openstack.org/#/admin/projects/openstack/diskimage-builder">Disk Image Builder</a>. A proposal was made to move this from free text that was all over the place and inconsistent to a formatted table structure with clear items that should be listed for each element. This is a very tedious project and not particularly interesting to someone who is very familiar with the code base. For someone like me, however, it's perfect! So that's my current project, reformatting and improving the documentation for the environment variable overrides in Disk Image Builder's elements.<br />
<br />
If you don't have a buddy to make recommendations, just pop into the #openstack-infra channel in IRC and just ask for suggestions! Alternatively, try the #openstack-doc and #openstack-qa channels.<br />
<br />
<h3>
Step 2: Set Up Gerrit and git-review</h3>
<br />
OpenStack has done an excellent job of documenting the <a href="http://docs.openstack.org/infra/manual/developers.html#getting-started">steps for new developers</a> and I recommend following those instructions after reading some of my notes here. There are more <a href="https://wiki.openstack.org/wiki/Documentation/HowTo/FirstTimers">in-depth instructions</a> provided by the Documentation team for first time contributors that may be a better fit if you don't have a lot of experience contributing to projects!<br />
<br />
OpenStack uses a code review tool called Gerrit hosted at review.openstack.org and uses Ubuntu Single Sign On to manage login credentials. When I joined the Infrastructure team, I already had an Ubuntu Single Sign On account via Launchpad from contributions I'd made to Ubuntu a few years ago.<br />
<br />
Additionally, to contribute to any OpenStack project (including Infra), you'll need to create a community account and sign the agreement. Make sure the email you provide for your OpenStack email address matches your Ubuntu Single Sign On email address! I ran into this issue myself and I've seen it enough that I'll bet it's one of the top new contributor issues! If you have any issues with your OpenStack community account, the first thing to check is that those email addresses match.<br />
<br />
Finally, install git-review on your system. As a side note, for development projects, I generally try to minimize system-wide installs that could affect my entire system. This is especially important when dealing with several projects that may have conflicting version requirements. That being said, git-review is fine to install system-wide, just be aware in the future when some instructions tell you to install something system-wide and think about possible conflicts with any other projects you might be using. See the next section for suggestions on not littering dependencies all over your local file system.<br />
<br />
<h3>
Step 3: Get the Code</h3>
<br />
Infra code, like all OpenStack code, lives in a git repository hosted on git.openstack.org. To find the repository for the project you want to patch, look up the project by name at <a href="http://git.openstack.org/cgit/">git.openstack.org</a> using the Search box at the upper right corner. Copy the “git://” URI to clone the git repo locally.<br />
<br />
For your local dev setup on your local machine, I recommend creating a folder for all of your OpenStack related projects. I have a folder called "dev" in my home directory that contains subfolders for various projects. Under that, I created a folder called openstack where I clone my git repos. For OpenStack infra, you will want to create a separate openstack-infra directory because openstack-infra can have different dependencies than other OpenStack projects. It should use its own virtualenv to manage these dependencies.<br />
<br />
In general you should be using a local Python rather than a system Python. You know if you're using system Python if you have to type "sudo" anytime you want to do anything beyond running a program (like pip). Virtualenv makes doing this really easy. Learn more about using virtualenv <a href="https://virtualenv.pypa.io/en/latest/">here</a>.<br />
<br />
There's another great tool for managing environment variables that's written in bash, called <a href="https://github.com/cxreg/smartcd/">smartcd</a>. It lets you set up custom environment variables on a per directory basis. A lot of OpenStack projects depend on environment variables so having something to customize this without littering your environment is really useful.<br />
<br />
I also recommend that you set up a virtual machine with a <a href="http://docs.openstack.org/developer/devstack/">Devstack</a>. If you're editing docs or unit tests, it's not too big of a deal to run things locally but when you're doing larger code patches, you want to mimic running tools against an OpenStack as much as possible. For the documentation patches I've done, running locally and using a virtualenv has been sufficient.<br />
<br />
<h3>
Step 4: Run the Tests</h3>
<br />
Once you've cloned the git repository, follow the instructions in the README at the parent level to do any necessary local setup. It will likely involve installing a bunch of python dependencies. See the section above for my recommendation involving using virtualenv for this.<br />
<br />
If the project you're working on does not have a README, or the README doesn't mention anything about how to set up the repo, this is definitely an opportunity to add a patch. Every project should have a README and it should contain not only setup information but also bug submission information. These are good first patches as you get to know the infrastructure. <br />
<br />
Some projects are complex, require a lot of setup and possess a huge range of dependencies. If your change doesn’t actually require running the project, don’t get overwhelmed by getting the project up and running in order to submit your first patch. You can easily run a subset of the unit tests locally to verify your change without having to locally test the entire project.<br />
<br />
After configuring and installing, before touching anything else, I highly recommend running the tests to make sure everything works on your system. It's incredibly hard to troubleshoot when you're not sure if your patch broke something or if it was a setup issue that's causing test failures. To run the tests you'll need to set up tox if you haven't already. It's really straightforward (pip install tox), see the <a href="http://docs.openstack.org/infra/manual/python.html">OpenStack Python Developer Docs</a> if you're not sure how.<br />
<br />
The tox.ini file at the parent level of the repo defines the different sections that tox recognizes. So if all you really care about is docs, there should be a section called "docs" and it will be clear in the tox.ini what tests are being run as part of that. If you are only touching a specific subset of things (eg, docs), then don't worry about troubleshooting if the entire test suite fails on your local machine.<br />
<br />
Unit tests can fail for a variety of reasons, including versions of dependent libraries and OS-level conflicts. This is why it’s important to a) use a tool like virtualenv to separate Python language dependencies and b) to use a virtual machine or other container to avoid system level conflicts that are hard to debug.<br />
<br />
<h3>
Step 5: Hack Hack Hack</h3>
<br />
Before you start hacking, you should <a href="http://docs.openstack.org/infra/manual/developers.html#starting-a-change">cut a local branch to commit to</a>. However, if you suspect an upstream conflict is going to be merged while you’re working, you can hack on master without committing, and then cut the branch once you're ready to commit. The advantage of just hacking on master (without committing) is you can easily keep the branch current without dealing with merge conflicts. If you accidentally commit to master, Gerrit won't let you merge when you check in your commit. You’ll need to cut a local branch to submit your code upstream anyway, so it's generally just good practice to work on a local branch.<br />
<br />
<h3>
Step 6: Run the Tests</h3>
<br />
After you're done hack hack hacking, run the tests again to make sure you didn't break anything. Again, only run a subset if that's all you care about. This will just catch anything specific to what you're changing. Jenkins will run the full suite of unit and integration tests once you submit your patch for review.<br />
<br />
<h3>
Step 7: Compose a Commit Message and Rebase</h3>
<br />
Composing a well thought out commit message is important, even for small changes. The typical <a href="http://docs.openstack.org/infra/manual/developers.html#committing-a-change">OpenStack commit style</a> is to do a short description followed by a longer paragraph that provides more context for the change. If the change is really minor, you can get away with a short description. Learn more about writing good commit messages <a href="https://wiki.openstack.org/wiki/GitCommitMessages">here</a>.<br />
<br />
Gerrit will create one review item per commit. If you have multiple commits, you need to rebase them down to one commit. My workflow is to write my real commit message for the first commit and then do short, less descriptive commits for anything subsequent. Once I'm done developing, I do rebase -i HEAD~n where n is the number of commits (inclusive) to rebase. When you do an interactive rebase, you can tell git what you want to do with each of the commits.<br />
<br />
It might be tempting to just constantly rebase your work into one commit to save yourself the trouble. While doing your initial work, I don't recommend this because you might make a mistake that's hard to back out of without your full commit history.<br />
<br />
To keep a remote copy of your branch without having it go through testing, you basically push your change to Gerrit but then mark it as a <a href="http://docs.openstack.org/infra/manual/developers.html#work-in-progress">Work in Progress</a> (WIP) through a workflow comment. Run git review, then open the patch's page in Gerrit. Click Review on your patch and mark it as "-1 WIP". This will let everyone (including Jenkins) know that this patch isn't ready for testing just yet.<br />
<br />
Note that if you want to keep a remote copy of your work in Gerrit, you'll need to rebase it down to one commit. I haven't figured out an alternative solution that keeps the repo in sync with the master branch but lets you have a remote copy of your revision history without creating a bunch of extra patches in Gerrit. When I figure something out I'll be sure to talk about it in a future article.<br />
<br />
<h3>
Step 8: Submit Your Patch</h3>
<br />
Before running git-review, make sure the email address in your git config matches the one you have registered in Gerrit. Just type "git review" to submit your patch. If you want to submit the patch as a work in progress, see the above section about doing a workflow commit.<br />
<br />
Once you’ve submitted your patch for review, the build system will run a huge suite of tests on the remote branch in Gerrit. Pay attention to your emails for the test results from Jenkins. If you need to troubleshoot a failure, do so by looking at the Jenkins console logs. Ask for help in the #openstack-infra IRC channel if you're not sure what something means, and try to provide as much information as possible including a link to the change in question and specific error messages you think are the problem. For longer pastes, use <a href="http://paste.openstack.org/">paste.openstack.org</a> instead of cluttering up the IRC channel. Check if the failed tests are "non-voting" before digging into things. If the tests are "non-voting" their failure doesn't matter with regards to your patch being accepted because they may have known issues.<br />
<br />
If it looks like a fluke, you can re-run the tests by adding a comment with the text "recheck". All automated tests must pass for code to be merged, and typically reviewers won’t even begin reviewing a new patch until the checks have passed.<br />
<br />
<h3>
Step 9: Get Your Patch Reviewed</h3>
<br />
Once the test have passed, you'll need to get your change accepted by 2 core members in order to get it merged. If your patch has been reviewed and says "Needs Workflow" it means another core needs to approve it before it can be merged.<br />
<br />
To find out who the core members are that can +2 or approve your patch, visit the project's page in review.openstack.org. Click on "Access" at the top of the screen and then click on any of the project-core links to see a list of people. You can add names as Reviewers to your change from your change's url or you can ask in #openstack-infra if those individuals could review your change. Not everyone monitors their emails if you just add them as a Reviewer.<br />
<br />
If you get comments and people want you to make changes, generally discussion should happen in Gerrit so there’s some history tied to the change. However, if you’re still uncertain or need more back and forth than Gerrit can offer, feel free to discuss the change publicly in the #openstack-infra IRC channel, or privately with the reviewer on IRC if you’re not yet comfortable speaking in the public channel. Many people in the community are very passionate about wanting the best for OpenStack, and they have strong opinions as a result. If you don't agree with specific feedback because you feel you had good reasons for why you did a thing the way you did, feel free to politely share those reasons. Chances are you'll have a nice discussion and you'll both learn something ;) If for some reason you're not satisfied with the result of the discussion, feel free to seek a second opinion from another core member. It's ok if you get overruled, don't be frustrated. Just try your best to understand why they want it done that way and move on to the next thing. When you're working with groups, sometimes you have to pick your battles. Once you get more established in the community and understand more of the context, you might better understand their reasons or you can be the core person making those decisions. It's all just part of being in a community with other humans :)<br />
<br />
Once your patch has been approved, it will be automatically merged and you'll get an email notification (if you've opted for those)!<br />
<br />
<h3>
Step 10: Do the First Patch Dance!</h3>
<br />
<img src="https://lh3.googleusercontent.com/rqLpJIuNE1jObRVKE0EGRKVMSE2nlp_ofc1CmjVHWQXRs1c2OnP1Tl2FL7pjNB_8YbvlXN91hn30lyRffknQw526XHABSGj7gavpu0oM2KNdwe4G6rrbQjLY6Duk5rk1cw=s1600" /> <br />
<br />
You can watch your progress as an OpenStack contributor at <a href="http://www.stackalytics.com/">Stackalytics</a>!<br />
<br />
<br />
<h3>
Useful Links</h3>
<div>
<ul>
<li>OpenStack Developers' Guide - <a href="http://docs.openstack.org/infra/manual/developers.html">http://docs.openstack.org/infra/manual/developers.html</a></li>
<li>OpenStack Docs Team "First Timers" Guide - <a href="https://wiki.openstack.org/wiki/Documentation/HowTo/FirstTimers">https://wiki.openstack.org/wiki/Documentation/HowTo/FirstTimers</a></li>
<li>Virtualenv - <a href="https://virtualenv.pypa.io/en/latest/">https://virtualenv.pypa.io/en/latest/</a></li>
<li>Smartcd - <a href="https://github.com/cxreg/smartcd/">https://github.com/cxreg/smartcd/</a></li>
<li>OpenStack Git Repositories - <a href="http://git.openstack.org/cgit/">http://git.openstack.org/cgit/</a></li>
<li>DevStack - <a href="http://docs.openstack.org/developer/devstack/">http://docs.openstack.org/developer/devstack/</a></li>
<li>OpenStack Python Developers' Guide - <a href="http://docs.openstack.org/infra/manual/python.html">http://docs.openstack.org/infra/manual/python.html</a></li>
<li>Git Commit Messages - <a href="https://wiki.openstack.org/wiki/GitCommitMessages">https://wiki.openstack.org/wiki/GitCommitMessages</a></li>
<li>Paste - <a href="http://paste.openstack.org/">http://paste.openstack.org</a></li>
<li>Stackalytics - <a href="http://www.stackalytics.com/">http://www.stackalytics.com</a></li>
</ul>
<br />
<br />
<br />
<br />
<br /></div>
Augustinahttp://www.blogger.com/profile/01417588491825885974noreply@blogger.com62