On Tue, Sep 6, 2016 at 5:55 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:
On Mon, Sep 5, 2016 at 11:14 PM, Quim Gil
<qgil(a)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!
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil