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)

Nemo bis, 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 • 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.

• 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?

--Nemo 08:29, 10 June 2014 (UTC)

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)

See Analytics/Metric_definitions#Active_editor and Analytics/Metric_definitions#Newbie_editor --Arthur Richards (talk) 19:29, 19 June 2014 (UTC)

What a cryptic answer (I know those sections, I wrote part of them). Was this meant as a "no" to my first question? --Nemo 07:46, 21 June 2014 (UTC)

I didn't mean to be cryptic Nemo - you asked for a link to the definition in response to Tychay, so I provided the link to the working definition of active editor. I imagine that 'new' in this case means an active editor who has not been considered an active editor previously, but perhaps you should ask Maryana directly for clarification. --Arthur Richards (talk) 17:13, 23 June 2014 (UTC)

• Irrespective of the definition for the metric, I see the goal for its increase is now along the lines of "Quantitative target: 2% increase in new mobile active editors from Q1". This is not meaningful IMHO, they need to be weighed by the number of pageviews. Example: imagine that at the end of the year you have a 10 % increase of $random_activity_metric with a 50 % increase of page views in the same period; that's a loss, not a gain. --Nemo 08:55, 23 June 2014 (UTC)

• Nemo_bis, trends in pageviews and active editor numbers haven't always correlated on our projects. For example, PVs kept rising steadily after the start of the editor decline in 2007-8 and have done so up to today, despite the continued editor decline. So tying PVs to active editor metrics on mobile doesn't necessarily make sense. Maryana (WMF) (talk) 19:52, 23 June 2014 (UTC)

Citations

Hi there. What does "OPW" stand for in 'Auto-filling citations depends on the OPW work to do this led by the Services team (and partially mentored by the Editing team).'? Thanks. --Hfordsa (talk) 11:36, 10 June 2014 (UTC)

Outreach Program for Women. Matanya (talk) 12:13, 10 June 2014 (UTC)

I see that number 4 on the list of "Top departmental priorities for Q1 (July - September 2014)" is "4) Continue improving VisualEditor (citations, performance, visual parameter-editing, IE support); begin re-engaging with English Wikipedia community" — "New citations functionality will make citations - currently obscure, template-based machinery - truly accessible to anyone by simply pasting a URL. This will benefit wikitext users as well." How is that going? Deltahedron (talk) 20:46, 6 September 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)

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

@Jdforrester (WMF): 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

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

• Specific

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

Further background for the interested reader at en:Wikipedia_talk:WikiProject_Mathematics#A challenge from Jimbo Wales and at en:User talk:Mdennis (WMF)#Mathematics editors and the 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 <mo><mi>... 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)

Hello Deltahedron. Thank you for your comments.

I think you are wrong to characterise software development in these terms. Software is not just done by volunteers (or staff) at the direction of WMF management "planning" outcomes. Most esoteric content types (from formulæ and galleries to image maps and hieroglyphics) are not just maintained but were imagined, created and directed by volunteers too.

Though I'm sympathetic to wanting the mathematical support to improve, and Physikerwelt has some valid points about how we as a community have failed to support him enough in some of his areas of work, I do not think that WMF management involvement is needed to tell him and other volunteers what to do and what the editing community want.

Instead, I think the editing community who use the formula system regularly are best placed to give advice and input to the great roadmap for maths – I note that the talk page is blank, so I'm confused as to how much input you've provided, if any.

Jdforrester (WMF) (talk) 20:01, 20 June 2014 (UTC)

It seems you have understood the precise opposite of what I am attempting to suggest. I am suggesting that the plan be developed on the basis of what readers and editors actually want and need, and that this comes from a constructive engagement with discussions such as that at en:Wikipedia talk:WikiProject Mathematics#A challenge from Jimbo Wales. This is the opposite of management telling them what they want Next, I am suggesting that paid staff effort be coordinated with volunteer developer effort in implementing that plan. This is not the same as telling volunteers what to so. It seems clear to me that currently neither of the things I suggest is happening.

I note that you agree that "the community" has failed to support PW enough. Actually, I maintain that it is the WMF that has failed PW. PW has made some specific requests for support from WMF developers. Will WMF provide that support or will it not?

I think it's symptomatic of WMF planning that there's always another page that you can point me to -- in this case mw:Extension:Math/Roadmap. It is not up to me to find or populate these arcane locations: WMF have a staff of Community Advocates to link us as volunteers into WMF and conversely, and to direct conversations appropriately. If you are confused about the community views, then I suggest you use your own advocates' channels for clarification. In the unlikely event that it is necessary for you to know what input I personally have given, then my all means looks at the links I gave in my original posting, where you will see my input along with that of other editors, or feel free to ask me directly.

May I ask whether you plan to take any specific actions in support of your "wanting the mathematical support to improve"? Deltahedron (talk) 10:22, 21 June 2014 (UTC)

Is there any progress on providing an answer to this question, which would be much appreciated? Deltahedron (talk) 21:14, 25 July 2014 (UTC)

To broaden the scope a bit: there are several areas in our wikis where editors have to spend a lot of time fighting with the limitations of text.

Unlike video and photos/slideshow support, which attract a lot of attention mostly as "idealogical" battlefields with unknown benefits, scientifical and informational visualisation tends to be uncontroversial and rather self-contained in scope/audience: here some technological support could do wonders to free up editing energies and enthusiasm.

I've been collecting a list at Infographics, graph, chart, diagram, plotting, animation support (tracking): some are already in the "deployment review" phase (sometimes since years ago), others would need some help from users to define use cases and solutions (like Support for editable cladograms in wiki markup). --Nemo 08:01, 4 July 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)

Report on requirements for usage and reuse statistics for GLAM content

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. [See also the commissioned report - on the right - to this effect.] 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)

• Hello Multichill, Christoph Braun, Kippelboy, Zellfaze, Jonathan Cardy (WMUK) and Wittylama: Thanks so much for bringing up this topic. Image view metrics are important to the multimedia team as well, and we would like to explore a collaboration with you and the analytics team to get a basic set of metrics in place in coming months. We have been discussing a framework for multimedia metrics with our analytics colleagues Toby and Dario, as well as with Gergo and Gilles on our team -- with guidance from Erik. Together, we reviewed these preliminary metrics goals last week, focusing on image views, uploads and files used as our first baseline metrics to measure our progress. For image views, we would be interested in joining forces with you to leverage the work you've already done with the NARA pilot and scale it up, if feasible. To that end, we'd like to propose a meeting with key stakeholders in coming weeks to discuss what can be practically done together to move this forward in coming months. Note that our team cannot take on the full feature set described in in your excellent GLAM requirements doc, but we can help collect and build dashboards with the analytics team for per-file view stats (see our Mingle ticket #628) -- that could then be extended for GLAM partners with your help. In any case, I think it would make sense for us to have a first meeting over Google Hangouts or IRC, and take it from there -- and maybe follow this up with a face-to-face meeting at Wikimania in London, if you plan to be there. Thanks again for reaching out to us, and we look forward to working together to make progress on this front this year. Fabrice Florin (WMF) (talk) 02:14, 26 June 2014 (UTC)
  • Excellent Fabrice, thanks. And yes - on behalf of Europeana we definitely want to meetup at Wikimania and we'll have several people involved in the GLAMwikiToolset project there too. Wittylama (talk) 15:19, 26 June 2014 (UTC)
    • Thanks Fabrice. Any suggestions as to when at Wikimania we can meet? Jonathan Cardy (WMUK) (talk) 09:01, 6 August 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)

+1 to this question. Fabrice - Europeana, who coordinated the development of the GLAMwikiToolset, have recently hired me to help be the liaison between Europeana and the the Wikimedia community, with special emphasis on supporting the WMF relationship regarding the Toolset. There are a lot of people interested in seeing the success and integration of this software, for example, I note that Wikimedia Finland's 2014 successful annual activities grant stated "Several content donations are planned but have been postponed in anticipation of the GLAM-wiki toolset".

Eloquence suggested this talk page was the best place to discuss expectations. Wittylama (talk) 10:59, 20 June 2014 (UTC)

