Re: [Wikimedia-l] First _draft_ goals for WMF engineering/product

2014-07-03 Thread Erik Moeller
On Sun, Jun 29, 2014 at 10:19 AM, Michael Peel em...@mikepeel.net wrote:

 I am worried by how short-term the current plans/goals are, though. I know 
 that
 a lot of work that the engineering department does, particularly with regards
 software, which can only be planned on a quarterly basis to ensure it's as 
 agile
 and responsive to changing needs as possible. However, there's also the
 long-term view - what the key pieces of work that department wants to get done
 over the course of the next year or longer are - which is currently missing. 
 I think
 this is particularly important for the engineering side of things (expected 
 server
 capacity needs etc.), but it's also relevant for the software development 
 side in
 terms of the larger picture.

 Is there a wikipage available somewhere that sets out the long-term
 view/strategic priorities for the engineering department? If not, could I 
 encourage
 you to think about starting one?

Dear Mike,

Thanks for the thoughtful question.

On the subject of short term vs. long term precision, I'd encourage
you (and others) to view Lila's presentation from the metrics meeting
today [1]. We should be able to say with precision with what we're
going to do in the next quarter and paint a general picture as to what
we're going to do in a year.

There are indeed areas of planning that are a bit more predictable,
e.g. hardware purchases. The line item detailed view of the budget is
internal, but it includes year-long estimates for operating expenses
and capital expenditures, for example, based on hardware inventory,
warranty information, capacity projections, vendor agreements, and
project planning. They can still be thrown off if a major project with
lots of inter-dependencies like a data-center build-out falls behind
schedule.

The current engineering draft goals do include team-level Q3 and Q4
goals, but I've been OK keeping these fairly minimal for now. What's
more important is adding the narrative and through-line as well as
department-wide targets, which is still on my to-do list. Lila added a
couple of example dept-wide targets that we'll be fleshing out
further. We've already stated some of this in the FDC proposal (esp.
the mobile section), but I'll be bringing it into a more concise
summary focused on explaining the strategic context and the expected
outcomes.

I'm optimistic that as we develop this goalsetting framework further
it can serve as a template for how some of this work is done
organization-wide, potentially replacing the additional narratives
developed for the Annual Planning/FDC process.

Erik

[1] https://www.youtube.com/watch?v=993lpGrittg
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] First _draft_ goals for WMF engineering/product

2014-06-29 Thread Michael Peel
Hi Erik,

Thanks for sharing this update. It looks like a move in a good direction for 
WMF's engineering.

I am worried by how short-term the current plans/goals are, though. I know that 
a lot of work that the engineering department does, particularly with regards 
software, which can only be planned on a quarterly basis to ensure it's as 
agile and responsive to changing needs as possible. However, there's also the 
long-term view - what the key pieces of work that department wants to get done 
over the course of the next year or longer are - which is currently missing. I 
think this is particularly important for the engineering side of things 
(expected server capacity needs etc.), but it's also relevant for the software 
development side in terms of the larger picture.

Is there a wikipage available somewhere that sets out the long-term 
view/strategic priorities for the engineering department? If not, could I 
encourage you to think about starting one?

Thanks,
Mike

