Opening up MediaWiki dev summit in January?

List overview All Threads
Download

newer

older

Re: [Wikitech-l] [Engineering]...

ArchCom IRC office hour: Content...

Brion Vibber

1 Sep 2016 1 Sep '16

7:12 p.m.

The last couple years we've done a big MediaWiki Dev Summit in January, around the time of the Wikimedia Foundation all-hands meeting. Invitations have been fairly broad to known developers, but there's a very strong feeling that newbies, non-technical people, and in general *the people MediaWiki is created and maintained for* are not welcome. I think we should change this. I would really like a broader MediaWiki Dev Summit that asks our users to participate, and asks "developers" to interact with them to prioritize and work on things that really matter to them. I want template authors, Lua module authors, template users, power editors, folks working on the lines of defense for vandalism patrol and copyvio checking. I want people with opinions on discussion systems. I want people who have been editing for years and have experience with what works and what doesn't. I want people who wish they could edit but have a bad experience when they try, and want to share that with us so we can help make it better. Thoughts? -- brion

Show replies by date

Pine W

1 Sep 1 Sep

7:20 p.m.

I like the concept. I wonder, if instead of having a standalone dev summit, it would make sense to have this broadly scoped conference be combined with or adjacent to Wikimania. Pine On Sep 1, 2016 10:12, "Brion Vibber" <bvibber(a)wikimedia.org> wrote:

...

Tony Thomas

7:23 p.m.

On Thu, Sep 1, 2016 at 10:42 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote:

...

Thoughts

Great. I was thinking the same thing last time during WikiConference India too. We had couple of hackers hacking around in one room, and editors editing in another room. When some of us took time to go near them, they told about various issues they face (but this one was more or less language specific, wiki-centric issue etc), and when we sat near them and tried fixing it, it worked, and they were overjoyed! I think this might be the only possible way to reduce the gap between users and devs. Quoting one more situation, there was a Wikimedian there at the WCI, who was typing in page titles to a wiki page and waiting for the red/blue link to show up to check if the page exists. He was doing it as part of some project. which was to find out which all pages never existed for a list (don't know who gave him the list, though) - and create the same in his home wiki. Experts would know it can be done with a python script calling one of API, and I was lucky to show him that. Wait, this might move the focus from a Mediawiki Dev summit, though - but something like this should happen, I hope. Thanks, Tony Thomas <https://www.mediawiki.org/wiki/User:01tonythomas> Home <http://www.thomastony.me> | Blog <https://tttwrites.wordpress.com/> | ThinkFOSS <http://www.thinkfoss.com>

Brian Wolff

7:32 p.m.

Last year there was an attempt to sort of do this (mostly by extending the word "developer" to mean new things). Largely those types of people didnt attend (although there were a few exceptions), however I remember being left wondering if they did attend, what would they do? It seems to me most sessions were about architecture design decisions that actually didnt affect anyone not working on the code (ie we were going to make the user visible feature either way, the question was do we use method x or method y in the backend). With that in mind. Otoh, its entirely possible that some of the sessions i didnt attend were more applicable to these groups. With that in mind are you proposing the focus of event also change? Or do you think that these groups would be interested in it as is? -- Brian On Thursday, September 1, 2016, Brion Vibber <bvibber(a)wikimedia.org> wrote:

...

editors,

...

folks working on the lines of defense for vandalism patrol and copyvio checking. I want people with opinions on discussion systems. I want people who have been editing for years and have experience with what works and what doesn't. I want people who wish they could edit but have a bad experience when they try, and want to share that with us so we can help make it better. Thoughts? -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Brion Vibber

7:37 p.m.

On Thu, Sep 1, 2016 at 10:32 AM, Brian Wolff <bawolff(a)gmail.com> wrote:

...

Yes, I think we *should* provide a focus for the event, and that the focus should be on users, use cases, and what we as developers need to do to achieve those things. In my opinion we haven't had a strong focus to the event in the past, and it's limited what we accomplish there to largely making a set of technical presentations and having a few discussions that either don't produce a decision or don't have much affect on what actually happens after the summit. (I'd be very interested also in some feedback on things that *have* worked well at MWDS in the past, as I'd love to encourage anything that has been productive! But I think we've not been successful in an architectural focus so far.) -- brion

Brian Wolff

7:47 p.m.

On Thursday, September 1, 2016, Brion Vibber <bvibber(a)wikimedia.org> wrote:

...

On Thu, Sep 1, 2016 at 10:32 AM, Brian Wolff <bawolff(a)gmail.com> wrote: > Last year there was an attempt to sort of do this (mostly by extending

the

...

> word "developer" to mean new things). Largely those types of people didnt > attend (although there were a few exceptions), however I remember being > left wondering if they did attend, what would they do? It seems to me

most

...

> sessions were about architecture design decisions that actually didnt > affect anyone not working on the code (ie we were going to make the user > visible feature either way, the question was do we use method x or

method y

...

in the backend). With that in mind. Otoh, its entirely possible that some of the sessions i didnt attend were more applicable to these groups. With that in mind are you proposing the focus of event also change? Or do you think that these groups would be interested in it as is?

focus

...

so far.) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

bawolff

8:11 p.m.

...

[Sorry about last email. accidentally hit send] Yes, we certainly do have issues with follow-through on summit decisions. For me personally, I've found the dev summits mostly useful as a community building type thing (For the MediaWiki developer community). As a remotee (Or at other various points in time, as a volunteer), its rare I actually see everyone in real life. The dev summit provides a venue to actually interact with everyone. While it may not actually be the best at resolving architectural issues, I feel like it helps me understand where everyone is coming from. In particular, I find that the dev summit is more effective for this purpose than hackathons, as the unstructured nature of hackathons tend to get people clumping in groups that already know each other. The dev summit on the other hand better provides for cross-pollination of ideas in my experience. (Don't get me wrong, I love hackathons too, just for different reasons). However, use-cases and users is why we're here, so I'm certainly not opposed to that focus. I just hope we continue to retain this as an event that's more talky and less hacky, as I feel that's where a lot of the uniqueness of the event came from. One aspect of the first MediaWiki architecture summit that I really liked but has been mostly lost, was inviting non-Wikimedia mediawiki users. They're a group that has use-cases that we don't often hear about, and provide a unique perspectives. Although I suppose its not surprising that their involvement has kind of been lost. I would love to see them come back, although I'm not exactly holding my breath for that. -- Brian

