Talk:Wikimedia Engineering/2014-15 Goals

Successful Wikimedia Hackathon USA
How comes? Is there a proposal for one from someone? I don't see any in Hackathons. --Nemo 08:00, 10 June 2014 (UTC)
 * , there has been some discussions at the WMF about merging the Architecture Summit 2014 with the WMF Tech Days, recovering the San Francisco Hackathon spirit somehow. This would continue to open up the Engineering gatherings in SF and would save quite a lot of $$$ in travel compared to the current situation. Rachel Farrand is the owner of this project which is in its very initial state. Right now she is looking for potential dates in January 2015 and venues in San Francisco. We will create a planning page as soon as we have time and place confirmed. Before that, this idea is almost vaporware.--Qgil (talk) 15:33, 13 June 2014 (UTC)
 * Ah right, that event. I remember the merge but I didn't know it was called "Hackathon USA". :) Keeping the "San Francisco Hackathon" name may work better (as it recalls the WMF offices), dunno. --Nemo 16:28, 13 June 2014 (UTC)

Flow - translatewiki
I have no idea what the bullet "translatewiki.net" could mean in the second quarter. If it means i18n, that's absurd: i18n can't come after the "Deployment" planned for the previous quarter. --Nemo 08:04, 10 June 2014 (UTC)
 * As it is under the 'Deployment' section, I assume it means deployment of Flow to translatewiki.net, which is currently using LQT. -- Krenair (talk &bull; contribs) 19:20, 13 June 2014 (UTC)
 * Yes, that's correct. Sorry that was unclear. DannyH (WMF) (talk) 20:11, 13 June 2014 (UTC)
 * Does this mean you'll also take care of making Flow work with Translate and our translatewiki:Template:Support system, based on LQT threads summaries and other LQT features like thread moves and notifications + SemanticMediaWiki and categories, as well as convert the thousands previous threads and ensure links from commit messages and bug reports don't break? --Nemo 20:56, 13 June 2014 (UTC) P.s.: At any rate you're missing, in "Interdependencies", the need to get the required privileges, authorisation and supervising by Nikerabbit.
 * Hard to say. We haven't gotten to Q2 yet. :) As I noted in the Q1 section: "All deployment ideas are preliminary; actual rollout depends on conversations with staff and community stakeholders." Last month, Siebrand told me that he was interested in moving translatewiki's discussions from Liquid Threads to Flow, when Flow was ready for it. That's the only conversation we've had about it so far. There will be a lot of details to figure out and work on, for translatewiki and any other possible deployment plans. DannyH (WMF) (talk) 21:05, 13 June 2014 (UTC)

new mobile active editor
Definition please. --Nemo 08:29, 10 June 2014 (UTC)
 * Is a "new active editor" one that we previously didn't get (i.e. which produces an increase in totals for Wikipedia et al.)?
 * Is a "mobile editor" one who did their first edit on mobile? Registration and all edits on mobile? A majority of edits on mobile? Registration on mobile and edits wherever?


 * From this, I would guess a mobile active editor is someone who registered on mobile and hits the 5+ edits/month irrespective of device. -Tychay (talk) 19:13, 13 June 2014 (UTC)


 * Thanks, this is useful. Please link the definition from the text if you're sure. Still missing definition for the "new" part. --Nemo 21:06, 13 June 2014 (UTC)

Auto-archiving existing talk pages when Flow is turned on
What does this mean? Does it mean what it literally says, that existing talk pages will be archived when Flow is turned on, leaving a talk page with only headers? Dougweller (talk) 17:55, 10 June 2014 (UTC)


 * See for example Talk:Beta Features/Nearby Pages which has this done. Jdforrester (WMF) (talk) 18:07, 10 June 2014 (UTC)


 * Thanks but I don't see how that answers my question. At the time Flow is turned on, will all talk pages be blanked due to archiving? What I do see is another problem in that the history of Talk:Beta Features/Nearby Pages doesn't include the archive. I don't think that would be acceptable. Dougweller (talk) 08:10, 11 June 2014 (UTC)


 * Sorry, that bullet point is unclear -- I'll edit and explain that better. What we need to do is just build the ability for the team to auto-archive a talk page when we turn Flow on, still on a page-by-page basis. We're not at the stage where we're ready to archive a whole namespace yet. :) Let me know if you have any other questions. DannyH (WMF) (talk) 18:02, 11 June 2014 (UTC)
 * DannyH (WMF), has anyone read en.wiki's guidelines on userpages? There is material that cannot be removed from user talk pages, eg existing sanction notices and unanswered unblocked requests. Breaking our guidelines like that would upset a lot of people. Besides the fact that current live discussions will vanish. New uers will see the guidance given them by welcome messages and Teahouse invitations mysteriously gone. This is going to hurt and I would expect a pretty negative reaction. Article talk pages also have headers that should never be removed automatically, I hope that Flow will not do that. Dougweller (talk) 07:20, 13 June 2014 (UTC)
 * I too think that this would require SERIOUS consideration in how you would have to do a transition. We use talk pages for a substantial amount of metadata definitions. Millions of definitions. where are these going to go and how will we achieve that move. A question like that needs to be defined, illustrated and answered before any sort of wider release can be possible. But that is not the scope of that bulletpoint. It is just for the 'one by one' activations, which means 'as requested', which means there is already user interaction, and thus someone can make sure the Flow page header has the appropriate info. TheDJ (talk) 13:50, 13 June 2014 (UTC)
 * Yeah, there's a lot of fine detail work for pretty much everything that we do. There are use cases, edge cases, policies, workarounds and compromises on every part of the feature that we're going to work through as we take each step. The list of bullet points on this page is just for the high-level goals. DannyH (WMF) (talk) 18:57, 13 June 2014 (UTC)

