I propose:

1. VisualEditor table editor and citoid bugfixes and feature development

2. Major modernization of desktop interface design, perhaps aligned with https://www.mediawiki.org/wiki/Athena

3. Extension:Newsletter development, bugfixing and deployment to all wikis.

Note @Qgil that Lyon is mentioned twice and Mexico City is not mentioned in the task description.

Thanks @Pine (feel free editing the task description yourself the next time, wiki-style). :)

In T89084#1027271, @Pine wrote:

I propose:

1. VisualEditor table editor and citoid bugfixes and feature development

CCing @Jdforrester-WMF and @Mvolz

2. Major modernization of desktop interface design, perhaps aligned with https://www.mediawiki.org/wiki/Athena

CCing @Jaredzimmerman-WMF and @TrevorParscal

3. Extension:Newsletter development, bugfixing and deployment to all wikis.

As proponent of T76199: Goal: Newsletter extension for MediaWiki, I wish this would be a realistic proposal. An Individual Engagement Grant or a small focused hackathon of 3-5 people somewhere might be a better fit for this. Still, let me CC @Quiddity and @Eloquence since they have also shown interest on this feature (that I still believe we really need).

Looking at https://old-bugzilla.wikimedia.org/showdependencytree.cgi?id=65005&maxdepth=1&hide_resolved=0 , i18n is one of the most productive areas for the hackathon.

Services!

There was a lot of discussion about services at the dev summit, and by the time of the hackathon, RESTBase should've been deployed and my team (Mobile Apps) should've got a prototype of a mobile apps content service working. I'm sure there'll be tons more to discuss at the hackathon.

In T89084#1028187, @Deskana wrote:

Services!

There was a lot of discussion about services at the dev summit, and by the time of the hackathon, RESTBase should've been deployed and my team (Mobile Apps) should've got a prototype of a mobile apps content service working. I'm sure there'll be tons more to discuss at the hackathon.

Do we have a particular ask around Services? @GWicke?

@Lydia_Pintscher, what if we make Wikidata the star of the Hackathon in Lyon?

Heh I'm all for it obviously.

It was suggested (by _joe_ and some of the ops staff) that "PHP thumbnailer as a service" was something we could hack on in Lyon.

Would it make sense for a theme to focus more on an outcome than a specific technology or implementation?

For example, rather than "Services", a theme might be "Mobile Editing Performance", and folks could choose to hack on one of many supporting projects, such as a new extension to api.php, or an optimization in the mobile app or mobile Web site, or a new customizable service that uses RESTBase for storage, etc.

It might be interesting to be able to compare and contrast (or even combine) multiple different approaches to achieving the outcome, and would outline a clear user-facing context with which to gauge success.

In T89084#1029308, @cscott wrote:

It was suggested (by _joe_ and some of the ops staff) that "PHP thumbnailer as a service" was something we could hack on in Lyon.

+1. In the 3 days the best we could probably reasonably hope for would be a cut-n-paste code to a new repo proof of concept but just doing that would be a really interesting exercise in determining if library extraction could be used later to create something more production worthy. I like the idea of a PoC of a PHP service in general and this one is something that we could really use today.

I'd love to spend some time hacking on Phabricator. Some project ideas:

• Improving on burndown chart-related functionality (this could be a great time to knowledge-share with @Christopher and start taking the burndown functionality to where we need it to be for WMF teams)
• Implement a matrix view with dependency management/Scrum of Scrums as the guiding use-case to more easily at-a-glance identify interdependencies between teams (like what we used to get with Mingle)
• Implement the ability to change the status of all tasks in a particular column on a workboard
• Implement the ability to query tasks based on their workboard column
• Work on auto-update features (eg auto-update workboards without having to refresh as tasks get added/removed/moved, auto-update tasks as they are being edited/comments added/etc)

I'd love to see work by @kaldari (and myself?) on a better tool for reporting abusive users and content on wiki, as well as a connected backend tool that helps communities better triage the incoming reports.