• Hi Wittylama: Kudos on your new job with Europeana, which seems like a really good fit for you! We would like to see the GW Toolset succeed, but concur with you that it's been off to a bumpy start -- perhaps due to a mismatch between expectations and available resources. Active development on the GW Toolset is not currently part of the multimedia team's roadmap for 2014-15, though we are prepared to continue to play an advisory role and help address critical issues along the way. But with only 3 developers on our team, our plate is quite full already with the upload wizard upgrade, the structured data implementation and making a small dent in our large technical debt. So we recommend that Europeana and its partners continue to lead further development of the tool, with guidance from our team. We're happy to discuss this project with you, with the understanding that our resources remain limited in the near-term. My colleagues Erik, Rob and Gergo are welcome to chime in as well, from their perspective. Fabrice Florin (WMF) (talk) 02:54, 26 June 2014 (UTC)

Health-check survey

How does it differ from m: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)

Nemo, the health-check survey will not be intended to measure job satisfaction like the m:Employee engagement survey. Rather it will be used to assess efficacy in getting the right stuff done. A good example of this is what is done in engineering at Spotify (see [1]). The results of this will be used to help focus efforts around making specific improvements in areas where they are most needed. --Arthur Richards (talk) 19:34, 19 June 2014 (UTC)

Thanks, I had no idea that the m:Employee engagement survey was not about "getting the right stuff done" i.e. achieving the organisation's goals; again, improvement of the Meta page(s) on the topic(s) is very much welcome. For instance, from the very useful resource you linked, the following items would seem to related very closely to "employee engagement": "Teamwork", "Pawns or Players", "Suitable Process", "Fun". --Nemo 07:58, 21 June 2014 (UTC)

I should have been more clear about 'getting the right stuff done' - by this I mean are teams delivering the right products at the right time. This is a very team-level perspective of 'getting the right stuff done' whereas an organizational perspective of 'getting the right stuff done' which would be at a higher level (are the teams aligned and focused with the organization's strategic direction). The way I categorize this in my mind is that the engagement survey is strategically focused (big picture and longer time horizon) whereas the health-check survey is tactically focussed (day-to-day, or really quarter to quarter). The employee engagement survey is an annual survey and as such, if we were to ask individuals to evaluate themselves on "Teamwork", "Pawns or Players", "Suitable Process", "Fun" only annually, we would not be in a position to iterate quickly on helping individual teams make improvements in areas where they feel they are deficient. Doing quarterly, focussed health-check surveys with the teams, we'll be able to more quickly identify where a team is feeling deficient, help that team find ways to make improvements, and then measure quickly whether or not the efforts towards improvement are working - and make adjustments as needed. When we design the team health check survey, we will be sure to calibrate against the employee engagement survey and ensure that there is no unnecessary redundancy. --Arthur Richards (talk) 17:12, 23 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)

Hi John. Thanks for the thoughtful commentary. You can see from the latest draft of the Growth team section that we are in fact developing quantitative targets. Unlike last year's targets, a raw number of active editors is not what we're focusing on. Instead, we're using the current number and rate of change in our active editor community to predict what conversion rate increases would be required in key metrics (signups, new editors, returning editors) in order to either arrest any decline or grow. These numbers that will all be finalized and documented before July 1, but for now you can see some more explanation at Growth/2014-15 Goals. Thanks, Steven Walling (WMF) • talk 19:04, 19 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)

Services

Under the Q1 goals for the Services group, I see "PDF render service deployment". The other things in the list for Q1 there are really meaty, important projects like the RESTful API work and HTML templating. On the other hand, most users (at least of modern browsers) are able to view, save, and print PDFs directly from the browser without a secondary service. Why do we even need to support this? It'd be much more efficient to just deprecate the feature IMO. Steven Walling (WMF) • talk 23:23, 19 June 2014 (UTC)

The primary goal of this is to support users who want to create books. Its just that incidentally people also use it to print to pdf... I don't actually know if it was considered to deprecate it completely instead of replacing mwlib with something more easily maintained. 198.73.209.2 23:36, 19 June 2014 (UTC)

Actually, this project originally started with the idea of using PhantomJS and something like book.js for the rendering, basically doing what's possible in cutting-edge browsers on the server until everybody's browser has caught up. I believe that this ran into the issue of current PhantomJS not using latest WebKit yet (waiting for the QT5 chrome / blink port). To get something working, the current version uses a LaTeX-based backend.