Mathematics rendering and editing
I am concerned about the current state of, and planning for, mathematics rendering and editing. When I say "planning" what concerns me is that there are no explicit plans for the future, and no mechanisms for forming them. I am told that these areas are currently dependent on one current volunteer working on rendering and one former volunteer project on a formula editor for VE. This seems entirely inadequate for a form of editing that is required in about 3% of Wikipedia articles (perhaps some 100,000 on en.wp).

I would suggest


 * General
 * WMF planning address the issue of development of mathematics and other complex rendering markup and editing components.
 * WMF liaise actively and effectively with existing editor and reader communities in (1).
 * WMF draw up roadmap for development of complex rendering and editing.
 * WMF liaise actively and effectively with volunteer developer communities to determine required frameworks and work packages.
 * WMF allocate funds and resources to support work packages.


 * Specific
 * Retention of current modes of editing and rendering mathematics an indispensable part of product development.
 * Mathematics rendering to be based on MathJax as principal vehicle, with efficiency and resources issues resolved on a wide variety of platforms.
 * LaTeX markup retained as principal mode of editing mathematics text with concomitant option to directly edit at the wikitext markup level.
 * Appropriate resourcing for specific targets.

Further background for the interested reader at en:Wikipedia_talk:WikiProject_Mathematics and at en:User talk:Mdennis (WMF). Deltahedron (talk) 18:29, 10 June 2014 (UTC)

Additional comments from one of the handful of volunteers working in this area.


 * workflow: From my perspective the most important thing is to establish a workflow for further development and deployment of the math extension. There are two volunteers Frédéric Wang and myself actively working on the Math extension. From WMF side the Visual Editor team takes care of the Visual Editor related aspects. For Frédéric and me the main problem is that we have no fixed contact person at WMF that cares about math related questions. I think a very brief weekly Skype meeting with a fixed contact person would eliminate most of the problems. This would eliminate most of the randomness involved in the current development process.
 * roadmap: I tried heavily to promote the https://www.mediawiki.org/wiki/Extension:Math/Roadmap page to have a more coordinated development process. Looking at the history indicates that I have changed my username. If anybody here is willing to contribute to the roadmap pleas give me a signal and I'll update the page. Otherwise I see no need to update this page for my own use only.
 * source rendering mode: I apologize that the MathSource mode is currently disabled. There is a fix at https://gerrit.wikimedia.org/r/#/c/139439/ which resolves this issue. As soon as this is backported by some WMF employee the source rending mode will be back.
 * MathML support: We manged to have experimental mathoid (MathML + SVG) support to the master branch. It works well on private wiki installation, but on the Beta Cluster only the SVG is displayed correctly. The MathML elements like ... are removed for some reason. If anyone has an idea why this happens I'd be very happy about comments either here, at my user talk page or at the bug report at https://bugzilla.wikimedia.org/show_bug.cgi?id=66495.
 * --Physikerwelt (talk) 17:38, 14 June 2014 (UTC)

It would be nice to have some sort of reaction from WMF staff to these proposals. Deltahedron (talk) 18:26, 17 June 2014 (UTC)

Image view analytics
I'm not happy to see that image view analytics is missing on the roadmap for the analytics team. The GLAM community has been begging for this for years. We recently did a pilot that shows that this is possible. Erik / Kevin, could you please explain why you left this out? Multichill (talk) 19:44, 11 June 2014 (UTC)
 * I wholeheartedly agree with Multichill, I'm interested to hear your response. 85jesse (talk) 08:27, 12 June 2014 (UTC)
 * +1 Multichill. You simply can't stretch the importance of image view analytics enough. Regards, Christoph Braun (talk) 10:26, 12 June 2014 (UTC)
 * +100 So needed!--Kippelboy (talk) 10:32, 12 June 2014 (UTC)
 * Weak Support Would be useful for GLAM folks and also for corporate folks. I would use it for both use cases. Zellfaze (talk) 12:17, 12 June 2014 (UTC)
 * +1 better image view analytics are needed by us in the GLAM sector, but of course they are also important for our photographers on commons who want the satisfaction of knowing more about how their work is being used. As I understand it the current system doen't scale, and would struggle if for example someone tried to do a report of usage of the Geograph upload to Commons. It is frustrating that because of our IT bottlenecks we can't promise potential GLAM partners that they will be able to get image view analytics if they release large volumes of images to Commons Jonathan Cardy (WMUK) (talk) 06:57, 17 June 2014 (UTC)
 * Yes, agreed - I don't want to specify too precisely what kinds of statistical data are desired, or how it is achieved, (that's too operational for this strategic level document) but I do want to repeat what has been said by many people working in external partnership roles: We need statistics for Commons partners. The first thing that external partners ask when we approach them for a content donation to Commons is a demonstration of how they can prove to their bosses the usefulness of working with us. Quite understandably people (and, by extension, GLAMs and organisations generally) need to justify their time/effort and multimedia statistics is how we do this. For example, this is the statistics page for all Europeana-related stats which is used to justify continued investment in Commons by Europe's official GLAM-content aggregator [and, full-disclosure, my current employer]. As you can see, it is based entirely of Magnus Manske's tools which were originally only created as proofs-of-concept. Given the significance of external GLAM (and other) partnerships to Commons [in terms of publicity, quality, quantity, wikis & external usage] it would be fantastic if this were supported directly. Other common questions from GLAMs (which are addressed in this goals document) include structured data, and file notifications - and I applaud that. cc Fabrice. Sincerely, Wittylama (talk) 21:46, 17 June 2014 (UTC)