Russell Uman

8:49 p.m.

...

One aspect of the first MediaWiki architecture summit that I really liked but has been mostly lost, was inviting non-Wikimedia mediawiki users. They're a group that has use-cases that we don't often hear about, and provide a unique perspectives. Although I suppose its not surprising that their involvement has kind of been lost. I would love to see them come back, although I'm not exactly holding my breath for that.

As a non-wikimedia mediawiki developer, who attended this year's summit for the first time, I thought there was a reasonable amount of discussion that would be interesting for users/editors. There was a lot of discussion about how developers decide what to implement. Community tech wishlist most prominently, but also for other features. I remember a pretty great discussion on the first day around the various ways to support lower-bandwidth and mobile users. There was also a great discussion about the future of mediawiki core as a standalone product. Maybe that was only interesting to me :) I'd like to see this event keep its developer focus. But I think users/editors can benefit from meeting developers as much as developers can benefit from meeting developers. Even though many talks are implementation focused, I think users can help make sure the initial use cases and requirements don't get lost in those discussions, and can help with usability and acceptance testing for new features. -- russell uman firebus ((((d-_-b))))

Brion Vibber

9:15 p.m.

On Thu, Sep 1, 2016 at 11:11 AM, bawolff <bawolff+wn(a)gmail.com> wrote:

...

Yes, we certainly do have issues with follow-through on summit decisions.

*nod*

...

For me personally, I've found the dev summits mostly useful as a community building type thing (For the MediaWiki developer community). As a remotee (Or at other various points in time, as a volunteer), its rare I actually see everyone in real life. The dev summit provides a venue to actually interact with everyone. While it may not actually be the best at resolving architectural issues, I feel like it helps me understand where everyone is coming from. In particular, I find that the dev summit is more effective for this purpose than hackathons, as the unstructured nature of hackathons tend to get people clumping in groups that already know each other. The dev summit on the other hand better provides for cross-pollination of ideas in my experience. (Don't get me wrong, I love hackathons too, just for different reasons).

That's a very good point! It may be good to have distinct spaces for these environments, and 'hackathon' type events tend to have a different focus on bringing people in with shorter-term projects. I think we may want to look at ways to "boost signal" on input to and output from MWDS. Even if we don't have as much physical cross-pollination between devs and users as we could co-hosting with a bigger, less dev-focused event like Wikimania, it's important to retain that focus on user needs -- both as input to make technical decisions based on, and as output when we're reporting back what we expect to work on and if/how we can either assign resources within WMF, WMDE etc or if we need help from outside and how to organize that.

...

However, use-cases and users is why we're here, so I'm certainly not opposed to that focus. I just hope we continue to retain this as an event that's more talky and less hacky, as I feel that's where a lot of the uniqueness of the event came from.

Yeah, I get that. Thanks for bringing up the positive side of less-hacky. :) One aspect of the first MediaWiki architecture summit that I really

...

liked but has been mostly lost, was inviting non-Wikimedia mediawiki users. They're a group that has use-cases that we don't often hear about, and provide a unique perspectives. Although I suppose its not surprising that their involvement has kind of been lost. I would love to see them come back, although I'm not exactly holding my breath for that.

*nod* Some of those use-cases are great for potential Wikimedia-world uses too; we shouldn't forget those "other" users. :) -- brion

Melody Kramer

8:01 p.m.

I'm not a dev (by day job) but frequently attend hackathons and other coding events, and just wanted to detail what I do and what I've seen others do (without coding.) - write documentation - do rapid protosketching or user testing - write content for the platform/app - user test existing platforms (if devs want someone to test something out) - ideation and initial brainstorming - translation - develop comms. strategies so that the participants continue to work beyond the event - accessbility testing (I haven't done this but have seen people do it.) I've never attended this particular summit, but thought the list might provide some food for thought. This is a good blog post <https://18f.gsa.gov/2015/04/21/hackathons-not-just-for-folks-who-code/> on how to shape a hackathon or dev event for non-coders too. (Full disclosure: I used to work there, though I didn't write that post.) On Thu, Sep 1, 2016 at 1:32 PM, Brian Wolff <bawolff(a)gmail.com> wrote:

...

The last couple years we've done a big MediaWiki Dev Summit in January, around the time of the Wikimedia Foundation all-hands meeting.

Invitations

have been fairly broad to known developers, but there's a very strong feeling that newbies, non-technical people, and in general *the people MediaWiki is created and maintained for* are not welcome. I think we should change this. I would really like a broader MediaWiki Dev Summit that asks our users to participate, and asks "developers" to interact with them to prioritize

and

work on things that really matter to them. I want template authors, Lua module authors, template users, power

editors,

folks working on the lines of defense for vandalism patrol and copyvio checking. I want people with opinions on discussion systems. I want

people

who have been editing for years and have experience with what works and what doesn't. I want people who wish they could edit but have a bad experience when they try, and want to share that with us so we can help make it better. Thoughts? -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- Melody Kramer Read a random featured article from Wikipedia! <https://en.wikipedia.org/wiki/Special:RandomInCategory/Featured_articles> mkramer(a)wikimedia.org

C. Scott Ananian

9:35 p.m.

On Thu, Sep 1, 2016 at 1:12 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote:

...

Hear, hear. To make the discussion concrete, here are some issues I've had at past dev summits, which may also answer the question "what would these non-devs do?": * In a big session on services-oriented architectures, a lot of time was spent theorizing about what small wikis who do their hosting on shared-hosting services do, and whether various solutions we were proposing would make it easier or harder for these non-WMF users of mediawiki. *But none of these users were at the summit.* So no decisions could ultimately be made, as the necessary affected parties were not present. * I've tried to have conversations about the role of LanguageConverter and Content Translation at each dev summit. However, no one was present at the dev summit who used LanguageConverter on their home wiki, and few folks who rely on Content Translation routinely. (Maybe one or two were present, but not enough to have a reasonable discussion about the future of these features.) For better or worse, previous dev summits have had weak representation from those who are not American users of projects-other-than-enwiki. (Again, not that it as 100% American enwiki users, just that not enough others were present to constitute a reasonable quorum for discussing issues affecting them.) * The parsing team has various proposals for improvements to the template system. We don't really have a quorum of the "power users" of the wiki projects who write and use nontrivial templates. * In general the dev summit is pretty quite about projects other than wikipedia! Wikisource/wikibooks/wikitionary/commons/etc have lots of interesting technical work to be done, which is poorly represented by WMF employees. --scott ps. I am sympathetic to the idea that this sort of broader conversation about technical topics might fit better at wikimania. But the last few wikimanias have been moving in the opposite direction, to being less WMF-driven, and I actually thought Esino Lario was a quite nice example of how that can work. No one I talked to at Esino Lario felt that "not enough WMF staff were present" or that they couldn't get WMF answers to their questions when they needed. But this trend is opening a gap between WMF engineering and our user community, which we should try to bridge somehow or other.

bawolff

2 Sep 2 Sep

12:54 a.m.

...

* In a big session on services-oriented architectures, a lot of time was spent theorizing about what small wikis who do their hosting on shared-hosting services do, and whether various solutions we were proposing would make it easier or harder for these non-WMF users of mediawiki. *But none of these users were at the summit.* So no decisions could ultimately be made, as the necessary affected parties were not present.

I don't think that would change, regardless of what we do. Even if we have more users at the summit, its not going to be a representative sample of every type of user we have. I don't think its reasonable to assume that just because a usecase isn't represented at the summit that it doesn't exist. Anyone taking the time out of their day to travel all the way to a MediaWiki event, is probably a power user, and thus this will bias the representation of users at the summit.

C. Scott Ananian

1:04 a.m.

On Thu, Sep 1, 2016 at 6:54 PM, bawolff <bawolff+wn(a)gmail.com> wrote:

...

proposing

would make it easier or harder for these non-WMF users of mediawiki.

*But

none of these users were at the summit.* So no decisions could

ultimately

be made, as the necessary affected parties were not present.

Quite possibly! And thus perhaps we should just exclude those sort of topics from the summit -- if we can't get representative participation, we shouldn't have a decision-oriented summit session. Sessions oriented around "learning from our community" might still work -- we could have invited a cross-section of shared hosting users for a workshop where we gathered info about different hosting providers, walked them through installs using vagrant (or what-have-you), listened to their concerns & problems, and worked together with them to figure out what might work. At the end, we can't say "this will work for all users of shared hosts" but at least we can say, "for the 15 people we worked with, here are the ways they managed to install a services-oriented prototype of mediawiki" or something like that. "Community workshop" is an underexplored dev summit format. But maybe that would be a better fit at wikimania? --scott

Matthew Flaschen

9:20 p.m.

On 09/01/2016 03:35 PM, C. Scott Ananian wrote:

...

However, no one was present at the dev summit who used LanguageConverter on their home wiki, and few folks who rely on Content Translation routinely. (Maybe one or two were present, but not enough to have a reasonable discussion about the future of these features.) For better or worse, previous dev summits have had weak representation from those who are not American users of projects-other-than-enwiki.

I think this general problem is partly inevitable. I'm not saying that all Dev Summit attendees are enwiki users, or will be in the future. But I think that even with scholarships and outreach, it will inevitably be skewed in a few ways: 1. Almost no one will show up, when compared to our broad user base. The people who do come will mostly be a subset of the most enthusiastic power users. Power users are one of the groups we're building software for, but not the only one. This can be mitigated with hard work at outreach to representative users who don't typically come to this kind of thing. But this is also why we need to use other outreach and measurement efforts, like EventLogging, to reach and measure the people that don't attend summits (and may not answer surveys regularly). 2. The people that do come will be skewed towards being native speakers of English. 3. They will be heavily skewed towards being either WMF employees, San Francisco, or able to afford to fly. Scholarships can help with this, but only partly. So I would be careful about seeing this as a great opportunity to meet an accurate cross-section of our user base. We need to be a little more strategic when thinking about what to build and who we're building for. I agree with C. Scott there might be a role for specifically inviting key groups of users (e.g. shared hosting) to work with them in person and understand their needs. Though this could be at the Dev Summit, it doesn't necessarily have to be. It could be at Wikimania, or in SF but another time, etc. Matt

Rob Lanphier

1 Sep 1 Sep

10:33 p.m.

On Thu, Sep 1, 2016 at 10:12 AM, Brion Vibber <bvibber(a)wikimedia.org> wrote:

...

I think we should change this.

I think so too! I have a lot more to say, but I'm thinking that the best place to say it will be on wiki rather than on mailing list. So, I copied your message here: <https://www.mediawiki.org/wiki/Talk:WikiDev17> I'd like to give you a better response later when I have more food in me ;-) Rob

Rob Lanphier

10:36 p.m.

On Thu, Sep 1, 2016 at 1:33 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:

...

I copied your message here: <https://www.mediawiki.org/wiki/Talk:WikiDev17>

Ooops, I meant here: <https://www.mediawiki.org/wiki/Talk:Wikimedia_Developer_Summit_2017> Rob

Risker

4 Sep 4 Sep

9:17 p.m.

This topic is a great read, and as a non-developer who's interested in technical matters, I was quite excited to see this proposal. It might be an idea to identify one or two specific topics that may be particularly amenable to outreach to users outside of the "usual suspects" who attend the Dev Summit, and then actively recruit interested parties. It is quite possible that scholarships may be required to ensure a broader (i.e., more than English North Americans) participation, so this may be a budgetary issue that needs to be weighed against using those same scholarships for active developers. I think some of the comments on this thread are correct, that it's likely that at least some of the discussions at the Dev Summit will be too esoteric for non-developers. On the other hand, there was a point where I only understood about 3% of what was posted on this mailing list, and I think I can quite honestly say I'm all the way up to 25% now. People do learn by assimilation. :-) A similar process can be done with Wikimania - which has the added advantage of already attracting hundreds of community members for other reasons. I'd suggest that a special "developer/community day" be held in conjunction with the hackathon. While it's likely you'd still need to offer scholarships, in most cases it would be the cost of an additional day's accommodation/per diem rather than flight/accommodation/per diem, because you would target people who are already planning to attend Wikimania. I expect that the 2017 Wikimania will be one of the largest ones, since it is in North America and easily accessible by just about everyone, so there is likely to be a large target audience. You might want to work with Marc-Andre (who is the Wikimania Convenor) to see how this could be accommodated. Thanks Brion for raising the topic - and thanks to everyone in this thread, you've all taken this idea to heart and recognized the value of user input. Risker/Anne On 1 September 2016 at 13:12, Brion Vibber <bvibber(a)wikimedia.org> wrote:

