Jump to content

Wikimedia Technical Conference/2018/Session Guide

From mediawiki.org

Overview

[edit]

Goal: The sessions for TechConf are designed to answer specific questions which will enable the Platform Evolution Program team to develop and execute a 3-5 year technical roadmap for the platform.

How did we get here: The sessions and questions were created through aggregating feedback from stakeholders throughout the Wikimedia Foundation, Wikimedia Deutschland, movement volunteers and 3rd party users of the platform.

In order to have a wide array of viewpoints, the conference committee has invited product managers, designers, community members and 3rd party developers along with engineers. Additionally, many budget owners for teams within the WMF are also invited to ensure any outcomes are grounded in the context of our resources and time.

Structure: The Program Committee and Session Leaders have worked together to develop session structures and exercises. Exercises range from gathering use cases, discussing architecture principles, planning to solve technical problems, uncovering steps to remove blockers, and developing processes that will allow us to make changes to the platform over the next 3 years in a systematic way which is inclusive of feedback from stakeholders and is respectful of our communities.

How to participate:

  1. Choose which sessions you would like to attend
  2. Read prerequisite session information prior to attending a session
  3. Attend session: Participate and provide input as needed
  4. Follow-up post session as needed.

Conference Structure

[edit]

The conference is designed around several themes. Each theme has several topics, which themselves are broken down into sessions. Each session has multiple questions to answer.

The flow of the conference looks at our platform from the outside, inward. This means we look at the users we serve and the products we build, move into features and then into technical problems. At the end of the conference, we will regroup and review what we have answered and discuss how to turn our work from the conference into a roadmap.

Much of the conference is focused on enabling engineers to solve problems after the conference. Sessions are designed to get agreements on use cases, requirements, and principles that can be used as a guide when developing technical solutions.

Session Structure

[edit]

The sessions themselves are very much about problem-solving and not writing code. We want to use the rare opportunity to have face to face discussion which can lead to concrete next steps for moving our platform forward to support our movement strategy.

In addition to having a topic and theme, sessions also have a type to describe the general purpose of each session. Session types are listed below in this document.

Each session also has several questions to answer. To provide context for each question, we have also attached a description of the significance of that question and why it is important to answer for technical planning.

In order to answer questions, sessions will have one or more activities that will be used to answer questions. Session leaders will develop the activities along with members of the TechConf committee.

Session Leader Information

[edit]

Prior to TechConf

[edit]

Session Leaders will be provided a session sheet which will be used to guide the session. Each sheet has several questions which the session should try to answer along with the significance of each question.

Committee members and session leaders will discuss and refine the questions prior to the conference. They will also work together to select the appropriate activity or activities to uncover the answers to questions.

While working to refine sessions, session leaders are expected to provide the domain knowledge for each session, ensuring that questions make sense and will actually achieve the desired goal. Committee members are expected to make sure that sessions remain true to solving the issues outlined by stakeholders and that each session fits into the rest of the conference as a whole.

At TechConf

[edit]

Sessions leaders should arrive at 9:30am the day of their session to check-in with the facilitator for their session and the program committee. This is a final check to make sure everything is ready for their session that day.

At the beginning of the session, the session leader should make sure the participants can read the questions that are supposed to be answered in that session. This can be done by printing out the questions or writing them on the whiteboard. The questions should be listed in a prioritized way to ensure the discussion focused on the most important questions first. Remember not everyone in the session needs to answer all the questions. Participants can break into small groups to work on specific questions. Smaller groups of 6-8 people can be more efficient for this.

At the end of the session, the session leader should confirm next steps for that session topic are identified and confirm with the notetaker that all the outcomes and answers to the questions are documented.

Post-Session

[edit]

There is time daily for compiling notes and updaing Phabricator tickets. Session Leaders should confirm outcomes of the session are documented in the Phabricator ticket associated with that session.

Session Process at TechConf

[edit]

Each session will have one or more leaders, a facilitator and a scribe.

Full role descriptions TBD, see: https://www.mediawiki.org/wiki/Good_meetings#Roles

Setup

[edit]

Each session starts out with handing out of session setup notes. Groups can read together before starting.

Activities

[edit]

After everyone has an understanding of the session, the session leader and facilitator will begin the activity (or activities) designed for the session. This may involve breaking the session into smaller groups. Try to keep groups small to have productive discussion.

Documenting

[edit]

Each session will have a dedicated scribe to document the session. When breaking into smaller groups, please note that the scribe may need some help to keep up with note taking.

Publishing notes

[edit]

At the end of each day we will have dedicated time to take scribe notes and publish them in Phabricator.

Creating morning briefs

[edit]

Also at the end of each day Conference Committee members will work with session leaders and scribes to create morning briefs for the next day that attendees can read as they get coffee and settle in

Session Guidance for facilitators

[edit]
  • Activities should be inclusive - get opinions from different viewpoints
  • Activities should be active
  • Activities should be designed to answer questions, try to avoid open discussion
  • Keep discussions small - large discussions tend to be unproductive and slow
  • Keep discussions focused on answering the questions, allow brainstorming, but bring things back to the questions.
  • If work is too much, divide and conquer. Break into small groups and work on
  • Computers closed :)
  • For brainstorming activities, hold off thinking about constraints such as resourcing
  • If you can’t answer a question, make sure you know why and write it down
  • If the question is wrong, make it right so you can answer it
  • If you uncover more questions, answer them if you can, and if not write them down and figure out who can answer them
    • Agreement is good, but if you can’t agree:
    • list the trade-offs of competing answers
    • provide action items and questions to get to unblock the answer
    • Say who you think can answer questions and make the decision

Session Guidance for scribes and notetakers

[edit]

See https://docs.google.com/document/d/1J-wTeelHFGeXw6dO1ywkGr0NfnzG-cUykowc6aSKoWE/edit#

Session Types

[edit]

Product Vision

[edit]

These sessions provide an opportunity for product owners to communicate vision for products that they build. The information from these sessions provide context for both the use cases we serve and the technologies we choose.

Evaluating Use Cases

[edit]

This type of session is examining at a set of use cases that have the potential to generate requirements which significantly impact the architecture. The questions are designed to remove ambiguity about the use cases and identify key features that will result in us being able to unblock architecture decisions.

Technical Challenges

[edit]

This type of session is looking at a current technical challenge which is impacting our ability to deliver software and/or maintain our infrastructure. The questions are designed to get alignment on issues and goals and identify concrete actions that we need to take to implement a solution.

Status Updates

[edit]

Practically we won’t have time to discuss all subjects that stakeholders and attendees feel need to be discussed. In addition, some projects are already in process to address some of our major issues and we just need to provide space for updates to be given. These sessions are the venue to do both of these activities.

Process Workshop

[edit]

These sessions are designed to be hands-on to review by doing. In these sessions, we will walk through processes to show what is working, possible things to be improved and other gaps.

Facilitation Exercises

[edit]

These are possible exercises for TechConf aimed at avoiding large group discussions or one person presenting and others listening.

Spectrum Exercise

[edit]

A virtual line is draw along the center of the room. The facilitator then puts forward a series of statements with two differing viewpoints with each viewpoint put at one end of the room. Participants then line themselves up along how much they agree or disagree with each one.

Keep/Change/Don’t Agree

[edit]

Facilitator puts forward topic to the group and then participants write down on post-it notes statements regarding what they think is going well and what needs to be done differently for 5 minutes. Then the group goes to a wall and read and put up their statements under each relevant column. Ones not agreed on are put in that column for later discussion.

  1. What should we keep doing?
  2. What do we need to do better or differently?
  3. What do we not agree on?

Small Group Discussion

[edit]

Participants are broken into groups of no more than 6. The facilitator then puts forward a series of questions for the groups to discuss. Each group decides on a spokesperson. At the end of the discussion each spokesperson presents to the entire group what their group decides. Other groups have the opportunity to ask questions of the other groups after they present. Areas where groups don’t have agreement are noted and saved to be discussed further later in other small groups.

We should/I will

[edit]

This exercise is done at the end of an event. Participants are given post-its and they write down things for five minutes with the phrase “I will…” or “We should…” They then put their post-its on a wall next to either the “We should” or the “I will” categories. Participants can then read out their statements of what they are commiting to do. With the “We should” others can agree to also do that item. If not many people are reading them out the facilitator can pick a few to read or ask a volunteer to read some.

Station Rotation

[edit]

This type of activity is about giving and getting information useful for providing everyone with a shared understanding of the topics. It also gives the station maintainers an opportunity to solicit feedback from a smaller group of people resulting in more feedback

Working Group

[edit]

This type of activity provides deep discussion for a small group participants. If the group has more than 8 participants, the participants should break into smaller groups and tackle different parts of the problem (Try to keep 5-8 participants per group). Use paper, whiteboard, sticky notes, lists, diagrams and other manual tools to work together to answer the questions.

Sources for Facilitation Exercises

[edit]