GLAMwiki Toolset
The development of the GLAMwiki toolset could have been a less bumpy road. A small group of people have started discussions and are working on a proposal for future iterations/versions if the GWT. Wouldn't this be the right time/place to secure involvement of the engineering team and ironing out those bumps? Ter-burg (talk) 20:44, 11 June 2014 (UTC)

Health-check survey
How does it differ from Employee engagement survey? (Updates to the Meta page welcome.) --Nemo 08:38, 13 June 2014 (UTC)


 * The Employee engagement survey was (and still is) done annually every year by HR for the entire organization. This, I would guess, would be done by the Team Practices Group and would be confined to the Tech project teams above. You'd have to ask them for further details once they get up-and-running. :-) Tychay (talk) 19:21, 13 June 2014 (UTC)


 * Considering this subpage is entitled "2014-15 Goals", I think the differences (in goals) should be established now rather than later. --Nemo 21:07, 13 June 2014 (UTC)

Quantitative goals
On June 10, 2014, Erik wrote "As far as quantitative targets are concerned, we will aim to set them where we have solid baselines and some prior experience to work with ..."

Particularly for non-profits, I think there is a consensus, in goal-setting, that goals that specify outcomes are what an organization should be about, while goals involving inputs and outputs are important only so far as they support goals that are outcomes. (See, for example, http://blogs.hbr.org/2012/11/its-not-just-semantics-managing-outcomes/ )

Looking at the draft goals, I don't see any of the following measurable outcomes:


 * Server uptime [Site Operations]
 * Percentage of edits done using VE (versus the old wikitext editor) [Editing]
 * Number of active editors [Editor Engagement - Growth]
 * Number of edits done on mobile devices [Mobile and/or Editing]

In fact, the only measurable outcomes specified seem to be for Wikipedia Zero - and that's the one example mentioned by Erik, above. Given that there is a ten person Analytics team, the lack of quantifiable measurements as goals is disappointing. It's even more disappointing given that there are solid baselines for the first three items above.

The other thing that is disappointing - in terms of quantitative goals - is the lack of measurement of customer satisfaction. By "customers", I mean readers, volunteer developers, and volunteer editors. (National chapters and other WMF-related organizations are, in a sense, customers, too, but satisfying them is beyond the scope of Engineering.) WMF does do surveys to measure employee engagement and Engineering does quarterly surveys of all engineering teams "to measure current team health", so the concept of measuring satisfaction is not alien to WMF. But Engineering does no surveys of developers or editors to see if they're happy with what Engineering is doing. Or, if such surveys have been done (I'm not aware of any), then Engineering doesn't believes that such surveys should play any role in goal-setting.

To the extent that there are now no baselines for customer satisfaction outcomes, it's also true that if no surveys are ever done, there never will be baselines that can be used for goal setting, measuring improvement. John Broughton (talk) 02:57, 15 June 2014 (UTC)

Labs: Improvement of new-user & project creation process
Not sure what you mean by "Reorganization/improvement of new-user & project documentation", but I hope that not only documentation but the process itself will change. I think the easiest thing to do would be to at least fix the tool creation process by entering the tool name alone and not some confusing "Service group name".

As for the new-user process I think it should be done in one form:
 * 1) Signup at Wikitech to get Labs account (which now only give Bastion SSH access).
 * 2) Fill out an access request for the Tools project this should be an option in above.
 * 3) You should also get an option to "Add public SSH key" (with a link opened in new tab to help for generating SSH keys).
 * 4) After that user should receive information that he/she will get an email after completing the requests and link to help page for more information.

Or maybe make it a wizard with steps that would also include creating a new tool in the end. If there is AJAX access to current forms then this wouldn't be hard (as it could all be done on client side). Each step would include short explanation of the result (similar to description in "Quick start guide" on the help page). --Nux (talk) 16:25, 15 June 2014 (UTC)