What are PTG Events & Why Sponsor?

The Project Teams Gathering (PTG) is a new biannual event organized by the OpenStack Foundation that will take place in Q1 and Q3 between the OpenStack Summits in Q2 and Q4.

The new PTG events are a product of splitting up the event known as the Design Summit, which will now become (1) the Forum at our biannual Summit (where strategic planning, feedback listening, requirements gathering and cross-community discussions happen) and (2) the PTG events (where the actual development work is being organized.)

The PTG events could be considered a “mega midcycle” gathering for all active project teams. Moving forward the PTG events should replace the need for individual OpenStack projects to organize their own standalone midcycle events between Summits. PTG events aim to maximize the ability of contributors to work through their project objectives in an environment that is focused towards work and productivity.

Getting all team members together throughout the year allows them to build the amount of shared understandings and trust that is necessary to successfully cooperate and achieve team objectives over the next six months.

The PTG events are critically important to the OpenStack release cycle. Sponsoring these events will greatly help ensure the continued growth and success of OpenStack. Contact [email protected] with any questions.

Steps to Sponsoring the PTG event:

Step One: View the PTG Sponsorship Prospectus for an overview of sponsorship benefits.

Step Two: Sign the electronic September 2017 OpenStack Project Teams Gathering Sponsorship Agreement no later than August 1st, 2017.

Please note: If you have not already done so, you will need to first sign the Master Event Sponsorship Agreement with the OpenStack Foundation before you sign the PTG agreement. (Note: If you previously sponsored any of the OpenStack Summits then you've already completed this step. You'll just need to know the date when you signed the Master agreement. You can find the date that you previously signed it here).

Travel

Renaissance Denver Stapleton Hotel
3801 Quebec St, Denver, CO 80207

---

Visa Information

How to apply for a Visa:

If you require a visa letter to travel to United States for the OpenStack Project Teams Gathering please fill out this form.

Before submitting a request, please check here if you country is a part of the Visa Waiver Program. The Visa Waiver Program (VWP) allows citizens of participating countries to travel to the United States without a visa for stays of 90 days or less, when they meet all necessary requirements. You can learn more about the Visa Waiver Program here. If you travel on a passport issued by a country NOT on this list, you will require a Visitor Visa to travel to the United States.

If you are unsure whether you require a visa or not, please visit this page and enter the country that issued your passport and the reason for your trip, and it will tell you what visa to apply for if a visa is required for your travel.

Visa Processing Time:

As a general planning guideline, if a visa is needed, a foreign traveler should apply for his or her visa as soon as possible, preferably no later than 60 days before the travel date.

Processing time for visas vary depending on the office and the time of year. You are encouraged to apply early and to submit complete applications including all supporting documents. For your information, general processing times at the various visa offices are available at the following link http://travel.state.gov/content/visas/en/general/wait-times.html/. For more accurate processing times, please consult the website for the visa office responsible for processing their application.

Deadline to submit Visa Invitation Letter request:

Requests for invitation letters must be received before Friday, August 25, 2017. We will send your visa letter to the email you provide on this form. No hard copies will be sent. Visa invitation letters will be issued within 3 - 5 business days after the request has been submitted.

Apply for Travel Support

Fill in the online form here. Applicants will be notified according to the deadlines below. Deadlines for the Denver PTG:

• Week of June 5, 2017: Initial publication, start collecting applications
• July 2, 2017: Final deadline to submit applications for Round One approvals
• July 7, 2017: Notifications of approved grantees for Round One 
• August 6, 2017: Final deadline to submit applications for Round Two approvals
• August 10, 2017: Notifications of approved grantees for Round Two

Travel Rewards

The grants will cover a combination of flights, accommodation and access pass to the PTG.

Frequently Asked Questions

Q: Why change?

A: In the past, the OpenStack community has published the latest release, hosted the OpenStack Conference for users, and held the Design Summit for contributors to plan the next version—all in the same feverish, two-week timespan. There have been a few problems with this approach. It has been hard on users because there was very little time get acquainted with the new release before the conference. It has been hard for strategic discussions, because they happened too late in the cycle to be taken into account. It has been hard on upstream contributors, torn between the opportunity to reach out beyond their team, and the necessity to get a lot of things down with your team. And it has been hard on downstream companies who are working to build product based on the new releases.

So we’re making adjustments to create time between the OpenStack Conference and the release of the software. Going forward, the releases will happen months before each summit. And a new event will be also held between summits called the Project Teams Gathering (PTG). PTGs will be the new venue for planning, organizing, and kickstarting the work on a new development cycle.

Q: When are those events happening?

A: Project Teams Gatherings happen in Q1 and Q3 of each year. OpenStack Summits happen in Q2 and Q4 of each year. You can see how this plays out in the timeline below.

Q: Attendance to Design Summits used to be free for ATCs. Why do I have to pay to attend the Project Teams Gathering?

A: In the past, the OpenStack Foundation gave discounted Summit passes to a subset of upstream contributors (not all ATCs) who contributed in the last six months, so that they could more easily attend the Summit. Most ATCs retrieved their Summit pass just in case, and an unpredictable portion of them would actually use them to attend. The PTG space is limited, so we charge a base fee in order to increase the chances that people registering will actually show up, optimizing our usage of the space. The funds will also help keep sponsorship presence at the event to a minimum. Anyone who physically attends the Project Teams Gathering will receive a discount code to attend the next Summit, in order to keep costs low for people who will attend both events. At the same time, we are beefing up our Travel Support Program in order to ensure we can get all the needed people at the right events. If the base fee for the PTG registration is an issue, you should consider applying to that program.

Q: Is the PTG a capped event? How did you set expected attendance?

A: This is the first event of this kind. We had to make an educated guess on how many people would show up, to plan space accordingly and keep costs under control. The PTG is targeted to existing project team members, like the team mid-cycle meetups and the Fridays contributors meetups at the Summit. We looked at attendance to those events and similar dev-oriented events in the industry, and settled for 500 people. 500 people represent about 80% of the commits to OpenStack in any given release, and way more people than ever showed up at team mid-cycles.

Q: How is the change helping upstream developers?

A: When everything was held in a single Summit week, upstream developers had a lot of different goals for that week. We leveraged the Summit to communicate new things (give presentations), learn new things (attend presentations), get feedback from users and operators over our last release, gather pain points and priorities for upcoming development, propose changes and see what the community thinks of them, recruit and onboard new team members, have essential cross-project discussions, meet with our existing project team members, kickstart the work on the new cycle, and get things done. There was just not enough time in 4 or 5 days to do all of that, so we usually dropped half of those goals. Most skipped attending presentations. Some abandoned the idea of presenting. Some dropped cross-project discussions, resulting in them not having the critical mass of representation to actually serve their purpose. Some dropped out of their project team meeting to run somewhere else. The time conflicts made us jump between sessions, resulting in us being generally unavailable for listening to feedback, pain points, or newcomers. By the end of the week we were so tired we could not get anything done. We needed to free up time during the week. There are goals that can only be reached in the Summit setting, where all of our community is represented — we keep those goals in the Summit week. There are goals that are better reached in a distraction-free setting — we organize a separate event for them.

Q: What is the Forum?

A: Forum is the name for the part of the Design Summit (Ops+Devs) that still happens at the main Summit event. It is primarily be focused on strategic discussions and planning for the next release (the “what”), essentially the start of the next release cycle even though development will not begin for another 3 months. We should still take advantage of having all of our community (Devs, Ops, End users…) represented to hold cross-community discussions there. That means getting feedback from users and operators over specific projects in our last release, gathering pain points and priorities for upcoming development, proposing changes and see what the community thinks of them, and recruiting and onboarding new team members. We will do that in a neutral space (rather than have separate “Ops” and “Dev” days) so that the discussion is not influenced by who owns the session. This event will happen at least two months after the previous release, to give users time to test and bring valuable feedback.

Q: What is the Project Teams Gathering (PTG)?

A: Project Teams Gathering is the name for the part of the Design Summit that happens as a separate event. It provides space for project teams to meet, make implementation decisions and start development work (the “how”). This is where we’ll have essential cross-project discussions, meet with our existing project team members, generate shared understanding, kickstart the development work on the new cycle, and generally get things done. At this event, OpenStack project teams are given separate rooms to meet for one or more days, in a loose format (no 40-min slots). If you self-identify as a member of a specific OpenStack project team, you should definitely join. If you are not part of a specific project team (or can’t pick one team), you could still come but your experience of the event would likely not be optimal, since the goal of the attendees at this event is to get things done rather than listen to feedback or engage with newcomers. This event happens at (or just around) the previous release time, when developers are ready to fully switch development work to the new cycle.

Q: How is the change helping OpenStack as a whole?

A: Putting the larger Summit event further away from last release dramatically improves the feedback loop. In the past, calling for feedback at the Summit was not working: users hadn’t had time to use the last release at all, so most of the feedback we collected was based on the 7-month old previous release. It was also the wrong timing to push for new features: we were already well into the new cycle and it was too late to add new priorities to the mix. The new position of the “Forum” event with respect to the development cycle makes it late enough to get feedback from the previous release and early enough to influence what gets done on the next cycle. By freeing up developers time during the Summit week, we also improve the Summit experience for all attendees: developers will be more available to engage and listen. The technical content at the conference also benefits from having more upstream developers available to give talks and participate in panels. Finally, placing the Summit further away from the release date helps vendors prepare and announce products based on the latest release, making the Summit marketplace more attractive and relevant.

Q: What about mid-cycles?

A: In the past, mid-cycle sprints were organized in separate events by project teams as a way to gather team members and get things done. They grew in popularity as the distractions at the main Summit increased and it became hard for project teams to get together, build social bonds and generally be productive at the Design Summit. We hope that the Project Teams Gathering event will fulfill those productivity and social bonding needs, eliminating the need for separate team-specific sprints.

Q: This Project Teams Gathering thing is likely to be a huge event too. How am I expected to be productive there? Or to be able to build social bonds with my small team?

A: Project Teams Gatherings are much smaller events compared to Summits (think 500 people rather than 7000). Each project teams will be allocated a specific, separate room, in which they will be able to organize their work however they see fit. The only moment where everyone will meet should be around lunch. There will be no evening parties: project teams will be encouraged to organize separate team dinners and build strong social bonds.

Q: Does that new format actually help with cross-project work?

A: Cross-project work was unfortunately one of the things a lot of attendees dropped as they struggled with all the things they had to do during the Summit week. Cross-project workshops ended up being less and less productive, especially in getting to decisions or work produced. Mid-cycle sprints ended up being where the work can be done, but them being organized separately meant it is very costly for a member of a cross-project team (infrastructure, docs, QA, release management…) to attend them all. We basically set up our events in a way that made cross-project work prohibitively expensive, and then wondered why we had so much trouble recruiting people to do it. The new format ensures that we have a place to actually do cross-project work, without anything running against it, at the Project Teams Gathering. It dramatically reduces the number of places a Documentation person (for example) needs to travel to get some work done in-person with project team members. It gives project team members in vertical teams an option to break out of their silo and join such a cross-project team. It allows us to dedicate separate rooms to specific cross-project initiatives, beyond existing horizontal teams, to get specific cross-project work done.

Q: Are devs still needed at the main Summit?

A: Upstream developers are still very much needed at the main Summit. The Summit is where all of the OpenStack community gets together and where the feedback loop happens. All project teams need to be represented there, to engage in strategic discussions, collect the feedback on their project, discuss cross-community topics, reach out to new people and onboard new developers. We also very much want to have developers give presentations at the conference portion of the Summit (we actually expect that more of them will have free time to present at the conference, and that the technical content at the Summit will therefore improve). So yes, developers are still very much needed at the main Summit.

Q: My project team falls apart if the whole team doesn’t meet in person every 3 months (at the Design Summit and our separate mid-cycle project team meeting). With this change aren’t we losing our ability to all get together every 3 months ?

A: As mentioned earlier, we hope the Project Teams Gathering to be a lot more productive than the current Design Summit, reducing the need for mid-cycle sprints. That said, if you really still need to organize a separate mid-cycle sprint, you should definitely feel free to do so. We plan to provide space at the main Summit event so that you can hold mid-cycle sprints there and take advantage of the critical mass of people already around. If you decide to host a mid-cycle sprint, you should communicate that your team mid-cycle will be co-located with the Summit and that team member attendance is strongly encouraged.

Q: We are a small team. We don’t do mid-cycles currently. Now we’ll have to travel to four events per year instead of two?

A: Each team needs to decide if it needs to get together to build trust and get work done over the next 6 months. If it does, it should participate (as a team) to the Project Teams Gathering. If it doesn’t, the team can skip it. The PTL and individual team members interested in engaging with other teams (or participating in cross-project efforts) should still definitely come to the Project Teams Gathering, but you don’t need to get every single team member there if you don’t have a dedicated team room. Note that in all cases, your project wants to have some developers present at the Summit to engage with the rest of the community.

Q: The project I’m involved with is mostly driven by a single vendor, most of us work from the same office. How does it make sense for all of us to travel to a remote location to get some work done?

A: It doesn’t make a lot of sense, and as a result we expect single-vendor teams in that situation to not request a team room at the PTG. The PTL (and whoever else is interested) should probably still come to the Project Teams Gathering to participate in cross-project work. And you should also definitely come to the Summit to engage with other organizations and contributors and increase your affiliation diversity to the point where you can take advantage of the Project Teams Gathering.

Q: I’m a translator, should I come to the Project Teams Gathering?

A: The I18n team is of course free to meet at the Project Teams Gathering. However, given the nature of the team (large number of members, geographically-dispersed, coming from all over our community, ops, devs, users), it probably makes sense to leverage the Summit to get translators together instead. The Summit constantly reaches out to new communities and countries, while the Project Teams Gathering is likely to focus on major developer areas. We’ll likely get better outreach results by holding I18n sessions or workshops at the “Forum” instead.

Q: A lot of people attend some sessions at the current Design Summit to get a peek at how the sausage is made. How do we preserve that education aspect in the new model?

A: It is true that the Design Summit was an essential piece in showing how open design worked to the rest of the world. However this created a lot of tension, as it is difficult to educate and reach out at the same time you try to get some work done. We tried to separate fishbowls and workrooms at the Design Summit, to separate discussion/feedback sessions from team-members work sessions. That worked for a time, but the context switch can be hard, and people started working around it, making some work rooms look like overcrowded fishbowl rooms. In the end that resulted in a miserable experience for everyone involved. In the new format, the “Forum” sessions will still allow people to witness open design at work, and since those are specifically set up as listening/outreach sessions (rather than team-introspective “get things done” sessions), we can take the time to properly engage and listen. It will also free up time for upstream contributors to present in the general conference and explain how the model works, rather than solely rely on the potentially-frustrating direct experience

Q: Having the Design Summit at the same time as the Summit allowed us to transform users and other community members into potential contributors. Doesn’t the new format jeopardize that seamless onboarding?

A: It is fair to say that by separating project teams gatherings from the general summit event, we make it more difficult for new potential contributors to informally join an existing team during the summit week. On the other hand, the week was so intense that team members could not really dedicate time (or space) specifically to reach out to and recruit new potential contributors: those new members had to hit the ground running. We could not spend half the time in a 40-min session to introduce or summarize the history of the topic to newcomers. By not running the work sessions during the summit week, we free up time for dedicated onboarding and education activities. Project teams will be able to request specific sessions to introduce a given project to newcomers in a classroom setting, where a few team members will spend the necessary time to explain things out. If the new contributor is interested and decides to get involved, their next step would be to start contributing and attend the project team gathering event, only 3 months away (rather than 6 months away). Beyond that, fewer conflicts during the week means we won’t be always running to our next sessions and will likely be more available to reach out to others in the hallway track, extending our recruitment sphere to people who might not have attended the Design Summit at all in the previous setup.

Q: What about the Ops mid-cycle meetup?

A: The Ops meetups are still happening, and for the next year or two probably won’t change much at all. An “Ops Meetups Team” was started to answer the questions about the future of the meetups, and also actively organize the upcoming ones. Part of that team’s definition: “Keeping the spirit of the ops meetup alive” – the meetups are run by ops, for ops and will continue to be. If you have interest, join the team and talk about the number and regional location of the meetups, as well as their content.