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)

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)

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)