...

Quim Gil

6 Sep 6 Sep

8:14 a.m.

Thank you for starting this conversation, Brion! Let me share the point where Rachel Farrand (Summit organizer) and I (Summit budget owner) find ourselves, after some conversations. GOALS First we need to define the goals of the Summit, then we can talk about the target audiences and the structure of the event that will help achieving these 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] 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. Still, even if we would have done better, "widening the audience" is not a goal per se. What should we widen the audience for? Here is an idea. 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. We have a Wikimedia Foundation Product department and also a Community Wishlist where the communities push for product improvements. We could set the goal of selecting (top down) a small number of product challenges and invite whoever needs to be involved to push them forward. Then we can leave plenty of free space for other topics that participants want to push (bottom up). That "we" should be representative and effective in order to define a list of goals in a few days (we need to open registration asap). It should be possible to get a short list from the Product and Technology departments, the Community Tech team (representing the Community Wishlist) and the Architecture Committee. Then again these product goals cannot be too surprising, since they are supposed to be prominent in discussions and plans already now. AUDIENCE If the Summit will focus on product goals, then it is evident that software architects and core developers will not be enough to achieve it. Product managers, UX designers, researchers, [add other roles here], and maybe even selected users/editors must be invited too in order to push the selected product improvements forward. But there is a problem: we have a capacity limit of 200 people. The Foundation alone could basically fill the event if we don't set limits, The Summit is immediately followed by the Wikimedia Foundation AllHands annual meeting. The Summit is actually the successor of Tech Days, an AllHands for all people who worked in tech at the Foundation. We do have some travel sponsorship budget for volunteers, and I believe we could get more participants among non-Wikimedia users of Wikimedia APIs and MediaWiki if we really want to target them. However, we simply cannot go for a big outreach while keeping an expectation of general attendance from Foundation's Product and Technology departments. Maybe we should go back to the invitation-only model with the capacity limit of 200 people in mind, and the representation of target audiences we want to get. For instance, we could set priorities on those directly involved in the product improvements selected (and that means that we need to select them asap) and define a % limit for Foundation participants. Basically, we would need to make some tough calls to define main goals and main audiences for the Summit in 2017. Successful events (just like successful products) are often the result of tough calls, so no surprise here. PS1: someone asked about lessons learned --> https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/Lessons_Lear… PS2: Rob suggested that a single email thread is not the best channel to solve this complex discussion and I agree with him... but I didn't want to kill this interesting thread either. Please note that the canonical places for Summit discussion are https://www.mediawiki.org/wiki/Talk:Wikimedia_Developer_Summit_2017 and the related Phabricator project task https://phabricator.wikimedia.org/project/board/2192/ [0] https://www.mediawiki.org/wiki/Wikimedia_Developer_ Summit_2017#Previous_summits On Sun, Sep 4, 2016 at 9:17 PM, Risker <risker.wp(a)gmail.com> wrote:

...

The last couple years we've done a big MediaWiki Dev Summit in January, around the time of the Wikimedia Foundation all-hands meeting.

Invitations

and

work on things that really matter to them. I want template authors, Lua module authors, template users, power

editors,

folks working on the lines of defense for vandalism patrol and copyvio checking. I want people with opinions on discussion systems. I want

people

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

Eran Rosenthal

3:40 p.m.

...

But there is a problem: we have a capacity limit of 200 people.

In hackthons (either Wikimedia hackathon or Wikimania hackthon days) there is not always a large enough hall for all the devs, and people may sit in different rooms. So the capability limit can be soften a bit - this could be a simultaneous event in multiple different locations where the main part take in SF, but Wikimedia chapters may organize in the same time smaller scale events (it could be even 1 room +pizza ++beer). We could set the goal of selecting (top down) a small number of product

...

challenges

One possible goal: Citations Citation support in MW is very hacky - based on hacks EVERYWHERE from parsoid, VE, ContentTranslation (tech) and template/modules (where every wiki have its own version/some version imported from enwiki...) I can imagine rewriting the Extension:Cite from scratch (Extension:CiteV2), with more structured data support (similar to in sense to Brion''s idea from Wikimania Mexico) - then the Wikidata support + importing /generating bibliographic data in wikidata (or other Wikibase repo?) takes part in Berlin where there is strong pywikibot/WD community, while Parsoid+VE+core/extension support for Cite takes place in SF. On Tue, Sep 6, 2016 at 9:14 AM, Quim Gil <qgil(a)wikimedia.org> wrote:

...

Thank you for starting this conversation, Brion! Let me share the point where Rachel Farrand (Summit organizer) and I (Summit budget owner) find ourselves, after some conversations. GOALS First we need to define the goals of the Summit, then we can talk about the target audiences and the structure of the event that will help achieving these 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] 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. Still, even if we would have done better, "widening the audience" is not a goal per se. What should we widen the audience for? Here is an idea. 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. We have a Wikimedia Foundation Product department and also a Community Wishlist where the communities push for product improvements. We could set the goal of selecting (top down) a small number of product challenges and invite whoever needs to be involved to push them forward. Then we can leave plenty of free space for other topics that participants want to push (bottom up). That "we" should be representative and effective in order to define a list of goals in a few days (we need to open registration asap). It should be possible to get a short list from the Product and Technology departments, the Community Tech team (representing the Community Wishlist) and the Architecture Committee. Then again these product goals cannot be too surprising, since they are supposed to be prominent in discussions and plans already now. AUDIENCE If the Summit will focus on product goals, then it is evident that software architects and core developers will not be enough to achieve it. Product managers, UX designers, researchers, [add other roles here], and maybe even selected users/editors must be invited too in order to push the selected product improvements forward. But there is a problem: we have a capacity limit of 200 people. The Foundation alone could basically fill the event if we don't set limits, The Summit is immediately followed by the Wikimedia Foundation AllHands annual meeting. The Summit is actually the successor of Tech Days, an AllHands for all people who worked in tech at the Foundation. We do have some travel sponsorship budget for volunteers, and I believe we could get more participants among non-Wikimedia users of Wikimedia APIs and MediaWiki if we really want to target them. However, we simply cannot go for a big outreach while keeping an expectation of general attendance from Foundation's Product and Technology departments. Maybe we should go back to the invitation-only model with the capacity limit of 200 people in mind, and the representation of target audiences we want to get. For instance, we could set priorities on those directly involved in the product improvements selected (and that means that we need to select them asap) and define a % limit for Foundation participants. Basically, we would need to make some tough calls to define main goals and main audiences for the Summit in 2017. Successful events (just like successful products) are often the result of tough calls, so no surprise here. PS1: someone asked about lessons learned --> https://www.mediawiki.org/wiki/Wikimedia_Developer_ Summit_2016/Lessons_Learned PS2: Rob suggested that a single email thread is not the best channel to solve this complex discussion and I agree with him... but I didn't want to kill this interesting thread either. Please note that the canonical places for Summit discussion are https://www.mediawiki.org/wiki/Talk:Wikimedia_Developer_Summit_2017 and the related Phabricator project task https://phabricator.wikimedia.org/project/board/2192/ [0] https://www.mediawiki.org/wiki/Wikimedia_Developer_ Summit_2017#Previous_summits On Sun, Sep 4, 2016 at 9:17 PM, Risker <risker.wp(a)gmail.com> wrote:

suspects"

who attend the Dev Summit, and then actively recruit interested parties.

is quite possible that scholarships may be required to ensure a broader (i.e., more than English North Americans) participation, so this may be a budgetary issue that needs to be weighed against using those same scholarships for active developers. I think some of the comments on this thread are correct, that it's likely that at least some of the

discussions

at the Dev Summit will be too esoteric for non-developers. On the other hand, there was a point where I only understood about 3% of what was

posted

on this mailing list, and I think I can quite honestly say I'm all the

way

up to 25% now. People do learn by assimilation. :-) A similar process can be done with Wikimania - which has the added advantage of already attracting hundreds of community members for other reasons. I'd suggest that a special "developer/community day" be held in conjunction with the hackathon. While it's likely you'd still need to offer scholarships, in most cases it would be the cost of an additional day's accommodation/per diem rather than flight/accommodation/per diem, because you would target people who are already planning to attend Wikimania. I expect that the 2017 Wikimania will be one of the largest ones, since it is in North America and easily accessible by just about everyone, so there is likely to be a large target audience. You might

want

to work with Marc-Andre (who is the Wikimania Convenor) to see how this could be accommodated. Thanks Brion for raising the topic - and thanks to everyone in this

thread,

you've all taken this idea to heart and recognized the value of user input. Risker/Anne On 1 September 2016 at 13:12, Brion Vibber <bvibber(a)wikimedia.org>

wrote:

The last couple years we've done a big MediaWiki Dev Summit in January, around the time of the Wikimedia Foundation all-hands meeting.

Invitations > have been fairly broad to known developers, but there's a very strong > feeling that newbies, non-technical people, and in general *the people > MediaWiki is created and maintained for* are not welcome. > > I think we should change this. > > I would really like a broader MediaWiki Dev Summit that asks our users

participate, and asks "developers" to interact with them to prioritize

and

work on things that really matter to them. I want template authors, Lua module authors, template users, power

editors,

folks working on the lines of defense for vandalism patrol and copyvio checking. I want people with opinions on discussion systems. I want

people

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Brad Jorsch (Anomie)

5:07 p.m.

On Tue, Sep 6, 2016 at 2:14 AM, Quim Gil <qgil(a)wikimedia.org> wrote:

...

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.

IMO that depends on what you define as "product". In the sense that MediaWiki and Wikipedia are products, sure. In the more narrow sense dealt with by the WMF's Product department, perhaps not. -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation

Toby Negrin

6:49 p.m.

On Tue, Sep 6, 2016 at 8:07 AM, Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org> wrote:

...

with by the WMF's Product department, perhaps not.

I'd be happy to talk about Reading's roadmap and discuss the technical implications[1]. I could also go over some of the user research we just did in Mexico, Nigeria and India[2] and what it might mean for the future. I'd also second suggestions to look at the Community Tech wishlist. There are a lot of useful, challenging problems to take on that didn't make the top 10 but could use some attention. -Toby [1] https://www.mediawiki.org/wiki/Reading/Strategy/2016-2017_plan [2] https://meta.wikimedia.org/wiki/New_Readers [3] https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results

Rob Lanphier

5:55 p.m.

On Mon, Sep 5, 2016 at 11:14 PM, Quim Gil <qgil(a)wikimedia.org> wrote:

...

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.

...

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.

...

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

...

We have a Wikimedia Foundation Product department and also a Community Wishlist where the communities push for product improvements.

The Community Wishlist seems like a great item to highlight (again) this year.

...

We could set the goal of selecting (top down) a small number of product challenges and invite whoever needs to be involved to push them forward. Then we can leave plenty of free space for other topics that participants want to push (bottom up). [...] AUDIENCE [...] Product managers, UX designers, researchers, [add other roles here], and maybe even selected users/editors must be invited too in order to push the selected product improvements forward. But there is a problem: we have a capacity limit of 200 people. The Foundation alone could basically fill the event if we don't set limits, The Summit is immediately followed by the Wikimedia Foundation AllHands annual meeting. The Summit is actually the successor of Tech Days, an AllHands for all people who worked in tech at the Foundation.

That's obviously the primary challenge we're faced with. Given that we can't invite all 5 billion or so stakeholders, we're going to have to figure out how to narrow the scope of invitations, and accomplish great things with a smaller audience. My proposal: let's make the scope of invitations be "participants in wikitech-l". Wikitech-l has long been our "paper of record" for Wikimedia technical decision making. To the extent that causes us to ask the question "ok, what's the goal of wikitech-l?", then I think that makes this a success. We only hold WikiDev once a year, but wikitech-l is active all year long. Let's figure out why we're using this mailing list to write messages at each other.