I believe the intention is to revisit HTML-based rendering after this version is deployed. The infrastructure for book creation etc will be useful no matter which rendering backend is used. Once available, HTML-based rendering will also work in latest browsers, so everybody will benefit. -- Gabriel Wicke (GWicke) (talk) 03:52, 20 June 2014 (UTC)

English, please

Hi. Please try to avoid abbreviations (e.g., "OPW work" and "SOA Auth"). And link liberally! --MZMcBride (talk) 02:37, 25 June 2014 (UTC)

+1. If acronyms are used, then please consider wikilinking them. Thanks. Mike Peel (talk) 18:21, 29 June 2014 (UTC)

Feedback by Micru

• Regarding citations: please do communicate with the Wikidata team, it is expected that source metadata will be centralized there, so it makes sense to find a method to link the fields of the citation with the corresponding Wikidata properties.
• Regarding MediaWiki Core’s front-end libraries: namespaces and tab management need some love. See Requests for comment/Associated namespaces
• Not mentioned - open datasets: also known as "let's centralize tables so we can create cool visualizations with the data" (not necessarily maps). This could be tied to "table editing". It is not clear where to store that data, Wikipedia pages seem not to be the right solution. Both initial candidates, Wikidata and Commons community, have shown well-justified reluctance to take care of this data. Consider other options that fit into the global ecology of projects (data-commons?).

--Micru (talk) 07:58, 27 June 2014 (UTC)

Accuracy review

User:Rdicerb_(WMF), how do you feel about implementing strategy:Proposal:Develop systems for accuracy review as a Community Engagement product? Volunteer development on it has stalled for lack of time and funding resources. It is sorely needed as the larger wikipedias transition from building new content to maintaining existing content. James Salsman (talk) 01:09, 5 July 2014 (UTC)

Mathoid

Is there a pointer to further details of this product? Mathoid is currently a red link. Deltahedron (talk) 21:16, 25 July 2014 (UTC)

Moritz Schubotz and several other contributors from the MathJax community have built a modern LaTeX to SVG & MathML render service based on MathJax and Node.js called Mathoid. This service is independent from MediaWiki, and is already used by other organizations. The best documentation currently is probably its github page. The integration work with MediaWiki is described in Extension:Math/2.

Our goal is to support the Mathoid deployment to the cluster, so that MediaWiki can start using this to render LaTeX to SVG & MathML. -- Gabriel Wicke (GWicke) (talk) 23:31, 25 July 2014 (UTC)

Thanks for the prompt response. Sounds good! Deltahedron (talk) 06:41, 26 July 2014 (UTC)

Flow reboot

In view of the various statements are en:WT:Flow, which seems to be the preferred locus for discussion and announcements rather than Talk:Flow, that Flow is undergoing "some reboot", presumably there will be a rewrite of the Goals here? Deltahedron (talk) 20:51, 6 September 2014 (UTC)

Re: put together a list of 43 stakeholders

Weird addition. Why 43 and not 80, 42 or 5? How is "A2K" related? --Nemo 21:09, 17 February 2015 (UTC)

42 ++ John Vandenberg (talk) 21:41, 17 February 2015 (UTC)

Objective, key result, beneficiaries

I'm happy to see these more clearly defined now. However, I'm finding it hard to connect many of the stated objectives (or key results) to the overall goals of the Wikimedia Foundation ("strategy", we would have said some time ago).

There is also a wild variety in how these columns are interpreted in the various sections, for instance some objectives don't state a benefit/goal but describe a product; some key results contain metrics to gauge progress, while others describe a piece of the product or a procedural step.

Concretely: «At least 99.95% of the 160K test pages [...] without semantic errors» is a very clear metric for a self-explanatory goal (avoiding markup errors) for our single most important mission (letting people edit). At the opposite, «Begin collecting baseline usage statistics (creating, adding, consuming)», which: is not a goal in itself; mistakes measuring for the measured thing (the benefit); is tautological and panglossian in nature (it is, because it is; it is, hence it's good; usage is good because it's usage). --Nemo 21:48, 29 March 2015 (UTC)

Re: New external monitoring for performance and uptime metrics from the user's perspective

I see it was marked done: where is it? --Nemo 22:08, 18 April 2015 (UTC)