Page MenuHomePhabricator

Wikimedia Developer Summit 2017 Debrief(s)
Closed, ResolvedPublic

Description

I would like to do individual in-person / hangout debriefs with the following people:

Comms (remote / social media stuff):
IT / Admin:
Program Commmitee:
Finance (sounds like @Lani will be organizing this one)
Scholarship committee:
Core organizing team (rachel, srishti, Quim)
Tech / Product Management: Victoria, Wes, Toby, anyone else.

These meetings should be 30 min each. These meetings should have pre-meeting email discussions & agendas. The results of these meetings should be incorporated into the the feedback from the event surveys.

Links:
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2017/Lessons_Learned
https://phabricator.wikimedia.org/T154925

Event Timeline

One suggestion that I will being up in the meetings especially with Tech / Product management and the core organizing team will be a suggestion to make the Dev Summit take place on a Wednesday - Friday and the All-Hands to take place on a Monday / Tuesday as we have done in the past.
This will allow time for people to meet with their teams over the weekend, have a break in between events, and for there to be extra time during working days both before and after the event for meetings, offsites, and other things.

Aside from the debrief with Was and Victoria I will schedule all of these for the weeks of 2/6 and 2/13 when I will be in SF.

Rfarrand raised the priority of this task from Medium to High.Feb 1 2017, 7:37 PM

Debrief with Admin team:
Pain points: contracts should be finalized further in advance if possible. Collaborate with finance and legal to streamline process. Monday morning registration set-up should be less hectic.

Ideas for next time: Admin briefing in advance, give registration packet to admin team days before the event so they can put everything in order then, give venue maps to admin team in advance so that they can memorize it in advance, more signs especially directional venue signs would have reduced the questions at the help desk by a lot.
Sarah: next time would like to be more involved with the heavy logistics planning
Megan: next time would like to be more involved with the program and unconference
Lani: Is happy to help but does not want main ownership of any area

The team of 4 of us agree that we worked well together and that pre-event communication was good.

Notes from debrif with Comms:
Melody, Jeff, Srishti, & Rachel

pain points: last moment change of which sessions would be recorded, find a better way to get people to understand the note taking process. Also we need to have better camera placement for remote sessions and make sure the speaker knows to stay on camera.

We worked together on remote participation (IRC, notes in the right places, helping people who needed to figure ou the correct youtube links, updating Phab tickets, social media & pre-messaging, and during some sessions Melody took notes. We also had pre-event brainstorming sessions about remote participation support.

We think Melody's role of remote advocate was very successful. She watched everything happening remotely and stepped in where she was needed to fix things that were unclear for remoties. She ended up helping a lot with note taking. Next time we will try to have better camera placement and audio for the live streams. Jeff recommends doing more with social media. We can start with the big large-audience WMF accounts and direct people to the smaller MediaWiki accounts. More posts in advance of the events and more, artistic or quotes-from-speaker posts during the event to pull in more remote participants.

Jeff also suggests providing a "highlights of dev summit" at the begining of the WMF all-hands to help the WMF staff who did not attend the Dev Summit feel more connected. Mel would be willing to help put something together for this.

Also more blog posts from the event (Rachel will add this to the volunteer section in registration)

Also find ways to take speakers from the Dev Summit and have them redo their talks at another technical conference and/or make their talks non-tech friendly in an attempt to explain what happened technically at the summit to non technical people who were not at the summit.

Notes from debrief with IT
Rachel, Srishti, Byron, Brendan

Pain points: Brendan was over extended. At a next event if we have the same remote participation needs we should being a minimum of 2 people from IT and provide more support for IT from the A/V company. It would have been better to have at least two people responsible for starting all the videos and streams. Also, some of the meeting rooms were too large for the meetings that were held in them. This caused issues with capturing the audio for some of the remote sessions. Byron notes that the WMF internal contracting process should be given more time to make sure everything is sorted on time. Next time we should also ask the venue to use a projector in the main room at has a better "output ratio" so that more people's laptops can sync with it more easily and accurately. Apparently the projection dimensions were a bit off.

In the future, IT would be willing to travel to events and send more people to local events (defaulting to 2). IT may be at Wikimania already so we could potentially get them involved in helping with remote participation at the hackathon there.

We worked well together and everyone was happy with the communication and partnership.

Some thoughts that have come up on doing debriefs:

  • Start off by recording what we accomplished together as a group to make sure nothing is missing. Sometimes people in the departments we were partnering with did even more than I realized.
  • Start with pain points and THEN move to what we did well together. If you start with the positives it moves automatically to the pain points before we actually get to that agenda point.
  • Spend time on improvements. What can we do better for next year.
  • Ask how different departments can work together more effectively next time. Want to make sure that working with TC is not a burden.

More debriefs:
Finance debrief was done by email and I will summarize here later.
@Qgil will probably do the program committee debrief, which I can also attend, and will summarize it here. Correct Quim?
I will run the scholarship committee debrief and summarize it here. Just need to find a time that works for everyone.
We have already done the management debrief and I will summarize it here once we know what our future direction from tech and product is.
After all of that @srishakatux and @Qgil and I will do a final debrief and then I can close this task...

Thanks for all this.

We think Melody's role of remote advocate was very successful. She watched everything happening remotely and stepped in where she was needed to fix things that were unclear for remoties.

I found this passage especially interesting. Thanks for experimenting with it.

Comments about working with Finance in the future:

Accounts Payable cannot pay a service related invoice unless there is an agreement on file w/in CobbleStone
The expense & agreement terms must be routed via CRF workflow prior to asking the vendor to perform any services
The CRF workflow encompasses the following:
expense approvals in line via this matrix
finance control checks (Purchasing & Budgeting)
legal approval of terms
In lieu of a PO system - the interim process involves thevendor referencing the CID - Contract ID # on their invoice to facilitate AP obtaining expense details related to their processing of the payment
When vetting new vendors - look for a track record, evidence of service capabilities and necessary insurance coverage commensurate with their service or goods offering
If you need help sourcing new vendors or conducting a competitive bid - Purchasing can help

I'd just emphasize the "prior to asking the vendor to perform any services" part of the second bullet point. We discussed the importance of submitting requests far enough in advance to ensure adequate time for finance control checks and legal review (which includes negotiation). Contracts very often can't be approved as written, which is why legal asks for a 7 business day turnaround in order to reach out to the vendor and agree on terms.

This page has been linked on the Dev Summit lessons learned page and will be referenced in advance of the next Dev Summit if/when we commence planning!

https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2017/Lessons_Learned