@Pine / @Qgil there won't be any work specifically in the direction of Athena, however @Prtksxna is working both on Blueprint (skin for documentation) and MediaWiki-skins-Slate (a responsive skin based on the ideas from the Winter prototypes) I'd be happy to see him work on either or both, but I'm not going to nominate him for it at the hackathon unless he's interested.

@cscott if we're already processing a huge database of thumbnails it would be great to also pass them though something like https://github.com/lokesh/color-thief/ as well.

@Jaredzimmerman-WMF The idea is to pull the PHP thumbnailer code from core with as few changes as possible. So if color-thief integration lands in core before the hackathon, then it will also live in the new thumbnailer service!

In T89084#1033592, @Jaredzimmerman-WMF wrote:

@Pine / @Qgil there won't be any work specifically in the direction of Athena, however @Prtksxna is working both on Blueprint (skin for documentation) and MediaWiki-skins-Slate (a responsive skin based on the ideas from the Winter prototypes) I'd be happy to see him work on either or both, but I'm not going to nominate him for it at the hackathon unless he's interested.

This sounds like a good idea but I am not sure if I want to commit it to it right now.
@Qgil, by when do we freeze this?

I don't know about "main theme", but I'd love to take T89188 to the hackathon as a fundraising project.

Suggestion: "Finding new ways to get people engaged with our projects."

Let's define the plan for Lyon first.

I propose to focus on the activities that can pull newcomers to our hackathons: local developers, international developers invited, and insightful users.

We can think of experience paths for these areas, starting with basic training and easy tasks on Day 1, and moving onto more serious hacking during the rest of the event (for those willing to follow).

Each of these areas should have an interesting project with a catchy title that would act as attractor and umbrella for other activities in that area. I suspect having a task and an owner for each area is going to be useful as well.

Wikidata is a clear candidate. Interesting project, plenty of potential for demos, several points of entry, the team will be there... On the deeper front, @Manybubbles and the Wikidata team are trying to work on Search , and I wonder if both areas could be combined, inviting whoever appropriate from Elasticsearch or other relevant upstream projects. Open data and open search in the context of Wikip/media can be a good call for developers in France and surroundings.

The entire Release Engineering team will be in Lyon, and we should take advantage of this. Can we organize an area around MediaWiki releases improving the internal vs 3rd party situation? We had many open ends at the MediaWiki Developer Summit on extension management, impact of Services in 3rd party installs, MediaWiki in the cloud...

Also, can we organize something around Quality, with an eye put on groups of QA testers and the upstream communities powering our QA toolchain?

The Editing area is well represented (with VisualEditor deployed everywhere as main mission), @Jdlrobson is pushing strong the discussion on new ways of editing/contributing, and again the Wikidata perspective could add critical mass here as well. This looks like another fruitful area where we could invite local expert editors as well as heavy Wikipedia users that have never edited, and again the open data crowd (WMFR could help with the recruiting).

Mobile apps has been complaining about lack of contributors and some isolation. I bet finding Android and iOS developers in Lyon and surroundings shouldn't be a problem, if we have something interesting for them. Mobile and hackathons is a cocktail known to produce interesting results, if there is some inspiration and preparation.

A hackathon is also a place ideal for Wikimedia Labs. Beyond the obvious and needed training and support at the event, there could be an ambitious goal for improving Labs itself. Also, the Tools Labs community is strong in Europe, and we could make a call for a specific gathering there.

i18n is indeed a strong aspect of the Wikimedia Hackathon EU. It is also a good area for newcomers, especially when having so many speakers of different languages. Looking at the proposals we can see RTL specific work, which suggests that we could also reach out to Arabic and Hebrew speakers (developers, editors; locally and in the Mediterranean context).

HHVM, it seems that something is cooking up, but let's wait @ori to provide more details.

There is space for more, of course. I don't think we should put a filter a priori, we can just define a requirement for critical mass and completeness in order to be promoted as a main area of the event. For instance, we could have this table, and see who can fill an entire row with Phabricator tasks:

I'd really like to see design and design research included in the scope for major hackathons like this one. Is that possible?

Here we only aim to discuss the main themes, which require a significant presence of related teams at the event. We cannot afford sending everybody to Lyon and Mexico DF, and it seems that the Design team is leaning more toward Wikimania as a group. Then again, this is currently just my assumption. @Jaredzimmerman-WMF might know better, and @aripstra might or might not have plans to repeat T86792: workshop on design research in product development at developer summit or organize another design research activity in any of these events.

On a deeper level that perhaps belongs to an own task... One thing is to embed the design effort in hackathon projects, and another thing is to make Design in itself a theme. The latter option would require specific outreach effort for designers, who might not feel attracted by the idea of a hackathon at the same level of a developer, unless there is something clearly targeted for them. We have discussed the possibility of organizing smaller hackathons or sprints, focused on a specific area, and perhaps this format also has possibilities for Design-centric events.

I added the table for Wikidata to the description.

In T89084#1029481, @bd808 wrote:

In T89084#1029308, @cscott wrote:

It was suggested (by _joe_ and some of the ops staff) that "PHP thumbnailer as a service" was something we could hack on in Lyon.

+1. In the 3 days the best we could probably reasonably hope for would be a cut-n-paste code to a new repo proof of concept but just doing that would be a really interesting exercise in determining if library extraction could be used later to create something more production worthy. I like the idea of a PoC of a PHP service in general and this one is something that we could really use today.

Thumbnailer seems kind of like a poor choice for this, unless we plan to break compatibility with the current extension API - or - we want to only use it for certain types of thumbnails and then fallback to normal mediawiki for others in which case I'm not sure what the point is.

In T89084#1088753, @Bawolff wrote:

In T89084#1029481, @bd808 wrote:

In T89084#1029308, @cscott wrote:

It was suggested (by _joe_ and some of the ops staff) that "PHP thumbnailer as a service" was something we could hack on in Lyon.

+1. In the 3 days the best we could probably reasonably hope for would be a cut-n-paste code to a new repo proof of concept but just doing that would be a really interesting exercise in determining if library extraction could be used later to create something more production worthy. I like the idea of a PoC of a PHP service in general and this one is something that we could really use today.

Thumbnailer seems kind of like a poor choice for this, unless we plan to break compatibility with the current extension API - or - we want to only use it for certain types of thumbnails and then fallback to normal mediawiki for others in which case I'm not sure what the point is.

I don't know if there is a well articulated goal on wiki or in Phabricator at this point, but I can relay my ideas based on conversations that I had with the WMF Operations team in January. This would not be (at least in the initial deployable increment) a general purpose service that could handle the needs of any MediaWiki installation. The basic idea would be to create a stand-alone service that is tailored specifically to the needs of the current WMF production cluster. Thumbnails are a hook point that feels like it can be readily adapted to the idea that MediaWiki can be scaled for larger deployments by replacing general purpose code paths with specific tailored implementations at deploy time. One way to think of this is the ultimate expression of the single responsibility principle.

Please move the discussion about Thumbnailer to T91104: PHP thumbnailer as a service or wherever corresponds.

On the main themes, the approach proposed at T89084#1065426 is working out. Wikidata and Mobile Apps have stepped in. There is clearly a critical mass of participation from Editing tools, MediaWiki releases, and Quality, since the related WMF teams are organizing their off-sites close to the event. Labs is another area that can and should be promoted, considering that so many Labs users are based in Europe.

In the following days I will work with the main contacts of these areas to publish the highlights and best links in https://www.mediawiki.org/wiki/Lyon_Hackathon_2015, and to discuss the best promotion that we can do to attract participants.

Er... sorry, I forgot that this task included Wikimania as well. It made sense when I created it, and perhaps it is a good idea looking at the subscribers we have. In any case, the Wikimedia Hackathon part is quite clear at this point, and it is a bit early to start working on the Wikimania part.