On Tue, Sep 6, 2016 at 5:55 PM, Rob Lanphier robla@wikimedia.org wrote:
On Mon, Sep 5, 2016 at 11:14 PM, Quim Gil qgil@wikimedia.org wrote:
GOALS [...] The Summit and its goal have been a moving target over the years, as you can deduce from the many changes of names & goals. [0]
It has been, but given the high satisfaction scores last year, I think it behooves us to come up with iterative improvements, not a radical rethink. It seems like last year we got closer to what we've been struggling to achieve in previous years.
The satisfaction scores about the Summit itself (based on a survey run just at the end of the event) are indeed high, and I agree that we should keep the basic model for the three days, just adding iterative improvements wherever needed. This comprises combination of pre-scheduled and unconference sessions, the organization in areas with owners, the organization of sessions with note-takers and other roles...
We have got clear feedback about the need to rethink the phases before and after the event.
Before, the call for participation and the selection process was felt as confusing and requiring a lot of energy from everyone (organizers included), without a clear benefit. By agreeing on a few main focus areas beforehand and "curating" them (assuring the the right people are invited and the right topics are addressed), we could leave more freedom of self-organization to all the rest.
After, the Summit discussions that brought high levels of satisfaction get frequently colder and stalled, having little or no impact in the daily work, quarterly planning, longer term strategy. By agreeing on a few main focus areas that are already connected to our strategy and plans, and by assuring that all required parties are as involved as the developers, the Summit will have the impact that its participants expect.
Widening the audience was a main goal last year. This is why we renamed
it
to Wikimedia (not MediaWiki) Developer Summit, and we invited developers
of
tools, templates, bots, mobile apps, the MediaWiki Stakeholders Group,
and
also non-Wikimedia users of our APIs. It was a half-backed thought that received half-backed support that unsurprisingly brought half-backed results.
I think that's a bit unfair to what we accomplished last year.
My evaluation is based on the number of non-WMF developers specializing on tools, templates, bots, mobile apps, MediaWiki, and other users of our APIs, and what they got from the event. It is also based on how much outreach effort we managed to put into assuring that the participation from these sectors was rich and diverse. Making the assessment above doesn't make me happy at all, but I think it is a fair and frank one.
What if the Summit would be product driven, with architecture and the rest
following that drive. All we are here to offer better products to our users. All the technical discussions make more sense when there is a
clear
product vision to be either supported or contested with reality checks.
I would like to get Wes's take on this. Last year, I didn't get the sense that Wes was eager to grab the reins on WikiDev16, and I'd be surprised if he wants to do it this year. That seems to dump too much of the responsibility on him.
It would seem that the target *participant* for this summit would be the future WMF Chief Technology Officer (CTO). Assuming that we have the CTO hired by January, it would set the bar way too high to expect that the new CTO will be responsible for running the summit. We should strive to make a big theme of this summit be "onboarding WMF's new CTO". Obviously, the scope should be more than that, but let's hope that WikiDev17 is a great introduction to the wikitech-l community for our new CTO
OK, it looks like I need to define better what I mean by "product driven". First of all yes, MediaWiki and Wikipedia clearly are products. Then...
When Brion opens this thread proposing to refocus the Summit "to prioritize and work on things that really matter" to our users, he is basically proposing to change from a tech-architecture-infrastructure-driven perspective to a perspective driven by user experiences, the features that users miss, the problems that bug them most. Let the users talk, and then we will figure out what that means in terms of technology, architecture, infrastructure.
I don't think that a reinvented "Dev Summit that asks our users to participate" is feasible in the literal sense, if that Summit needs to happen in January and today we are just beginning to discuss the notion of it. But I strongly agree with Brion's point, and I think that a totally feasible move in that direction is to
* select some challenges with a big user impact from the WMF Product roadmap * select some challenges from the highly ranked requests from the Community Wishlist * assure that the people that need to be involved in the discussion and resolution of these challenges are represented (from developers to users with all the other roles in between) * leave plenty of space for other topics that other participants want to push in a self-organized way
This has nothing to do with Wes or the future CTO being in charge of the Summit or not. I am not expecting them to select those challenges themselves, even less to organize the program or the event. On the other hand, we cannot afford weeks of discussions to select these main challenges either. We should be opening registration and travel sponsorship requests asap, and both are connected.
One way to get there is to have WMF Product selecting these challenges with feedback from the Technology department and have Community Tech selecting the challenges from Community Wishlist tasks, all this while keeping listening the discussion in wikitech-l.
As a future participant of the Summit 2017, if yourTopicX was not selected, you will still be able to rally for it, attend the Summit, and convince others to join as well. We will offer you time and space so you can push your topic.
My proposal: let's make the scope of invitations be "participants in
wikitech-l".
I see where you are coming from, but this goes in the opposite direction of the "opening up" that we have been pushing, and that moved Brion to start this thread. I think we can find ways to assure that "wikitech-l people and concerns" are addressed, while assuring that the opening up keeps happening.
PS: It looks that everybody agrees on high prominence to Community Wishlist related topics. It's a decision, then!