On 27 Jun 2014, at 02:55, Erik Moeller e...@wikimedia.org wrote:

 As an update on the goals process for WMF engineering, we've begun
 fleshing out out the top priorities for the first quarter. Going
 forward, we'll aim to call out the top priorities for each quarter as
 we approach it, to create more shared visibility into the most urgent
 and high-impact projects we're working on.
 
 I've decided for now to use a division between User-Impacting
 Changes and Cross-Functional Platform and Process Improvements. The
 intent of calling out both areas is to ensure that important
 organizational priorities don't fall off our collective radar. At the
 management level, the intent is for us to pay special attention to the
 priorities called out in this manner, and this may also impact our
 willingness to request help from across the organization if necessary
 to support these priorities, at least in Q1.
 
 I've merged the current draft into the goals document, here:
 https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals#Top_departmental_priorities_for_Q1_.28July_-_September_2014.29
 
 Once again, this is draft and marked as such. The Impact column will
 include links to relevant metrics once those are a bit more solid; if
 you look further down in the document you'll see that these are being
 refined and tweaked in multiple areas right now.
 
 A little bit of rationale for some items that may surprise you:
 
 - I've decided to list HHVM as the top priority in both categories.
 This is because a) it's a very complex undertaking from an engineering
 perspective and requires significant coordination across development 
 operations, b) it's probably the biggest change regarding how code
 gets executed in production since we adopted PHP in the first place,
 c) the expected performance benefits for many uncached logged-in user
 operations are very significant (I defer to the team to quantify
 before throwing out estimates).
 
 This is also indicative of the importance we're attaching to site
 performance. There's no question that performance is directly
 correlated with user engagement, and it's appropriate that we spend
 significant effort in this area.
 
 - We're elevating SUL finalisation (
 https://www.mediawiki.org/wiki/SUL_finalisation ) to a top priority,
 and I've classified it as user-impacting. This is because it's on the
 critical path for making it easier to develop cross-site functionality
 (as long as we have to deal with the edge case of detached accounts,
 certain features that work across wikis are just trickier to
 implement), and one of those long term issues of technical debt we've
 been kicking down the road for years. It's also a pretty complex
 project -- if it goes wrong and we mess up our account database, we're
 in big trouble. So we want to make sure we have lots of eyeballs on
 this from a technical and community management perspective. We may not
 completely wrap up in Q1 since we need to give users whose accounts
 are affected significant warning time, which is just elapsed time we
 can't shorten.
 
 - Front-end code standardization is called out as a top priority. We
 really need to dig ourselves out of the mess of having disjointed
 templating systems, widget libraries, and JS frameworks across our
 codebase if we want to increase development velocity and UX
 consistency. I'm prepared to sacrifice short term development velocity
 on other projects in order to make this happen.
 
 - The content API that Gabriel is working on (
 https://www.mediawiki.org/wiki/Requests_for_comment/Content_API ) is
 called out as a top priority. This is because the Parsoid output (for
 which the content API will be a high performance front-end) is now
 getting to the point where it's starting to become plausible to
 increasingly use it not just for VisualEditor, but also for views as
 well. The potential here are performance benefits across the board:
 for logged-in users in general by consistently relying on fast, cached
 

Re: [Wikimedia-l] First _draft_ goals for WMF engineering/product

2014-06-27 Thread Federico Leva (Nemo)

Erik Moeller, 27/06/2014 03:55:

As an update on the goals process for WMF engineering, we've begun
fleshing out out the top priorities for the first quarter.


This has already been an interesting and useful exercise, I feel. Those 
are indeed goals which need help from everyone who can. Which brings me to:



[...]
- The content API that Gabriel is working on (
https://www.mediawiki.org/wiki/Requests_for_comment/Content_API ) is
called out as a top priority. This is because the Parsoid output (for
which the content API will be a high performance front-end) is now
getting to the point where it's starting to become plausible to
increasingly use it not just for VisualEditor, but also for views as
well.


This is something I encourage everyone on this list to play with. I 
spent a couple days on Parsoid's output for it.wiki and it's been fun, 
finding many things to report: while reasonable pages are rarely very 
broken, on a random page there is some 50 % chance of finding some 
visual glitch.


My favourite toy to this purpose is Kiwix:
* download a recent file for your favourite wiki at 
http://download.kiwix.org/zim/wikipedia/ ,

* download Kiwix to open it http://download.kiwix.org/nightly/bin/latest/ ,
* start pressing random page and report surprises e.g. to 
https://sourceforge.net/p/kiwix/bugs/


Nemo

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] First _draft_ goals for WMF engineering/product

2014-06-27 Thread David Goodman
I'm delighted to see a document that is clear enough to encourage useful
comments from non-techies (on some parts of it)

I have 5, at increasing  levels of specificity

1) At least in the US, the need for increasing contributions by
underrepresented groups is not limited to women. Various ethnic groups in
the US are even more under=represented. But I'm not sure how much of this
is solvable by technology, either for them or for women.

