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.
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.
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!
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.
What I Learned
Reviews are Important
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.
Development Happens in Cycles
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.
Be the Change
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.
Where to Find a Team's Priorities
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.
Non-priority Items are Important Too
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.
What Could Be Improved
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].
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.
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.
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.
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.
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.
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.
What Was Good
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.
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.
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.
In general, everyone was so friendly and I'm really looking forward to the Nova Mid cycle.
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.
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.
In general, everyone was so friendly and I'm really looking forward to the Nova Mid cycle.
Final Thoughts
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.
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.
[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, Conversational Style, or here's the short version on Wikipedia.
