Jump to: navigation, search

Moderator Guide

WIP

Below is just a lot of stuff thrown at the wall - structure can be found here - https://etherpad.openstack.org/p/moderator-guide-wiki-page - which is what this document will become over time.


COPIED FROM OPS MEETUPS TEAM MODERATORS GUIDE

Thank you very much for stepping up to be moderators at the ops meetup. Your work is key to our success!

You are in control of your sessions, however, this document lay down some ideas about what we've seen in the past makes a good session, in case it helps.

We have two different types of sessions. General Sessions and Working Groups. Below, I've separated them out so you can read what's relevant to you.

We have three overall aims:

  1. Gather feedback on the issues that come up in running or using OpenStack and work to communicate this throughout the community
  2. Create a forum in which to share best practices and architectures between interested parties
  3. Increase constructive, proactive involvement from those running or using clouds


General Sessions

Basically, it's you, an etherpad, and room full of a couple hundred people who have OpenStack experience. As the moderator, your efforts result in actionable things we can work on, and the satisfied audience.

  • Introduce yourself to the audio guy or gal. You'll be provided with a microphone and asked about laptop connection.
  • The best thing to do is convince one of your friends to control the laptop. Get them to control the display of the etherpad, and if it gets big, scroll up and down to ensure the most relevant parts are seen.
  • At the start of the session give a 30 second intro to the etherpad, and ask everyone to take notes using it. (Many attendees will not be used to etherpads)
  • Kick off the discussion on time, perhaps by starting with some open ended questions, or a show of hands to understand the audience
  • Aim to get it to that nirvana state, where the conversation continues without your help
  • Don't fall into "Question and Answer" mode - just because you're up the front of the room, some people might expect you to do this. Steer back toward discussion always.
  • There will be microphone hogs. Do not be afraid to cut them off. Using language like "Thank you, that is important, we have recorded that on the etherpad" will mean there'll be no hard feelings.
  • If you see a nice transition between different topics, take it!
  • Most importantly: try and aim for every discussion to have at least one action item - something we can work on. If we don't do this, people are going to stop coming to these things


Overall, have fun! Also *be* fun! If you get bored, the audience will sense it - so if it happens start a new topic. Spontaneity is good! Asking people to do things (file a bug, start a mailing list post) is good!


Working Groups - "Small, working sessions"

These sessions are for a focus on specific topics, and they are long sessions (normally 80 minutes) so you can actually, legitimately get work done - not just talk.

You'll have yourself, and a small group of people who are experienced with OpenStack and actually very interested in getting involved. It's your job as facilitator to try and convert each and every one of these people into a proactive member of your working group, ideally continuing their tenure well after the summit.

Since these are mostly longer session, and about much more specific things, it requires a bit more planning. For some of the groups, you will have met before and have work and processes to continue. Try and seed your etherpads with this information prior to the session.

Try and think of some concrete things that can be done during your time, but also be ready and open to the suggestions of the attendees. If there's a great idea that everyone believes in, go for it and get it done. File bugs. File blueprints. Submit patches. Write documents. Use the whiteboard. You have time for all of this


Of course, all of this information is general. You are the rockstars here - do whatever you think is best . Tom will be on hand for much of the two days for assistance. (call +886 98833 1200 if anything goes horribly wrong)

There are also a few sessions which are a bit different...

Architecture Show and Tell

This is a series of lightening talks - basically a 5-8 minute talk about something cool about your deployment.

If you're moderating this, one of the main duties you have to perform (or delegate) is that of timekeeping - we normally cycle through many talks in each session.

Best practice is to get any slides people are using into one laptop before the start of the session.

Pre-and Post Meetup

Fully realising you are a volunteer with limited time and that you might not get around to any of this, some of the things that are cool to do before or after the meetup are:

  • Post a thread on the ops ML asking for ideas for your session (and also advertising it)
  • Giving a tweet out with the schedule details
  • Filling in the etherpad with some conversation start topics (or, if you are a developer looking for feedback - questions you would like answered)
  • Posting on the Ops ML a summary of the session and linking to the etherpad for those who couldn't make it
  • Writing a new wiki page under the Operations page with a summary of best practices/new tools you discovered etc
  • Following up on action items that people volunteered to do during the meetup ;)
  • Organising a followup IRC meeting, if applicable


COPIED FROM FORUM MODERATOR TEMPLATE

    • This is just a template. Feel free to copy this content and paste it to your own etherpad. The primary goal is to obtain actionable items for our community.

TEMPLATE FOR BOSTON FORUM SESSION

Fishbowl Session? Sit close if you want to be vocal, speak up, your words matter!

<SESSION TITLE>

Etherpad: https://etherpad.openstack.org/p/BOS-forum-moderator-template (suggested url format: https://etherpad.openstack.org/p/BOS-forum-<sessionname-abc>) Schedule Details: http://forumtopics.openstack.org/cfp/details/XYZ

DATE / TIME / ROOM LOCATION Moderator: Your name <email@address> (irchandle)

Related Forum etherpad(s):

Related PTG etherpad(s):

Related Ops etherpad(s):

Other related etherpad(s):

Use of ##<hashtag>:

    • Use ##<hashtag> to highlight actionable items or something that need attention from a specific project team or working group
    • This help the Forum team to aggregate data and produce post-forum summary report
    • If a discussion item contains multiple actionable items in sub-bullet list format, please also include the same ##hashtag at the end of the sub-bullet list.
    • Examples on how to use ##hashtag can be found here: https://etherpad.openstack.org/p/BOS-forum-hashtag-definition

Recommended hashtag:

   ##newfeature - Proposal for a new feature, similar to RFE
   ##gap - Feature gap that does not have a solution yet
   ##uservoice - Feedback from users and operators
   ##painpoint - Functional challenges/problems (either real or perceived) in operating openstack cloud (e.g. upgrade is painful, root-cause analysis is complex)
   ##<workload-type> - Any new or existing workload for OpenStack, examples of workload-related hashtag can be ##nfv, ##hpc, ##enterprise, ##bigdata, ##iot, or a new workload type you identify
   ##<project-name> - Items that need action/attention from a specific OpenStack projects (e.g. ##nova, ##neutron, ##glance, etc)
   ##<working-group/team-name> - Items that need action/attention from a specific OpenStack working groups/teams (e.g. ##lcoo, ##pwg, ##ewg, ##publiccloud, ##interop, ##uc, ##tc, ##board, ##foundation)


Session Description: Begin with the end in mind and write a paragraph, list, etc Taken from guide on crafting session description found here - http://velvetchainsaw.com/2010/03/18/crafting-better-conference-materials-writing-session-descriptions-for-dummies/

   Make a list of every feature of attending the session.
   Ask why each feature is included in the first place.
   Take the why and ask how this connects with the prospective attendee’s desires.
   Get to the absolute root of what’s in it for the attendee at an emotional level.


Agenda: From your description above, break out as much as you can into talking points so that there is a smooth transition to the end. We want to accomplish something during this session which can be measured after the session is over and are looking to you as a moderator to help extract actionable items and/or information.

   Discussion Item 1
   Folks should be adding notes here
   Additionally you can prepare sub-items relevant to the primary discussion item
   Discussion Item 2


   Discussion Item 3


   ...


Work Items / Wishlist: Allow for 5 minutes or so at the end of your session to capture work items just in case it was not possible during the session. Always good to ensure these were captured and use the ##<hashtag> whenever possible.

Participants:

   Your name <email@address> (irchandle)

COPIED FROM DESIGN SUMMIT WIKI PAGE

The Design Summit has been split into two separate elements: the Project Teams Gathering and Forum within the main summit conference. Therefore not everything on the rest of this page necessarily still holds, but the page is kept here for historical reference. For more information on this split, please see the PTG FAQ.

At Design Summits the developer community gathered to brainstorm the requirements for the next release, discuss the implementation details and connect with other community members. The OpenStack Foundation offers a Travel Support Program to help cover travel expenses.

Past Design Summits

  • Ocata Design Summit, Oct 25-28, 2016 in Barcelona, Spain.
  • List of etherpads for the Ocata summit

How does the Design Summit work?

The Design Summit is a part of the OpenStack Summit. It is not a classic conference track with speakers and presentations. Developer project teams brainstorm the topics they need to cover and get alignment on. The agenda is collaboratively reviewed and then scheduled by the program technical leads (PTLs). Those scheduled sessions can include the presentation of a few slides but are generally a 40-min long, open brainstorming discussion on a given subject or feature. If you care about a particular subject, please join. Due to the nature of the event, the schedule is a bit dynamic, so check out the summit schedule pages often.

If you suggest a session, you should be ready to moderate that session and make sure the discussion stays on track. Experienced developers will generally help in that endeavor, but you should plan to attend that session yourself.

The Design Summit is not the right place to get started or learn the basics of OpenStack. For that it's better to check the various OpenStack meetups organized by user groups around the world or attend the other conference tracks of the OpenStack Summit.

Session types

There are three types of sessions at the Design Summits:

Fishbowl sessions

Those are open sessions to discuss a specific feature or issue we have to solve. They happen in large rooms organized in fishbowl style (concentric rings of chairs). People wanting to participate to the discussion should move to the inner rings.

Work sessions

Work sessions are smaller gatherings of teams (or subteams) members to get specific work planned and done. They happen in smaller rooms organized in boardroom style.

Contributors meetups

On the last day of the summit, developers on a given team will gather for a half-day or a full-day of open discussions without a pre-defined theme. Depending on how the previous days went, the agenda might evolve.

Before the Design Summit: propose sessions

Each project team comes up with its own way of building a schedule, ultimately arbitrated by the team's PTL. Sessions are generally proposed on an open document (etherpad...) announced on the openstack-dev mailing-list, and then discussed at team meetings.

At the Design Summit

  • The schedule will be available online a few weeks before the Design Summit starts. Refer to it early, refer to it often
  • The session should start on time, be there or be square
  • The session lead starts by introducing clearly what the session is about (and what it is not about) to set expectations
  • It is the responsibility of the session lead to keep the discussion live and on-topic
  • Make the best use of the available time !
  • Collaborative note taking during the session should be done through http://etherpad.openstack.org, please participate and make sure your points are reported there
  • In fishbowl sessions, 5 minutes before the end of the session, the session lead should start making sure (s)he gets clear outcomes, work items and actions from the session
  • End on time, to give participants the time to switch rooms to the next session if needed

After the Design Summit: document outcomes

  • Document significant outcomes and post them to the mailing-list, so that the people who could not join the event can still influence the decision

Design Summit tips

  • We organize a special "Design Summit 101" session to serve as an introduction to how things work. You can find a write-up of such a session here.
  • Experienced OpenStack contributors share their tips on how to moderate a successful session on this video.