2) The user retention goals are not the province of engineering alone, or
even for the most part. Attracting initial contributors will indeed be
greatly helped by Visual editor, but the enWP people will need considerable
convincing about both features and interaction with the current editor and
current procedures before doing what most needs to be done, making it the
default for non-loggged in users. The other aspects are primarily that of
improving the social environment  and on-wiki processes at the individual
WPs  Commons, and more effective work by  the various chapters and
associated projects. Flow will be of some help here, but it isn't the
critical factor.  I d I think the decline not only may be irreversible but
ought to be expected to be irreversible: WP is no longer the most exciting
thing in the world to the extent that it can have the same attractive power
as in the first few years.

3)I have never understood the need for Flow- I find the existing talk page
systems quite functional. But since many others don't find the current
system satisfactory.  the one place Flow should not be trialed on the enWP
is the Teahouse, which has its own distinctive system.  It should rather be
trialed on places where there is long and particularly intricate
discussions and were beginners are not likely to be confused.

4) The most intractable conflicts at enWP arise from the need to apply
brief descriptive phrases or words to situations that ae inherently
ambiguous. A system for category searching by intersection  would eliminate
about half the problems.

5) Perhaps this should be put off till the following year, but a system for
constructing articles from infoboxes populated by wikidata would
essentially give a fill in the blanks interface for constructing many types
of articles. This would help beginners, and people writing in other than
their native languages.,









On Fri, Jun 27, 2014 at 3:55 AM, Federico Leva (Nemo) nemow...@gmail.com
wrote:

 Erik Moeller, 27/06/2014 03:55:

  As an update on the goals process for WMF engineering, we've begun
 fleshing out out the top priorities for the first quarter.


 This has already been an interesting and useful exercise, I feel. Those
 are indeed goals which need help from everyone who can. Which brings me to:

  [...]

 - The content API that Gabriel is working on (
 https://www.mediawiki.org/wiki/Requests_for_comment/Content_API ) is
 called out as a top priority. This is because the Parsoid output (for
 which the content API will be a high performance front-end) is now
 getting to the point where it's starting to become plausible to
 increasingly use it not just for VisualEditor, but also for views as
 well.


 This is something I encourage everyone on this list to play with. I spent
 a couple days on Parsoid's output for it.wiki and it's been fun, finding
 many things to report: while reasonable pages are rarely very broken, on a
 random page there is some 50 % chance of finding some visual glitch.

 My favourite toy to this purpose is Kiwix:
 * download a recent file for your favourite wiki at
 http://download.kiwix.org/zim/wikipedia/ ,
 * download Kiwix to open it http://download.kiwix.org/nightly/bin/latest/
 ,
 * start pressing random page and report surprises e.g. to
 https://sourceforge.net/p/kiwix/bugs/

 Nemo


 ___
 Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
 wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe




-- 
David Goodman

DGG at the enWP
http://en.wikipedia.org/wiki/User:DGG
http://en.wikipedia.org/wiki/User_talk:DGG
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] First _draft_ goals for WMF engineering/product

2014-06-27 Thread C. Scott Ananian
On Fri, Jun 27, 2014 at 3:55 AM, Federico Leva (Nemo)
nemow...@gmail.com wrote:
 My favourite toy to this purpose is Kiwix:
 * download a recent file for your favourite wiki at
 http://download.kiwix.org/zim/wikipedia/ ,
 * download Kiwix to open it http://download.kiwix.org/nightly/bin/latest/ ,
 * start pressing random page and report surprises e.g. to
 https://sourceforge.net/p/kiwix/bugs/

I wrote http://nell-wikipedia.github.cscott.net a while ago with a
similar goal.  It is an offline wiki using parsoid output.  It needs a
bit of updating, since the Parsoid output has changed slightly since I
wrote it.

But you can also use http://parsoid.wmflabs.org/enwiki/Main_Page
directly now.  The Parsoid output includes a style sheet which ought
to render the parsoid DOM output identically to the standard PHP page
output.

We're constructing a visual diff tool this quarter so that soon we
should be able to do even better: testing for pixel-accurate matches
against standard output.  But that's not done yet, so bug reports on
Parsoid output and CSS/rendering issues are still valuable.
 --scott

-- 
(http://cscott.net)

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] First _draft_ goals for WMF engineering/product

2014-06-27 Thread Subramanya Sastry

On 06/27/2014 01:51 PM, C. Scott Ananian wrote:

On Fri, Jun 27, 2014 at 3:55 AM, Federico Leva (Nemo)
nemow...@gmail.com wrote:

My favourite toy to this purpose is Kiwix:
* download a recent file for your favourite wiki at
http://download.kiwix.org/zim/wikipedia/ ,
* download Kiwix to open it http://download.kiwix.org/nightly/bin/latest/ ,
* start pressing random page and report surprises e.g. to
https://sourceforge.net/p/kiwix/bugs/

I wrote http://nell-wikipedia.github.cscott.net a while ago with a
similar goal.  It is an offline wiki using parsoid output.  It needs a
bit of updating, since the Parsoid output has changed slightly since I
wrote it.

But you can also use http://parsoid.wmflabs.org/enwiki/Main_Page
directly now.  The Parsoid output includes a style sheet which ought
to render the parsoid DOM output identically to the standard PHP page
output.

We're constructing a visual diff tool this quarter so that soon we
should be able to do even better: testing for pixel-accurate matches
against standard output.  But that's not done yet, so bug reports on
Parsoid output and CSS/rendering issues are still valuable.


We are beginning to get there. :-)

See 
https://github.com/subbuss/parsoid_visual_diffs/blob/master/diffs/enwiki.Medha_Patkar.diff.jun27.jpg 
for the latest pixel-level visual diff on a sample page. Within the next 
couple weeks, we should be able to start generating these on a wider 
range of pages and set up regression testing on them as well to track 
progress.


Subbu.

  --scott



___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] First _draft_ goals for WMF engineering/product

2014-06-26 Thread Erik Moeller
As an update on the goals process for WMF engineering, we've begun
fleshing out out the top priorities for the first quarter. Going
forward, we'll aim to call out the top priorities for each quarter as
we approach it, to create more shared visibility into the most urgent
and high-impact projects we're working on.

I've decided for now to use a division between User-Impacting
Changes and Cross-Functional Platform and Process Improvements. The
intent of calling out both areas is to ensure that important
organizational priorities don't fall off our collective radar. At the
management level, the intent is for us to pay special attention to the
priorities called out in this manner, and this may also impact our
willingness to request help from across the organization if necessary
to support these priorities, at least in Q1.

I've merged the current draft into the goals document, here:
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals#Top_departmental_priorities_for_Q1_.28July_-_September_2014.29

Once again, this is draft and marked as such. The Impact column will
include links to relevant metrics once those are a bit more solid; if
you look further down in the document you'll see that these are being
refined and tweaked in multiple areas right now.

A little bit of rationale for some items that may surprise you:

- I've decided to list HHVM as the top priority in both categories.
This is because a) it's a very complex undertaking from an engineering
perspective and requires significant coordination across development 
operations, b) it's probably the biggest change regarding how code
gets executed in production since we adopted PHP in the first place,
c) the expected performance benefits for many uncached logged-in user
operations are very significant (I defer to the team to quantify
before throwing out estimates).

This is also indicative of the importance we're attaching to site
performance. There's no question that performance is directly
correlated with user engagement, and it's appropriate that we spend
significant effort in this area.

- We're elevating SUL finalisation (
https://www.mediawiki.org/wiki/SUL_finalisation ) to a top priority,
and I've classified it as user-impacting. This is because it's on the
critical path for making it easier to develop cross-site functionality
(as long as we have to deal with the edge case of detached accounts,
certain features that work across wikis are just trickier to
implement), and one of those long term issues of technical debt we've
been kicking down the road for years. It's also a pretty complex
project -- if it goes wrong and we mess up our account database, we're
in big trouble. So we want to make sure we have lots of eyeballs on
this from a technical and community management perspective. We may not
completely wrap up in Q1 since we need to give users whose accounts
are affected significant warning time, which is just elapsed time we
can't shorten.

- Front-end code standardization is called out as a top priority. We
really need to dig ourselves out of the mess of having disjointed
templating systems, widget libraries, and JS frameworks across our
codebase if we want to increase development velocity and UX
consistency. I'm prepared to sacrifice short term development velocity
on other projects in order to make this happen.