...

Basically, we would need to make some tough calls to define main goals and main audiences for the Summit in 2017. Successful events (just like successful products) are often the result of tough calls, so no surprise here.

Yes. I'm looking to our Engineering Community Manager to create a great Engineering meeting.

...

PS1: someone asked about lessons learned --> https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/Lessons_Lear… PS2: Rob suggested that a single email thread is not the best channel to solve this complex discussion and I agree with him... but I didn't want to kill this interesting thread either. Please note that the canonical places for Summit discussion are https://www.mediawiki.org/wiki/Talk:Wikimedia_Developer_Summit_2017 and the related Phabricator project task https://phabricator.wikimedia.org/project/board/2192/ [0] https://www.mediawiki.org/wiki/Wikimedia_Developer_ Summit_2017#Previous_summits

My comments at Talk:Wikimedia_Developer_Summit_2017 don't have any responses as of this writing. Clearly, I said nothing uncontroversial there :-P Rob p.s. the rest of this thread is archived here <https://lists.wikimedia.org/pipermail/wikitech-l/2016-September/thread.html#86394>. I *almost* didn't trim out Risker's very thoughtful reply, but I did. Please find it in the archive.

Quim Gil

7 Sep 7 Sep

1:24 p.m.

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]

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

to Wikimedia (not MediaWiki) Developer Summit, and we invited developers

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.

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

Rob Lanphier

8:45 p.m.

Hi Quim, Thanks for the response, and thanks for responding for my request to talk about this at the upcoming IRC meeting: <https://phabricator.wikimedia.org/T141938#2613005> I've got a lot of thoughts about your response, but I'm going to zero in on the central thing that's confusing me (paraphrasing liberally inline below): On Wed, Sep 7, 2016 at 4:24 AM, Quim Gil <qgil(a)wikimedia.org> wrote:

...

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. [...] 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. [...] [making the scope of invitations be "participants in wikitech-l". 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.

It's hard for me to read this as anything but "WMF Product selects the topics, and then 'listens' for objections on wikitech-l". That seems the opposite of "opening up" to me, but rather seems to be about disintermediating wikitech-l discussion. Is your sense that the correct direction for us is for someone to provide more top-down direction instead of wikitech-l conversation? I'm going to repeat my rationale for wanting to emphasize wikitech-l. Wikitech-l has long been our "paper of record" for Wikimedia technical decision making. To the extent that causes us to ask the question "ok, what's the goal of wikitech-l?", then I think that makes this a success. We only hold WikiDev once a year, but wikitech-l is active all year long. Let's figure out why we're using this mailing list to write messages at each other. Rob

Quim Gil

8 Sep 8 Sep

1 a.m.

On Wed, Sep 7, 2016 at 8:45 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:

...

It's hard for me to read this as anything but "WMF Product selects the topics, and then 'listens' for objections on wikitech-l".

Since this is not even remotely what I am trying to say, let me try again, while I keep iterating on the proposal: The organizers of the Summit propose to have a few main topics defined beforehand, so we can invite the people beyond the usual Summit participants that should be involved in these discussions. We don't have any opinion about which topics should be selected. However, we believe that it is important to choose complex topics with a high user impact (direct or indirect) and ramifications in multiple technical areas. The Summit with its +200 participants provides a great framework to push these topics. We don't have any opinion about who decides these topics and how. However, we need good enough answers and fast, so we can start organizing the participation and the program. There will be time to fine tune things as we go, and there will be enough space for all the topics not selected beforehand, in the unconference part of the Summit. We believe that by having the right people focusing on a few main topics before and during the Summit, the outcome of the event will have a clearer impact in the strategy and goals that ultimately drive where we put a lot of our attention and resources. Is your sense that the

...

correct direction for us is for someone to provide more top-down direction instead of wikitech-l conversation?

My sense is that we need to open registration, call for participation, and call for travel sponsorship requests as soon as possible. This list, the Architecture committee, the WMF Technology management team, and the WMF Product management team are aware of this situation and our request to define main topics. I will be checking with all these sources with the goal of having a good enough answer that allows us to move forward with the Summit organization. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

Nuria Ruiz

4:53 p.m.

...

The organizers of the Summit propose to have a few main topics defined beforehand, so we can invite the people beyond the usual Summit participants that should be involved in these discussions.

...

We don't have any opinion about which topics should be selected. However, we believe that it is important to choose complex topics with a high user impact (direct or indirect) and ramifications in multiple technical areas. The Summit with its +200 participants provides a great framework to push these topics.

I think this idea is inline with how most tech conferences work. In order for the summit to be successful we should know what type of event we are creating (purely technical, a venue to explore user requests, a venue to influence product roadmap, just "get in touch"... whatever) Seems that defining what areas we want to cover in the summit is a prerequisite to do what Brion was asking for in the initial e-mail, to open the summit beyond WMF. On Wed, Sep 7, 2016 at 4:00 PM, Quim Gil <qgil(a)wikimedia.org> wrote:

...

On Wed, Sep 7, 2016 at 8:45 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:

It's hard for me to read this as anything but "WMF Product selects the topics, and then 'listens' for objections on wikitech-l".

correct direction for us is for someone to provide more top-down direction instead of wikitech-l conversation?

Rob Lanphier

7:57 p.m.

On Thu, Sep 8, 2016 at 7:53 AM, Nuria Ruiz <nuria(a)wikimedia.org> wrote:

...

Seems that defining what areas we want to cover in the summit is a prerequisite to do what Brion was asking for in the initial e-mail, to open the summit beyond WMF.

Good point. Let's say that we had to pick only one of these questions to answer at WikiDev17. Which would you choose? * how do we make manipulating the information on our websites easier and more useful? (both for humans and computers) * how can we better distribute the information on our websites? * how can we help our software development community be more inclusive and productive (and attract many more people)? * how can we improve the quality of our software, and pay down the technical debt we've accumulated over the years? * how can we make our websites better learning environments? * how can we make our websites better support languages other than English (and character sets other than Latin)? Rob

C. Scott Ananian

14 Sep 14 Sep

8:54 p.m.

On Thu, Sep 8, 2016 at 1:57 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:

...

Good point. Let's say that we had to pick only one of these questions to answer at WikiDev17. Which would you choose?

All of them! But since no one else bit Rob's bait, let me try to give a pro/con for each. * how do we make manipulating the information on our websites easier and

...

more useful? (both for humans and computers)

Pro: a very broad topic, most reasonable subjects of discussion could fit under this umbrella. CF Cite, multilingual support, wikidata-in-commons, etc. Con: a very broad topic, would this even be a useful frame?

...

* how can we better distribute the information on our websites?

Pro: invites radical thought disconnected from monetary/fundraising needs! How can we get everyone to use our stuff? We collectively probably haven't thought hard about this recently. Con: not related to most of the other proto-topics I've heard floated. Maybe more of a "strategy" topic than a "dev" topic.

...

* how can we help our software development community be more inclusive and productive (and attract many more people)?

Pro: again, big thoughts, on a topic which deserves attention. Can drill down into nitty-gritty like, "why not github?" and "can we make the review process more friendly?" which are favorite topics for fat-chewing among developers. Con: again maybe more "strategy" than "dev"; doesn't help us discuss wikidata or refactoring the front-end. Also, why "software development community more inclusive" and not "editor community more inclusive"? The sharp division there might be a real issue.

...

* how can we improve the quality of our software, and pay down the technical debt we've accumulated over the years?

Pro: again, a favorite topic of talk-over-beers among developers. One could imagine a whole summit devoted to going through our software stack component by component, identifying the cruft hidden in each, and making concrete plans to banish it. Con: this opinion might be controversial, but my impression is that we're actually pretty good at low-level refactoring. There are plenty of things we are hesitant to change (say, wikitext syntax!), but I don't get the feeling that the barrier is in engineering. The problem is mostly a management one: how can engineering communicate the time spend and value added by "invisible" maintenance and refactoring; how can we get management to allocate more dedicates resources to this? I don't think there's much technical debate about what to work on, if we had the resources to do so. * how can we make our websites better learning environments?

...

Pro: another radical idea, and I like radical ideas. ;) Con: We have wikiversity for this. Yes, it has its problems. But wouldn't this topic be better phrased as, "how can we better support wikiprojects other than wikipedia?" > * how can we make our websites better support languages other than English > (and character sets other than Latin)?

...

Pro: I feel like this was deliberately aimed at me, and I like it. ;) It would serve as a concrete frame to recruit new participants from outside enwiki/SFO. Con: Do I have to argue against my own pander? ... Ok, ok. Con: the typical attendees of a SFO dev summit are not really the best folks to discuss non-English/non-Latin issues. It might be worthwhile doing as an "educate SFO developers about the issues" training summit, but if you actually wanted to set goals/make progress you should really host this topic at a non-North-American Wikimania. ========= Ok, so what have we learned from this? Even if others have different opinions about each of Rob's proposed topics, which are the *sort* of things we'd like the dev summit to be about? Radical ideas? Stuff developers bitch over beers about? Vague umbrella topics ("make wiki easier to use") that we can crowd a bunch of stuff under? Something else entirely? --scott -- (http://cscott.net)

MZMcBride

15 Sep 15 Sep

1 a.m.

C. Scott Ananian wrote:

...

On Thu, Sep 8, 2016 at 1:57 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:

Let's say that we had to pick only one of these questions to answer at WikiDev17. Which would you choose?

All of them! But since no one else bit Rob's bait, let me try to give a pro/con for each.

I considered taking the bait. I read the questions, but my primary thought was "man, this guy seems way overdue to submit a Gerrit patch or do something less highfalutin."

...

* how can we better distribute the information on our websites?

Pro: invites radical thought disconnected from monetary/fundraising needs! How can we get everyone to use our stuff? We collectively probably haven't thought hard about this recently.

Plenty of people have given this thought. Offline reading, printed editions, putting Wikipedia on the Moon, Wikipedia Zero, etc. We can do more, of course, but that's true of everything.

...

* how can we help our software development community be more inclusive and productive (and attract many more people)?

Wikimedia-related Git repositories are on GitHub. If we want to attract more people, that requires figuring out how to scale up the already shaky code review process.

...

* how can we improve the quality of our software, and pay down the technical debt we've accumulated over the years?

I think this problem exists in most companies/organizations. Nobody wants to pay down technical debt; building new features is a lot more exciting.

...

* how can we make our websites better learning environments?

Yes, that's better phrasing. But it's still too vague to be useful. As I read this question, I hear your comments about "strategy" v. "dev" echoing around in my head. How we can better support non-Wikipedia projects might mean setting them free/abandoning them.

...

Ok, so what have we learned from this? Even if others have different opinions about each of Rob's proposed topics, which are the *sort* of things we'd like the dev summit to be about? Radical ideas? Stuff developers bitch over beers about? Vague umbrella topics ("make wiki easier to use") that we can crowd a bunch of stuff under? Something else entirely?

In my experience, the greatest value derived from these types of events (summits, hackathons, unconferences, whatever other cutesy word) is having unstructured time to explore and think and poke and discuss with people about pet projects and other neat ideas. The structured and more formal sessions, with their broad themes for whatever year it is, are usually boring and ill-fitting. MZMcBride

Chad

1:54 a.m.

On Wed, Sep 14, 2016 at 4:01 PM MZMcBride <z(a)mzmcbride.com> wrote:

...

* how can we improve the quality of our software, and pay down the technical debt we've accumulated over the years?

I think this problem exists in most companies/organizations. Nobody wants to pay down technical debt; building new features is a lot more exciting.

Bummer. I think paying down tech debt is fun and way more rewarding than making shiny new things. But I'm also weird as hell...

...

This. I usually find myself skipping most sessions. One of two things happen: 1) You sit there and listen to someone else talk to you, or 2) It's ostensibly a group discussion, but the group is too big and nothing useful gets discussed because you spend too much time listening to 30 different voices. (1) bores me to tears. (2) is basically useless. -Chad

Daniel Kinzler

10:09 a.m.

Am 15.09.2016 um 01:54 schrieb Chad:

...

Bummer. I think paying down tech debt is fun and way more rewarding than making shiny new things. But I'm also weird as hell...

/me waves to a kindred soul. -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.

Rob Lanphier

6:53 p.m.

On Thu, Sep 15, 2016 at 1:09 AM, Daniel Kinzler <daniel.kinzler(a)wikimedia.de> wrote:

...

Am 15.09.2016 um 01:54 schrieb Chad:

Bummer. I think paying down tech debt is fun and way more rewarding than making shiny new things. But I'm also weird as hell...

/me waves to a kindred soul.

This seems apropos: https://vimeo.com/121290570 It's good Hollywood is finally paying attention to our people. Rob

Daniel Kinzler

9:42 p.m.

Am 15.09.2016 um 18:53 schrieb Rob Lanphier:

...

On Thu, Sep 15, 2016 at 1:09 AM, Daniel Kinzler <daniel.kinzler(a)wikimedia.de> wrote:

Am 15.09.2016 um 01:54 schrieb Chad:

Bummer. I think paying down tech debt is fun and way more rewarding than making shiny new things. But I'm also weird as hell...

/me waves to a kindred soul.

This seems apropos: https://vimeo.com/121290570 It's good Hollywood is finally paying attention to our people.

Haha, excellent! -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.

Bináris

17 Sep 17 Sep

7:27 a.m.

2016-09-15 18:53 GMT+02:00 Rob Lanphier <robla(a)wikimedia.org>rg>:

...

This seems apropos: https://vimeo.com/121290570 It's good Hollywood is finally paying attention to our people.

Made my day! :-D -- Bináris

Quim Gil

20 Sep 20 Sep

9:12 a.m.

Robla and I are trying to nail down the main topics that will bootstrap the Summit in the next days. Please join the discussion until we make a decision (and beyond if you wish, of course): https://www.mediawiki.org/wiki/Topic:Tb6bztglijowk8x3 Remember that at least 50% of time and space will be dedicated to an Unconference setup that will allow the discussion to any other topic not making it to this short list. On Sat, Sep 17, 2016 at 7:27 AM, Bináris <wikiposta(a)gmail.com> wrote:

...

2016-09-15 18:53 GMT+02:00 Rob Lanphier <robla(a)wikimedia.org>rg>:

This seems apropos: https://vimeo.com/121290570 It's good Hollywood is finally paying attention to our people.

Made my day! :-D -- Bináris _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

C. Scott Ananian

7:05 p.m.

Here are three topic suggestions, cc'ed here in case folks aren't following the Flow, with an illustrative (but not exhaustive) list of sessions that could fit under each: *1. *(A unified vision for) *Collaboration* - Real-time collaboration (not just editing, but chatting, curation, patrolling) - WikiProject enhancements: User groups, finding people to work with, making these first class DB concepts - Civility/diversity/inclusiveness, mechanisms to handle/prevent harassment, vandalism, trolling while working together - Real-time reading -- watching edits occur in real time - Integration with WikiEdu - Broadening notion of "an edit" in DB -- multiple contributors, possibly multiple levels of granularity - Tip-toeing toward "draft"/"merge" models of editing - Better diff tools: refreshed non-wikitext UX, timelines, authorship maps, etc. *2. *Improving* Modular Wikitext Maintenance* - Infoboxes from wikidata, categories from wikidata, wikidata in commons, oh my! - Visual editing of templates, alternative template mechanisms, etc - Wikitext 2.0 -- how to shave off the rough edges but still provide a text-based power-user editing interface - Global pages, Global templates, etc - Improving composition of text and media content on the page - Moving to a Glossary model for LanguageConverter rules - Splitting metadata (categories, page flags, etc) from content in the DB *3. *(Doubling down on)* Machine Translation* - Annotation service to record fine-grained translation correspondences between wikis over time (not just at the time of first translation) - Suggestion service to suggest new edits to wiki A when translated text wiki B is modified (or vice-versa) - Refactoring existing language converter pairs as (sometimes trivial) translation engines, eg cyrillic-to-latin - Building a translation engine in house, training it with translated wiki pages, improving it over time, etc - Tightly integrating the translation UX for everyone. More: one community wearing babel fishes / Less: scattered villagers after the Tower of Babel fell. - Improving harassment/vandalism/civility/inclusiveness/diversity mechanisms to handle these larger cross-cultural communities. - i18n of global pages, global templates, etc. May need mechanisms to allow translation of comments, for example. --scott -- (http://cscott.net)

Legoktm

15 Sep 15 Sep

7:06 p.m.

New subject: Cleaning up ContentHandler technical debt (was Re: Opening up MediaWiki dev summit in January?)

On 09/15/2016 01:09 AM, Daniel Kinzler wrote:

...

Am 15.09.2016 um 01:54 schrieb Chad:

Bummer. I think paying down tech debt is fun and way more rewarding than making shiny new things. But I'm also weird as hell...

/me waves to a kindred soul.

Lovely! I just filed about 20 tasks on cleaning up ContentHandler's technical debt (you know, just in time to rewrite it all over again), help would be appreciated! <https://phabricator.wikimedia.org/T145728>. -- Legoktm

Daniel Kinzler

9:38 p.m.

New subject: Cleaning up ContentHandler technical debt (was Re: Opening up MediaWiki dev summit in January?)

Am 15.09.2016 um 19:06 schrieb Legoktm:

...

On 09/15/2016 01:09 AM, Daniel Kinzler wrote: Lovely! I just filed about 20 tasks on cleaning up ContentHandler's technical debt (you know, just in time to rewrite it all over again), help would be appreciated! <https://phabricator.wikimedia.org/T145728>. -- Legoktm

I'm happy to work on stuff like this if I can team up with someone who will review my stuff quickly. For a task like this, the same day would be best. Working on core has been extremely frustrating, with review latency measured in weeks and months. Feel like doing a sprint with me? -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.

2782

days inactive

2801

days old

wikitech-l@lists.wikimedia.org

Manage subscription

37 comments

21 participants

tags (0)

participants (21)

bawolff
Bináris
Brad Jorsch (Anomie)
Brian Wolff
Brion Vibber
C. Scott Ananian
Chad
Daniel Kinzler
Eran Rosenthal
Legoktm
Matthew Flaschen
Melody Kramer
MZMcBride
Nuria Ruiz
Pine W
Quim Gil
Risker
Rob Lanphier
Russell Uman
Toby Negrin
Tony Thomas