- The content API that Gabriel is working on (
https://www.mediawiki.org/wiki/Requests_for_comment/Content_API ) is
called out as a top priority. This is because the Parsoid output (for
which the content API will be a high performance front-end) is now
getting to the point where it's starting to become plausible to
increasingly use it not just for VisualEditor, but also for views as
well. The potential here are performance benefits across the board:
for logged-in users in general by consistently relying on fast, cached
output; for users loading VisualEditor by giving them most of the
payload required to edit in read mode; for users saving through
VisualEditor by potentially turning the wikitext transformation into a
post-save asynchronous process and thereby making saves near
instantaneous.

Moreover, it will put us on the long term path towards possibly using
HTML5 as MediaWiki's native format, supporting HTML5-only wikis, and
more. And it will be valuable for third party re-use and re-processing
of Wikimedia content for a multitude of use cases. Last but not least,
it's also a great use case for a service-oriented architecture
including REST APIs  good/clean API documentation.

In short, this is a big deal, and it has lots and lots of
architectural implications -- so raising the visibility on this is
intended to get more people to actually think through what all of this
means for the future of MediaWiki.

Other elements of the prioritization shouldn't be surprising:
Phabricator is a big deal, and it's coming; Mobile (including new
contributory features) and VE (including a really awesome new
citations experience we're 

Re: [Wikimedia-l] First _draft_ goals for WMF engineering/product

2014-06-25 Thread Erik Moeller
On Mon, Jun 23, 2014 at 10:28 AM, Nathan nawr...@gmail.com wrote:
 Can you describe how specific engineering projects are helping to address
 the gender gap? Do you typically review user-facing projects with the
 gender gap specifically in mind? I notice that while there is a FOSS
 outreach program for women, there is nothing specific in the Wikimania
 Hackathon materials to suggest that an effort was made to attract women to
 this event. There is another hackathon planned for early next year - will
 engineering make the gender gap part of the goals of that event?

Dear Nathan,

Thanks for asking this question, and thanks to Sumana for the pointers
to good places for deeper conversations.

At a high level, I think we need to be careful not to over-mandate
engineering. Building a great experience for editing and discussion
and testing it against a representative demographic cross-section is
in itself a very complex undertaking (especially when doing so in the
wonderful world of wikitext), without And it also needs to increase
the %/# of women participating in our projects as a specific measure
of success for each feature. I do want us to get better at more
quickly and frequently capturing the demographic baseline data so we
can at least understand the trends better. Quick, lightweight survey
tools are high on the wishlist for a lot of folks, and we'll think
about when/how to prioritize that in the overall roadmap.

Where I see some of the strongest potential to actually engage
under-represented groups is in the area of task recommendations.
Whenever we build systems that suggest things to do to new users,
we're making implicit value judgments about what kinds of work we
consider to be important. I think it's reasonable in this context to
consider factors such as the under-representation of a topic area in
the encyclopedia, which may draw in potential content contributors
familiar with that topic specifically, and in turn counter systemic
bias both in topic coverage and participation.

Erik

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] First _draft_ goals for WMF engineering/product

2014-06-23 Thread Federico Leva (Nemo)

Nathan, 23/06/2014 19:28:

it would be nice to see gender-gap related goals within
VisualEditor


Cf. https://meta.wikimedia.org/wiki/Research:Gender_micro-survey

Nemo

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] First _draft_ goals for WMF engineering/product

2014-06-17 Thread James Salsman
Erik Moeller wrote:
... My own focus will be on fleshing out the overall narrative,
 aligning around organization-wide objectives, and helping to
 manage scope

Steven Walling wrote:
 The Wikimedia Foundation does not write nor edit content
 on Wikipedia

Newyorkbrad wrote:
... The protection of Section 230 enables websites such as
 Wikipedia to operate without fear that the Foundation will be
 subject to suit anytime someone, such as a BLP subject,
 disagrees with the content of an article

Are there any reasons that
http://strategy.wikimedia.org/wiki/Proposal:Develop_systems_for_accuracy_review
should not be adopted as a Foundation engineering goal?

Is there anywhere in
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals
where it fits in?

I am not a fan of neglecting low hanging fruit, especially when it is
characterized as something positive, like narrowing focus, fleshing
out a narrative, goal alignment, or managing scope. So much money is
coming in from contributors who deserve and could have so much more if
the Foundation leadership was more ambitious and less distracted by
incremental but relatively burdensome improvements to existing
solutions like the visual editor and talk page redesigns.

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe