Re: [Foundation-l] Use of moderation

[Erik Moeller]

2009/9/8 Gregory Maxwell :
> As such, it's time to try something different.

What do you suggest? Are there models from other mailing list
communities that we should experiment with to create a healthier, more
productive discussion culture? What, based on your own experience of
this list, would you like to see change?
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Do we have a complete set of WMF projects?

[Erik Moeller]

2009/9/8 Michael Peel :
> What could be the cause of this recent dearth of new projects?

Certainly the process for getting a new project underway is so complex
and exhausting that it's not something that many people will be likely
to engage in - especially considering that project ideas are often
proposed by people who aren't currently very active Wikimedians.
Perhaps we need to set up a formal system for long-time Wikimedians to
adopt ideas they're excited about, to help push them to approval? In
any event, if you want to add to the Wikimedia family, my guess is
that it's currently a commitment of 2-3 months of several hours per
week to get to that point, provided it's achievable to begin with.

I do think that project adoption is something that we should explore
in the right circumstances; it's not something we've ever done but IMO
we should be open to it. I don't think OpenStreetMap or OpenLibrary
want or need to be adopted. ;-) But there may be other smaller
semi-successful projects that would like to join our project family,
and that would make sense as part of it.

I would also make the point that adding capabilities to existing
projects can be just as effective at cultivating new communities of
participants as creating an entirely new wiki, and sometimes more so.
For example, as of a few weeks ago, there's now a fledgling community
of people on Wikimedia Commons who add annotations to images, because
a volunteer developed a cool image annotation tool. The entire
community of people adding categories to Wikipedia articles could only
form after the categorization functionality was developed.

Because the Wikipedia community is so vast, adding capabilities that
engage more people on Wikipedia specifically, or improving access to
the existing capabilities, can have dramatically greater impact than
creating a blank-slate wiki.

That is not to say that I think there should be no new blank-slate
wikis, or wikis with custom software, for specific purposes. But I
would also not see the fact that no new top-level Wikimedia project
has been created in recent years as a sign of stagnation - wonderful
capabilities have been created in the existing Wikimedia ecosystem in
that same time period, some of them with dramatic positive impact.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Use of moderation

[Erik Moeller]

2009/9/8 Brian :
> Some of us feel
> that the foundation has become out of our reach. That no matter how much we
> discuss and try to reach consensus it will just be too hard, or there will
> be a lack of interest in our consensus at the foundation, for any real
> change to happen. You practically have to get a grant on behalf of the
> foundation anymore in order to convince them you've got a good idea.

Really? Can you give examples of stuff that used to be easy that's
become harder now, and where consensus has been ignored where it would
have been swiftly acted upon in the past?

I do believe that much like in Wikipedia itself, we're past the low
hanging fruit phase right now when it comes to WMF's objectives. It's
one thing to set up a MediaWiki instance and call it Wiktionary, it's
another to actually design software for supporting a multilingual
dictionary and thesaurus. And so it goes with virtually every major
challenge we're facing today. The "easy stuff" at this point is only
easy in that it is obvious (yes, MediaWiki usability sucks), not in
that it is easy to fix.

Part of traditional professionalization is also to only make a
commitment when you feel you can uphold it. So where a casual,
informal organization is more likely to say "Yeah, sure" and then
never do anything (FlaggedRevisions and SUL being two examples of this
happening in the past, with no execution over multiple years), a more
formal, professional organization will only make the commitment if it
can allocate resources to keep it. So, as an organization matures, it
will by definition say "no" more frequently, because saying "yes" too
often is one of the most common signs of immaturity. We've certainly
not reached the end point of that process yet.

But for a _volunteer_ driven organization, it's important to make a
further transition, not from "yes" to "no" in 9 out of 10 cases, but
from "yes" (and nothing will happen) to "yes, and here's how _you_ can
make it happen", except for the truly bad ideas. :-) I think this is
where we're failing right now -- engaging more people to help us solve
problems. The strategic planning process is the first attempt to scale
up the small-room conversations of the past into the largest possible
meaningful consultation. How do we transform those plans and proposals
into volunteer workgroups and actions?

[ And yes, that's a bit off-topic for the thread, but I think pretty
on-topic for the list. ;-) ]

-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Priorities and opportunities

[Erik Moeller]

2009/9/16 Samuel Klein :
> Putting aside the unnecessary bad faith and challenges to the
> foundation's integrity:   I find this all exciting - planning for
> significant tech budget support, possible major sponsorships (I've
> always hoped we would one day find multiple sources for long-term
> in-kind support of servers and bandwidth), &c.  I would simply like to
> see more open discussion of what our perfect-world tech dreams are,
> and how to pursue what sorts of sponsorships.

Thanks, Sam. I find the discussion of the last few days symptomatic of
the problems we've begun to brainstorm about with regard to the
signal/noise ratio, healthiness and openness of this particular forum.
(And by openness I mean that a forum that is dominated by highly
abrasive, high volume, low signal discussions is actually not very
open.) I do want to revisit the post limit question as a possible
answer, but let's do that separately.

The thread did surface some topics which are worth talking about, both
in general and specific terms, and I'm taking the liberty to start a
new thread to isolate some of those topics. For one thing, I think
it's always good to revisit and iterate processes for defining
priorities, and for achieving the highest impact in those identified
areas.

Developing more sophisticated processes both for short-term and
long-term planning has been precisely one of the key focus areas of
the last year. Internally, we've begun experimenting with assessment
spreadsheets and standardized project briefs, drawing from the
expertise of project management experts as well as Sue's specific work
in developing a very well thought-out prioritization system at the
CBC. Publicly, we're engaged in the strategy planning process -- the
associated Call for Proposals is a first attempt to conduct a
large-scale assessment of potential priorities. (I hope that with
future improvements to the ReaderFeedback extension we'll be able to
generate more helpful reports based on that particular assessment.)

Ideally, the internal and public processes will converge sooner rather
than later. For example, I posted a project brief that I developed
internally through the strategy CfP:
http://strategy.wikimedia.org/wiki/Proposal:Volunteer_Toolkit

I believe this one was submitted by Jennifer:
http://strategy.wikimedia.org/wiki/Proposal:Volunteer_Management_practices_to_Expand_Participation

And this one by Tim:
http://strategy.wikimedia.org/wiki/Proposal:Directed_community_fundraising

The next phase of the strategy planning process, the deep-dive task
forces, will be an interesting experiment in serious community-driven
planning work, complemented by the research conducted with the help of
our partners at The Bridgespan Group. All of this will become part of
the institutional memory of the Wikimedia movement, and hopefully
we'll continue to raise the bar in our thinking, planning, and
collaboration.

- - -

Of course separately from setting priorities, there's the critical
need to improve our ability to execute upon those priorities. This
includes the further development of project pipelines, more systematic
volunteer engagement, additional internal HR support, additional
hiring of staff to address key capacity gaps, etc. I'm thrilled by how
far we've come, and to be able to have supported, and continue to
support, an unprecedented large-scale initiative like the usability
project. I'm well-aware that there continue to be key priorities that
we aren't executing as effectively as we could.

The first thing many partners, donors and friends say when they visit
Wikimedia Foundation is how astonishing it is that an operation of
this scale can function with so little funding and staff. The truth is
that by any reasonable measure of efficiency and money-to-impact
ratio, we're achieving wonderful things together, and that's easy to
forget when looking at issues in isolation. (Yes, it would be
wonderful to have the full-history dumps running ASAP. Hm, it would be
nice to have the full-history dumps for some other top 50 content
websites. Oh, right, they don't provide any.)

But I don't measure our success compared to other organizations. The
most important question to me is whether we are continually raising
the bar in what we're doing and how we do it. The most recent
Wikimania was the most thoughtful and self-aware one I've ever
attended, with deep, constructive conversations and very serious
efforts of everyone involved to re-ignite and strengthen our movement.
There are elements of groupthink, but also very systematic attempts to
break out of it.

There are great opportunities today for anyone to become engaged in
helping to shape the future of what we do, and to accomplish real
change in the world as a result. Ultimately we all have to make a
choice how we spend our time -- how we spend our lives -- but I hope
we're creating a legacy that will fill us with pride and joy, and
inspire others to do the same.
-- 
Erik Möller
Deputy Director, Wikime

Re: [Foundation-l] WMF Office Move

[Erik Moeller]

2009/9/16 Sue Gardner :
> 2009/9/16 Thomas Dalton :
>> 2009/9/17 Daniel Phelps :
>>> We look forward to the future in our new location and hope that we get
>>> a chance to have you all visit us.  We will do our best to post photos
>>> as we settle in so that people can imagine us all in our new setting.
>>
>> This sounds very exciting! Until you get some photos, is this the place?
>>
>> http://maps.google.co.uk/maps?f=q&source=s_q&hl=en&geocode=&q=149+New+Montgomery+Street,+3rd+Floor,+San+Francisco,+CA+94105&sll=37.786555,-122.399604&sspn=0.008886,0.01929&ie=UTF8&ll=37.786802,-122.399737&spn=0.000278,0.000603&t=h&z=21&layer=c&cbll=37.786802,-122.399737&panoid=o1HKtiN5txSMU7LGzfPPYw&cbp=12,42.53,,0,-8.62

If you "turn around", you'll see the historic PacBell building on the
other side:
http://en.wikipedia.org/wiki/PacBell_Building

> we are not big enough to be open to the general public, with tours and data
> displays and so forth.

We never ended up mounting permanent data displays at Stillman, but I
do think we should rig up something for the new space - a
recent-changes live feed, and perhaps real-time images from Commons (
http://toolserver.org/~para/Commons:Special:NewFiles ) if we're
willing to tolerate the occasional inappropriate image. ;-)

-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] CTO role (Was: Re: Priorities and opportunities)

[Erik Moeller]

2009/9/16 George Herbert :
> I have a specific question regarding the CTO role which has been
> floating around not yet completely defined.  Brion announced the
> impending opening a while ago now and the formal definition of the job
> role (and possibly title, I suggest it's more of a CIO role than CTO
> per se) was to follow.
>
> As operational technical concerns are a credibly large part of the
> overall concerns people have about strategy and execution, can you
> tell us if there's a defined timeline on the new CTOish role being
> formalized, announced, etc?

Absolutely. We recently engaged the Walker Talent Group (
http://www.walkertalentgroup.com/ ) to help us with this search, which
they've graciously agreed to do on a pro bono basis. We had our first
serious meeting with them last Friday, and they are very excited to
reaching out to a broad network to surface a candidate who makes sense
for us. We've developed a draft JD which we've held off until we had
the opportunity to review it together with WTG, but which is ready to
post now and should go up early next week after a final review pass.
We're not going to hire unless we feel we have an excellent candidate,
but I hope we'll be able to place the position by the end of the year.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Announce: Brion moving to StatusNet

[Erik Moeller]

Thank you, Brion. Through your many years of volunteering and then
staff work, you've secured your place in Wikimedia history. It's been
a pleasure to work with you over the years, and I'm glad you'll
continue to be involved. As I said privately, I'm happy you've found a
great open source company to work for, but of course it's a great loss
to the organization. :-(

We'll be doing lots of internal planning to manage this transition
period. Separately, we'll also be posting at least two software
engineering jobs soon, in addition to the CTO job which is already
posted. If any of you have any referrals (ideally people who can
relocate to San Francisco), please let me know off-list. And please be
forgiving of tech delays in the coming months.

Thanks,
Erik
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Status of flagged protection (flagged revisions) for English Wikipedia.

[Erik Moeller]

Hi Greg,

a quick note on Sue's behalf since we're all quite swamped right now.
On the tech side of things we're planning for the CTO transition right
now, as well as building up our capacity; those are core
foundation-building priorities that have to be higher than any
specific deployment, particularly given Brion's departure now.

We haven't committed to a specific FlaggedRevs deployment deadline
precisely because there isn't enough capacity right now to allocate to
the project. Pretty much all development work is done by a single
contractor, Aaron Schulz, who is amazing and deserves massive credit
for the fact that there is a usable FlaggedRevs extension at all,
which is in production use on our second-largest Wikipedia and many
others. There's no project manager for it, there are no other
developers who are assigned to working with Aaron, nor are there team
meetings to plan the further roll-out of the product.

The only situation where there's actually a dedicated full-time team
working on one specific problem-set is the usability project, and
that's because we've been able to receive an $890,000 grant
specifically to build it. It's time-limited, but we're looking for
ways to extend it past its grant run. As I think has been visible with
the successful roll-out of the usability beta, the milestones so far,
etc., this is one viable approach to get stuff done.

Should we have a dedicated quality assurance team? Perhaps; it's a
high-risk but potentially also high-gain technology priority. Is it
higher priority than, for example, massively improving mobile access
to Wikipedia and thereby potentially reaching hundreds of millions of
new readers/contributors? Maybe: The Strategy Project is designed to
help us answers these questions.  At this stage of organizational
development, we can possibly have 2-3 usability-sized tech projects
per year. There are other ways to support project roll-outs, such as
hiring product/project managers, which we've budgeted for but may have
to delay past the other planned tech hiring.

All that said, even with Brion transitioning, we're hoping to have at
least some scheduled small group conversations about the roll-out
plan, and Brion is hoping to invest some of his remaining time with it
in helping to get the extension ready for en.wp. It's not trivial: The
scalability concerns at that size are a step more serious than with
de.wp, and we're also concerned about the potential negative impact on
participation. The user interface is well-suited for the current de.wp
implementation, but needs some TLC to work for the "flagged
protection" use case.

We're committed to getting there but at this stage I can't give you a
better promise than allocating some percentage of the core team to
supporting the UI development, testing, and production roll-out,
hopefully resulting in a full production roll-out prior to the end of
this year.

Erik
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Status of flagged protection (flagged revisions) for English Wikipedia.

[Erik Moeller]

2009/9/28 Gregory Maxwell :
> Of course. But I wasn't expecting a turn up on English Wikipedia yet.
> I'm asking why the 25 lines of configuration that EnWP specified have
> not yet been added to the test wiki at
> http://flaggedrevs.labs.wikimedia.org/wiki/Main_Page

I'll review the current state of the prototype w/ Brion this week and
whatever needs to be done to get broader testing will get done ASAP.

>> and we're also concerned about the potential negative impact on
>> participation.
>
> Please help me understand the implications of this statement.

It simply means that

a) we want to make sure that for the production roll-out, the user
interface is not insane and appropriate to the specific en.wp
configuration that's been proposed;
b) we'll want to track participation metrics after the roll-out to see
what the impact of this technology is.

Accusations of "obstructionism" don't help; I understand where these
come from, but it's a massive case of assume bad faith. Please stop
it.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Status of flagged protection (flagged revisions) for English Wikipedia.

[Erik Moeller]

2009/9/28 Gregory Maxwell :
> "Bad faith" — I don't think those words means what you think they mean.

If it was our intention to not implement Flagged Protection, then we
(WMF) wouldn't have said the opposite publicly. Instead, we would be
communicating about why we're not implementing it. Our only
communication about this has been, and will always be,
straightforward.

It's your right to question allocation of resources. I would ask you
to keep in mind that a) some resources are allocated in a fixed manner
due to the funding source (e.g. usability), b) just because you can
spend successfully in one department, doesn't mean you can spend
successfully in another, c) initiatives like the strategy process are
essential precisely to do the best possible job to choose between many
competing priorities, all of which are very important to their
respective petitioners. As I said, there's quite a bit of foundational
growth that needs to happen in the tech department to improve
responsiveness and capacity of the core team. Referrals are welcome.

As for FlaggedRevs, we'll whip the prototype into shape ASAP and take
it from there.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Status of flagged protection (flagged revisions) for English Wikipedia.

[Erik Moeller]

2009/9/28 Jimmy Wales :
> If the Foundation is bottlenecked at the moment (understandable) then
> how can I help, how can we the community help, to take some of the
> burden off of them to get done what we need to get done for the sake of
> our mission?  :-)

The process going forward is pretty clear -

a) make sure prototype setup reflects desired behavior as per the
en.wp proposal and invite broader testing;
b) make revisions to extension based on public and internal review
with a particular eye to usability;
c) ensure that the extension is fully scalable to en.wp traffic volume;
d) deploy on en.wp as per proposal (potentially, per c, initially in
some scale-limited fashion).

Brion's going to look into the prototype situation ASAP, and we have a
scheduled call with Aaron later this week to talk about any obvious
changes that he can focus on immediately. The most obvious way for
people to help is to give feedback during the testing period. Beyond
that, I would ask for patience and goodwill as we're managing many
competing priorities right now, and things are pretty stressful.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Status of flagged protection (flagged revisions) for English Wikipedia.

[Erik Moeller]

2009/9/28 Brion Vibber :
> It seems to work just fine, actually. The extension is on, the
> configuration is being loaded for the right database, and things seem to
> function when I test them.

Thanks for looking into it, Brion.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Charity Navigator rates WMF

[Erik Moeller]

2009/10/8 Michael Snow :
> We do pay attention to the efficiency of operations and how funds are
> spent, not merely for the sake of appearances but as something valuable
> in its own right. With that in mind, it's more useful to look directly
> at ways of achieving greater efficiency than to debate how important it
> is for us to meet arbitrary standards.

Indeed. Overhead ratios actually say almost nothing about wastefulness
or impact. It is possible to be utterly wasteful in spending on
program services, and it's possible to have zero impact with very
little overhead. It's possible to make a dramatic "overhead"
investment that's going to have an equally dramatic impact on your
ability to do your work, and it's possible to make no overhead
investments and thereby endanger your ability to function.

Think about some examples of large and small "overhead", and then
think about whether they are wasteful or not, and you will find
quickly how limited this entire conceptual model is.

Because donors pressure non-profits to reduce "overhead" without a
rational basis, and non-profits respond sometimes in ways that damage
their mission, and sometimes in ways that are unethical (deliberately
mislabeling costs), the use of overhead ratios is highly controversial
among those who study, understand, and advise the non-profit sector.
See, for example, this article in the Stanford Social Innovation
Review:

"A vicious cycle is leaving nonprofits so hungry for decent
infrastructure that they can barely function as organizations—let
alone serve their beneficiaries. The cycle starts with funders’
unrealistic expectations about how much running a nonprofit costs, and
results in nonprofits’ misrepresenting their costs while skimping on
vital systems—acts that feed funders’ skewed beliefs."
http://www.ssireview.org/images/articles/2009FA_feature_Gregory_Howard.pdf

See also this article along similar lines:
http://www.bridgespan.org/nonprofit-overhead-costs-2008.aspx

And for some serious empirical data, the non-profit overhead study is
one of the largest attempts to study the use of efficiency ratios in
the non-profit sector, and it found many "glaring functional expense
reporting errors" in non-profit's 990 statements, which is a response
to the pressure to show high "efficiency" ratios. This goes to the
extreme point of organizations reporting their entire fundraising
costs as program expenses, in contradiction with their own audited
financial statements:
http://nccsdataweb.urban.org/FAQ/index.php?category=51
http://nccsdataweb.urban.org/kbfiles/520/brief%204.pdf

Because misreporting (and sometimes overreporting) of overhead costs
is so common as the above document shows, it's very hard to make any
accurate comparisons of different non-profits on that basis, even if
you assume that the overhead percentage has value to begin with. The
Stanford article also shows the dramatic difference in overhead costs
in different business sectors -- what's appropriate "overhead" depends
in large part on what you're doing. If you're hiring a lot of
high-skill workers, then your HR department better be sophisticated
enough to surface the best candidates, etc.

The idea of spidering 990s to create some automatic assessment number
may sound useful in theory, but its practical value is low, especially
without understanding the above context. If you're a sophisticated
donor and you understand the implications of a) different sectors
having different needs and different efficiencies, b) reporting
standards and accuracy varying wildly across different organizations,
you might be able to derive some value from it. But the only way to
find out whether a non-profit is doing good work is to study its
impact, and understand how it's using its money.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Public release of Wikimedia Report Card

[Erik Moeller]

Erik Zachte, Data Analyst for the Wikimedia Foundation, has just
released the first official public version of the Wikimedia
Foundation's monthly report card on key program metrics. If you
haven't seen it, his blog post about it is here:
http://infodisiac.com/blog/2009/10/the-wikimedia-report-card/

And the public page is here:
http://stats.wikimedia.org/reportcard/

What's being tracked right now is the following:
* number of unique visitors to WMF projects according to comScore,
with breakdown by region, and the percentage reach this represents
among all Internet users;
* number of page requests according to our server log data, with
breakdown by language;
* comScore rank relative to other web properties (we can't release all
the data we have access to from comScore here);
* number of content objects (pages, binaries), with breakdown by
project for pages, and breakdown by filetype for binaries;
* participation rates: new pages per day, edits per month, new editors
per month, active editors making 5+ edits, very active editors making
100+ edits

We've used indexes as a tool to make trends easily understandable over
time -- see the "indexed" tabs in the different sections. The top left
of each section makes some key numbers easily accessible, e.g.
month-to-month comparisons and year-to-year comparisons.

The report card will continue to evolve in response primarily to the
Wikimedia Foundation's organizational priorities and needs - if we
have a specific project designed to achieve impact in one category,
we'll break out a section to look at it. And we're also hoping to have
higher level summary information. Feedback is very much welcome -
probably the best place to post it is in response to Erik's blog post
above so we have it all in one place. :-) Aside from feedback,
however, I also want to take this opportunity to praise Erik for all
his work over many months in putting this together, as well has his
ongoing work to release it on a regular basis.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Fwd: [openmoko-announce] WikiReader

[Erik Moeller]

2009/10/13 Steven Walling :
> From the demo video TechCrunch did, it looks like they are doing filtering
> which you can turn on selectively.

My understanding is that it's a simple keyword filter, so I wouldn't
expect too much from it.

We've played with the product during its development and connected
them with some people in the community; the last versions I've seen
don't have most of the early bugs anymore, though there's still plenty
of room for improvement as well. It remains to be seen whether it can
be commercially successful, but it's still nice to see alternative
approaches to distributing free content. I've put up a blog post about
it here:

http://blog.wikimedia.org/2009/10/13/openmoko-launches-wikireader/

-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Office move completed

[Erik Moeller]

This is just a quick update that we've completed our office move to
149 New Montgomery in San Francisco, which also means that the
usability team is now integrated into the same location. This week
we've had two days of tech meetings and two and a half days of
all-staff meetings in the new space, which is very functional, thanks
to the hard work of Daniel Phelps, James Owen, Steve Kent, Rob
Halsell, Ariel Glenn, Fred Vassard, and many others who helped. It
gives us some room to grow, breathe and meet, and more than a single
bathroom :-). We'll post more details and photos to the blog and to
Commons soon.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Office move completed

[Erik Moeller]

Blog post by Jay is now up:
http://blog.wikimedia.org/2009/10/27/wikimedia-finds-a-new-home/

First photos here:
http://commons.wikimedia.org/wiki/Category:Wikimedia_Foundation_149_New_Montgomery

More pics will come with time for those who can't get enough of seeing
office environments. ;-)
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Recent firing?

[Erik Moeller]

We don't comment on personnel rumors and speculation and will make
announcements when and where appropriate.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Fundraiser tech issues

[Erik Moeller]

The fundraising banners went live yesterday, but in spite of efforts
to test them, there were serious issues with their basic functionality
and IE6 and IE7. My apologies; it's an inexcusable screw-up on our
part, and we won't go live again until we've resolved this. (We're
looking into the feedback on the messaging/style of the banners as
well, and have been from the beginning.)

-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] advertising craigslist

[Erik Moeller]

Just as a bit of general background for this thread:

The Craig Newmark banner is currently running at 20% on the English
Wikipedia. It's a pilot to see how our audience responds to
endorsements and testimonials by third parties. (So far, it is doing
reasonably well, but not fantastically so; we will likely move on to
different messages soon.) We're not running a large endorsement
campaign this year, but we wanted to at least get some data on a
banner of this type to help us determine whether we want to run more
such messages in the future.

We approached Craig and asked him whether he would help us with this,
and he generously agreed. We chose Craig because he represents, to
many people, a philosophy of the web that is comparable to ours. In
spite of huge web traffic, Craigslist is run with a staff of 32 and
carries no ads, and Craig founded a non-profit organization, the
Craigslist Foundation, to support other non-profits. (CraigsList
itself is a for-profit.) We're pleased that Craig has joined our
Advisory Board, and we're happy he agreed to this endorsement.  That
said, any kind of personal endorsement can certainly polarize.

If, in future, we decide to run more such endorsements, we'll likely
want to come up with a rich mix of different kinds of people with very
different backgrounds, both to appeal to different segments of our
audience, and to get a better understanding of the overall trends.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Announcement: Priyanka Dhanda joins Wikimedia

[Erik Moeller]

Hello all,

I'm very pleased to welcome Priyanka Dhanda to the Wikimedia
Foundation as Code Maintenance Engineer. Priyanka joins us from
SourceForge Inc., where she worked since 2002 as a software developer
and also was involved in operations, working on most pieces of the
infrastructure, and integrating third party software with the
SourceForge platform (including MediaWiki). Priyanka holds a Master's
Degree in Computer Science from the University of Toledo, Ohio, and a
Bachelor of Technology in Computer Science and Engineering from the
Pondicherry Engineering College in India.

She is starting today and will work in the San Francisco office.

Priyanka will be a key interface between software developers and the
operations team, helping us to catch up with our code and bug review
backlog, to mentor new developers, to push projects to completion, and
to improve testing and automation.  Please don't swamp her immediately
with requests as she'll need some time to get more deeply oriented in
the MediaWiki codebase. :-) You'll be seeing her in the IRC channels,
on SVN, Code Review, BugZilla, wikitech-l, and so forth.

Please join me in welcoming Priyanka to the Wikimedia team! :-)

All best,
Erik
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] How are media from content partnerships used?

[Erik Moeller]

This is not news for people who've been watching closely, but I
thought it deserved a "re-post" to give it some additional visibility.

In the last year, the Wikimedia movement has developed some very
important content partnerships with cultural institutions such as
museums and archives to bring valuable pictures, videos, and other
media online. Some but not all of them are categorized here:

http://commons.wikimedia.org/wiki/Category:Commons_partnerships

What's the impact of these partnerships? How are these media used? We
didn't have good answers to these questions until very recently.
Thanks to the work of Bryan Tong Minh, Magnus Manske, and other
engineers, we now have some first good data:

1) The GlobalUsage extension is now re-deployed on Wikimedia Commons,
which makes it easy to see where any individual file is used in the
Wikimedia universe;

2) The Glamorous script by Magnus Manske gives you that overview for
an entire category on Commons.

For example, you can go to http://toolserver.org/~magnus/glamorous.php
and select the "Images from the German Federal Archive" category. This
will show you that out of the 82,457 images uploaded so far, more than
15,000 are currently used in articles. 34 languages use at least 100
images, 11 use at least 1,000.  This demonstrates the powerful dynamic
of global re-use that uploading media to Wikimedia Commons can result
in.

We'll be able to show even more compelling data if we now add the
(known) pageview data for the relevant articles. Hopefully this
emerging data will contribute to a virtuous circle of new content
partnerships.  I'll pull together some facts for a blog update on
what's happening in the space, but wanted to give a general quick
update first. :-)
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Sue Gardner, Erik Möller , Wi lliam Pietri: Where is FlaggedRevisions?

[Erik Moeller]

Hello all,

as a matter of principle, I'm not going to engage in this thread given
the toxic tone in which it was started and partially carried on, nor
do I expect any other WMF staff or contractors to do so. If there is
interest in a civil, reasonable discussion regarding this or any other
topic, please start a new thread, and we can have a conversation from
scratch, within the constraints of everyone's availability.

Thanks,
Erik
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] [Announcement] Extension of user experience work

[Erik Moeller]

Hello all,

our very positive revenue perspective (we have already exceeded our
fundraising targets for the fiscal year, and received the additional
$2M from Google) allows us to do something we've hoped to be able to
do: make our investment in user experience work permanent, as opposed
to releasing most of the current user experience team and ending the
project.

It makes obvious sense for any major website to have a permanent team
focused on user experience improvements in the broadest sense. This
includes eliminating obvious barriers to entry, but beyond that, we
want to improve the experience as a whole for both readers and
editors.

We're now referring to this work as "user experience" (UX) work, which
includes usability.

Naoko will be Head of UX Programs, while Trevor will be the lead
front-end developer on the team. Congratulations to both of them. :-)
Naoko is currently assessing the remaining contracts and will share
further information as these decisions are finalized.

In the immediate future post-April, we'll be concerned with tying up
loose ends from the usability initiative, and finishing functionality
that we had to put in the parking lot. We'll work on a roadmap and
staffing plan for 2010-11 and beyond as part of our business planning
process.

Our long-term focus will be determined in significant part based on
the recommendations from the strategic planning process; see
especially the community health recommendations:

http://strategy.wikimedia.org/wiki/Task_force/Recommendations/Community_health

While we haven't finalized priorities, the single biggest piece of
work is likely going to be the transition to a rich-text editor as the
default editing environment for all Wikimedia Foundation wikis. But,
user experience to us also means assessing how people self-organize
and communicate in Wikimedia projects, how they get stuff done, and
how they read and navigate our projects. Even among the areas of work
we've already identified, there's enough to keep us busy for many
years. :-)

Please note that the original usability initiative hasn't concluded
yet. The team is working on its final release, which will include some
of the most-anticipated changes, including collapsing of templates to
simplify the editing interface, and the production release of the new
feature-set to all users. As always, we'll continue to communicate
progress through  and
, and feedback and participation is
welcome at .

All best,
Erik
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] FlaggedRevisions status (March 2010)

[Erik Moeller]

2010/3/1 Austin Hair :
> I think it would be great if someone
> on the project could put the initial tone aside, turn the other cheek,
> and let everyone interested (and I know there are several) know what's
> going on.

Hi Austin et al.,

William has already posted extensively on this topic, so I'll keep it
simple. Since our last update in January [1], Aaron has continued to
work [2] through the list of issues [3] specific to the enwiki feature
request called "Flagged Protection". The current version of
FlaggedRevs has dependencies on MediaWiki core that haven't been
deployed yet, and the labs sites run on the same code tree, so Aaron
is now backporting the extension to work with the currently deployed
MediaWiki version, so he can pull the update to labs. Rob has also
separately re-purposed one of the servers from our main cluster, which
Aaron and Rob will set up as a separate testing environment that can
run any code, but which will need to resemble a roughly
production-equivalent system setup so that any observed behavior
matches what we will observe in a full production deployment.

William will post a more detailed update once the new code is
available for public testing. We'll need to test both the enwiki setup
and common existing configurations to ensure that we're not breaking
any pre-existing configurations, as we're not intending to fork the
extension.

Looking forward, our UX team has recently contracted Ryan Lane to
develop a new QA pipeline that supports easy spin-up of prototype
sites, as well as automated interaction testing using Selenium. [4] So
far, they've been using Linode VMs for prototype.wikimedia.org, but
their performance characteristics haven't been consistent with our
needs.

We're very thankful for Aaron's hard work on the FlaggedRevs extension
over the years; it's really almost entirely due to him that the
extension is now in active use in more than 20 wikis, with more than
1M pages patrolled in dewiki alone. That's an amazing achievement for
one young, talented engineer. And we're also grateful to William and
Howie for helping to guide the process, especially after Brion's
departure.

With that said, the concepts of FlaggedRevs pre-date even WMF itself,
and first development work began when the organization just had a tiny
number of employees. As a result, the process has involved almost
every single stakeholder in the Wikimedia movement (having an opinion,
not writing actual code), and as a product development process, been
entirely broken. We'll see it to further deployment, but of course
it's not the panacea that some people think it is; everyone means
something different when they talk about it, and there's a lot more
work to be done in the problem-space.

Through investments like the UX team, WMF is now building its capacity
for team-based product development, and ultimately, the tools we
develop to deal with quality assessment, moderation and labeling (and
IMO labeling is just as much a component of the BLP problem as edit
moderation) will need to be part of our overall product roadmap and be
tackled by the team as a whole. But, there are no shortcuts: new hires
take time to get productive, legacy projects need to be carefully
transitioned, and operations capacity (both staffing and resources)
needs to grow commensurate with new challenges. WMF is doing more than
ever before to serve its mission, but aspirations typically grow more
quickly than foundations.

All best,
Erik

[1] 
http://techblog.wikimedia.org/2010/01/flagged-revisions-your-questions-answered/
[2] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/aaron
[3] http://www.pivotaltracker.com/projects/46157
[4] http://usability.wikimedia.org/wiki/Resources#Interaction_testing_automation
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Wikiversity

[Erik Moeller]

2010/3/18 Anthony :
> For what it's worth, I think it's probably a good idea to shut down
> Wikiversity.  Wikiversity hasn't to my knowledge achieved anything of note.

To be fair, I don't think that's equally true for all language
editions. The German Wikiversity, from what I can see, seems to be
slowly but productively doing what the project was designed to do:
producing learning materials. Even the English Wikiversity has a set
of well-developed, rich pages, e.g. Robert Elliott's filmmaking
lessons:

http://en.wikiversity.org/wiki/Course:WikiU_Film_School_Course_01_-_Learning_the_Basics_of_Filmmaking

It's heartbreaking to see how a small project can be disrupted by a
tiny number of well-known problem users, and IMO a strong argument for
using more global blocking processes. Small projects often think they
need to give people "fresh start" opportunities because they're
otherwise not going to grow, but that's a bad bargain - introducing
toxic personalities into a fledgling community is a certain way to
bring about its decline.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Credo

[Erik Moeller]

2010/3/18 Jon :
> Is the Credo donation open to all Wikipedia project editors, or just the
> English Wikipedia project editors.  Thank you for your help.

It's open to editors from all Wikimedia projects who meet the
requirements (6 months participation and 600 edits in a project). I've
put it on en.wp because that's where most likely users probably are,
but the application form allows specifying a different home wiki.
Please put your name on the enwiki page as well, with a link to your
userpage.

http://en.wikipedia.org/wiki/Wikipedia:Credo_accounts
http://wikimediafoundation.org/wiki/Application_for_Credo_accounts
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Swedish Wikipedians removes Wikimedia logos

[Erik Moeller]

2010/3/30 John Vandenberg :
> I would prefer that Sv.Wp make an exception for WMF logos being used
> in conjunction with interwiki links, such as on
> sv:template:wikisource.  To me, those uses are part of the UI of the
> project, and fall under fair use of the trademark.
>
> However, I've seen this non-free logo debate too many times to be
> surprised that there are lots of people willing to make a tough stance
> on it.

They have at least kept the logos on the Main Page.

I'll note that the licensing policy passed by the Wikimedia Foundation
Board of Trustees (
http://wikimediafoundation.org/wiki/Resolution:Licensing_policy )
specifically permits project communities to develop exemptions, with
logos being listed as an example. The Swedish Wikipedia community can
make a community decision to remove these logos from articles and
templates, but there's no hobgoblin of consistency that forces them
to. In fact, the Swedish Wikipedia community could develop an explicit
exemption policy only for WMF logos within the boundaries of the
policy. The policy also requires exempt files to be properly tagged,
so any third party re-user can exclude them if they want to be on the
safe side.

Even without going into the licensing policy, I would personally
express the view that it would be completely reasonable to interpret
sister project templates to be a part of the navigational elements of
our websites that just happens to live inside article space. These
templates are in fact frequently filtered by re-users because they
provide limited utility outside the Wikimedia context. Categorizing
them in ways that are friendly to re-users is probably a greater
service to them than a logo purge, and the elimination of identifying
marks from our navigational structure clearly harms our own ability to
develop a coherent reader experience.

-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Swedish Wikipedians removes Wikimedia logos

[Erik Moeller]

2010/3/31 Petr Kadlec :
> On 31 March 2010 04:28, Erik Moeller  wrote:
>> I'll note that the licensing policy passed by the Wikimedia Foundation
>> Board of Trustees (
>> http://wikimediafoundation.org/wiki/Resolution:Licensing_policy )
>> specifically permits project communities to develop exemptions, with
>> logos being listed as an example.
>
> So are you saying that a Wikipedia community is allowed to develop an
> EDP saying that _logos_ received from 3rd party owners under, say,
> CC-BY-ND [and possibly even -NC, but let's not get to the problems
> with that] are acceptable? I was told that this is not correct and the
> resolution allows only for EDP recognizing copyright limitations
> existing in national copyright laws (even though I do not see this in
> the resolution text).

No, EDPs do indeed have to be grounded in "the limitations of
copyright law (including case law) as applicable to the project". But
an EDP which recognizes those limitations only for logos of
organizations whose trademark policies explicitly acknowledge
reasonable uses of their marks within the confines of those
limitations (as the WMF trademark policy does) would be acceptable, as
would be one which recognizes them only for WMF's logos (for all the
reasons that have already been given to make such an exception).
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Fwd: [Announcement] Howie Fung joins Wikimedia

[Erik Moeller]

FYI.


-- Forwarded message --
From: Erik Moeller 
Date: 2010/5/5
Subject: [Announcement] Howie Fung joins Wikimedia
To: wikimediaannounc...@lists.wikimedia.org


Hello all,

I'm pleased to announce that Howie Fung, who has been supporting us as
a consultant since October 2009, is joining the Wikimedia Foundation
as Senior Product Manager. In the immediate future, Howie will
continue to support the deployment of our user experience
improvements, as well as the continuing development and deployment of
the FlaggedRevs extension for the English Wikipedia. In the longer
term, Howie will help us to build Wikimedia's product development
roadmap by commissioning and assessing research and analytics, and by
engaging in broad consultative processes.

Most recently, Howie was Senior Product Manager at Rhapsody,
where he helped grow the music site's traffic five-fold within the the
first year
on the basis of extensive customer research, including web analytics,
focus groups, user testing, and customer surveys. Prior to that, Howie
was Product Manager at eBay, prioritizing features based on business
objectives, usability studies, and economic impact. Howie has more
than 15 years of experience in product management, business analysis
and strategy, technology evaluation, and team incubation. He has an
MBA from The Anderson School at UCLA and a Bachelor of Science in
Chemical Engineering from Stanford University.

As a consultant, Howie completed several key projects, including the
survey of former contributors [1], the analysis of feedback from the
user experience beta [2], and extensive analysis of the user
interface, workflows and terminology used in the FlaggedRevs
extension. He has also supported Wikimedia's five-year business
planning process. We're very pleased that Howie is joining Wikimedia's
permanent staff: please join me in welcoming him!

All best,
Erik

[1] http://strategy.wikimedia.org/wiki/Former_Contributors_Survey_Results
[2] http://usability.wikimedia.org/wiki/Beta_Feedback_Survey

--
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate



-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] hiding interlanguage links by default is a Bad Idea, part 2

[Erik Moeller]

2010/6/3 Fajro :
> Maybe we should support the "Language Icon" idea:
>
> http://languageicon.org/index-icon.php

That icon seems about as intuitive as the name "Hyperion
Frobnosticating Endoswitch" for FlaggedRevs. The only relevant mental
association that comes to mind is "robot tongue".
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] hiding interlanguage links by default is a Bad Idea, part 2

[Erik Moeller]

2010/6/3 Austin Hair :
> Last night I was discussing this with Finne (henna), and she proposed
> that we might show a default list based on the user's most likely
> language(s), while still keeping the others collapsed by default.

Yes, we discussed this internally as well as a better path to exposse
Wikipedia's multilingual nature than to dump a long list of native
language names in the sidebar (we might have an expansion link such as
"Show X other languages" to indicate the large number of language
versions available). I hope this is a path to an acceptable
compromise. I support the rationale behind collapsing the full list:
the vast majority of the information in it tends to be noise to the
average user.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] hiding interlanguage links by default is a Bad Idea, part 2

[Erik Moeller]

The original intent of the UX team, as I understand it, was to help
readers find essential (frequently clicked) elements in the navigation
more easily by collapsing less essential ones.

It has been legitimately argued that the language links are essential
for many users, even if the click rate is lower than that of some
other elements, and that they are also key to surfacing our value of
language diversity. The reasonable hypothesis has also been presented
that the click rates are higher in other languages than English.

The legitimate counterargument is that the naïve link list does not
necessarily do the best job at this: by presenting the one or two
links that may be relevant to the user within a potentially (and
hopefully) very long column of foreign words in sometimes foreign
scripts, it's a reasonable hypothesis that users will not in fact
discover or understand the availability of -their- language, but
rather simply glance over the list.

Howie has presented the outlines of a new compromise approach: that by
presenting a limited number of links by default, we increase the
discoverability of the feature, while also limiting overall page
clutter. That's also just a hypothesis.

I would suggest the following approach:

1) That we return to the default-expanded state for now. If we want to
default-collapse again, we'll need some more compelling metrics that
demonstrate the actual benefits of doing so.

2) That we prototype the system above, or some variant thereof, define
key metrics of success, and A/B test it against the existing one,
provided the idea doesn't turn out to be obviously flawed.

I agree that this isn't the highest priority issue on the list of UX
fixes and changes, so by implementing 1), we can do 2) on a timeline
that makes sense without a false urgency.

The BlackBerry issue is indeed of greater importance. It only affects
a subset of BB models, apparently older ones from what I've seen.
Hampton, Tomasz and Ryan Lane have been working on getting VMs with
the BB simulators set up, so that we can a) debug Vector on different
BB versions, b) test the mobile redirect and mobile site on BB before
we enable a redirect. This was delayed by ops issues on the mobile
site, but I hope we'll get It sorted out next week.

For the record, I agree entirely that read-breakage of this type is a
critical, high priority bug.

Erik

On 6/5/10, Gregory Maxwell  wrote:
> On Sat, Jun 5, 2010 at 3:37 PM, David Levy  wrote:
>> Sue Gardner wrote:
>>> Feedback is great, but it irritates me when people start using words
>>> like "stupid" -- that's what I was responding to.
>>
>> Perhaps you misread the context.  Austin wrote the word "stupid" as a
>> hypothetical example of nonconstructive commentary that should be
>> avoided.  No one has hurled an insult.
>
> Moreover "feedback" can itself be perceived as an insult.
>
> Imagine that someone cleaning your office took your important
> paperwork and dumped it in a bin.  You complain— "Hey we need that
> stuff to be accessible!" and they retort  "Thank you for your
> _feedback_. We'll consider it during our future cleaning plans".
>
> We're not just providing feedback here. We're collectively making a
> decision, as we've always done, thank you very much.
>
> ___
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>

-- 
Sent from my mobile device

Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Community, collaboration, and cognitive biases

[Erik Moeller]

Hello all,

the massive thread regarding the default sidebar language link
expansion state has surfaced a number of fundamental and significant
questions regarding the working relationship between the Wikimedia
Foundation and the larger Wikimedia volunteer community. This message
represents my snapshot-in-time thinking about these questions, and I
hope others will join this thread to meaningfully advance this IMO
very important conversation.

Tl;dr version: I believe that the transparency of Wikimedia's
engineering processes, and the general quality of these processes, has
significantly improved over the last year. At the same time, I agree
with those who are observing a widening gap between staff and
volunteer contributions, and I think we need to work together to close
this gap in full awareness of the cognitive biases present in all of
us.

1) Increase in quality and transparency of our engineering processes:

I'm very grateful for the hard work accomplished by the User
Experience Team to-date. When we started the usability project, we had
never run a discrete engineering effort of comparable scale before,
and indeed, most of our larger-scale engineering projects tended to be
drowned by day-to-day emergencies and bug fixes. The team consists
primarily of people who didn't have a long prior history in Wikimedia
projects, nor with each other: they had to grow as a team, understand
our enormously complex community, while also delivering results. I
want to use this opportunity to explicitly thank Brion, who played a
key role in the orientation of the team.

The UX team has implemented a number of important practices:

* very frequent sharing of detailed work product, including mock-ups,
specs, and research results such as user test videos.
* systematic QA using an external QA firm, browser compatibility
matrix, etc.; beginnings of automated testing
* qualitative remote and in-person user testing to assess real-world
experience with the site
* moving towards data-driven decision-making using tools such as
click-tracking, systematic assessment of feedback data, various
statistics, etc.
* public and frequent blog updates both in the regular and in the
technical blog, use of the sitenotice to announce deployments
* public sandboxes demonstrating all bleeding edge improvements early
* various community-oriented discussion pages and documentation on
usability.wikimedia.org informing and supporting design and
localization
* largest systematic feedback collection about any software deployment
in the history of Wikimedia projects

Many of these were "firsts" for the Wikimedia Foundation, and they all
were firsts on this scale. Some of these practices have clearly
contributed to letting the community participate _more_ in the overall
initiative: the larger-scale outreach, the sharing of research
findings (which led to some community-driven improvements), the
carefully prepared public testbeds, etc. Some, on the other hand, have
arguably widened the staff and volunteer gap, both between staff
developers and volunteer developers, and between staff and larger
volunteer community.

I don't think Wikimedia's development processes are anywhere near
those of proprietary web companies, but it's absolutely true that
they're also not highly comparable to 100% volunteer-driven open
source projects anymore. I think there are some parallels with both
the strengths and weaknesses of open source projects with reasonably
well-funded organizations behind them, both for-profit and non-profit.

I also want to be clear that there's no doubt in my mind that our
ability to execute projects of this _type_ and at this _scale_ is
unprecedented, and a historic achievement for the Wikimedia movement.
MonoBook was implemented in 2004, and the basics of the user interface
and user experience of Wikipedia have changed very little between then
and pre-Vector.

The reasons for that are varied. Fundamentally, I believe that online
volunteer mass collaboration works best when incrementalism and
self-selection can, over a long period of time, add to an overall
product that's useful at any given time -- such as Wikipedia or
Wikimedia Commons. We've seen this work less well where we need to
collaborate in a short period of time to achieve a result of
predictably high quality (Wikinews), or where we're working over long
periods of time on a result with (perceived or actual) limited
usefulness until it is complete (Wikibooks).

I'm not saying this is inherent in volunteer mass collaboration, or
that these challenges are insurmountable, just that a) tools and
practices of volunteer collaboration tend to support self-selected
long-term incrementalism better than, shall we say, strategic
megaprojects, b) we're not necessarily even using all the tools and
practices yet that other volunteer projects successfully employ to
tackle strategic challenges.

2) Widening gap between staff and volunteer contributions:

As the Wikimedia Foundation began to professionali

Re: [Foundation-l] Gmail - List messages flagged as spam

[Erik Moeller]

I reached out to Google about this, and they tell me it should be
fixed later today, at least for misclassified listserv messages.
According to our contact there, the misclassification happened because
spammers have included images from Wikimedia projects in spam
messages. Let me know offlist if you see additional false positives
from here on.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] [Announcement] Rand Montoya leaving Wikimedia Foundation

[Erik Moeller]

Hello all,

I regret to inform you that Rand Montoya will be leaving the Wikimedia
Foundation. His last day with us will be September 30, 2010.

Rand has generously agreed to support and advise us for the next three
months as we're gearing up for the 2010 fundraiser while he looks for
opportunities outside Wikimedia.

Rand will especially help us close the loop on our discussions in
Bristol: finalizing the next version of the chapters fundraising
agreement, and coordinating a self-assessment process of the chapters
fundraising work to-date.

Since Rand joined us two years ago, he has been tremendously
successful in his work for the Wikimedia Foundation. The 2008 and 2009
fundraisers set new record revenue numbers for the organization, and
have enabled us to expand our mission activities and grow our impact
world-wide. Rand also helped us to establish good fundraising
practices, including improved donor communication and cultivation, and
led efforts to help the international Wikimedia chapters fundraise.

Please join me in thanking Rand for all he has done for Wikimedia, and
wishing him the best for his future.

All best,
Erik
--
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Self-determination of language versions in questions of skin?

[Erik Moeller]

2010/6/28 Tim Starling :
> In this case, I would recommend a process of negotiation. Detail your
> concerns in Bugzilla, and give the developers time to respond to them.

This is good advice. I want to add that there's something very unusual
about the work that's been done over the last year, relative to many
other software changes we've made over the years. Its primary audience
is not in fact the community of individuals who may participate in
polls or file bugs in BugZilla -- its primary audience are the readers
of Wikimedia Foundation projects who have knowledge to share, but who
may find our user interface and user experience too daunting to do so.

The changes we've made have therefore not been directed at experienced
editors at all, and insofar as we've considered their needs and
interests, our primary intent has been not to cause significant
impediments or inconveniences except where such inconveniences were
deemed necessary trade-offs to accomplish a better experience for new
users.

Our motivations for engaging in such a project are rooted in the
well-established trend of stagnation and, in some cases, decline of
key participation metrics in the largest Wikimedia projects. Those
trends can be seen clearly in the numbers of active contributors, and
the numbers of new editors joining the projects:

http://stats.wikimedia.org/EN/TablesWikipediansNew.htm
http://stats.wikimedia.org/EN/TablesWikipediansEditsGt5.htm

German Wikipedia, by the way, is no exception from this trend, and
indeed, shows a significant decline in the number of new editors
joining, and a less dramatic but still pronounced decline in the
number of active editors from its peak levels.

User experience, by its very nature, is habitual. Don Norman, in "The
Design of Everyday Things", describes many examples of idiotic design
decisions for everyday objects like doors, projectors, or stove top
controls. After initial irritation, we accept those design decisions,
get used to them, and will suffer another brief irritation when
someone tries to fix them.

The same is true for user interfaces in software. A degree of
temporary inconvenience when changing user interfaces is unavoidable,
and thus, any such change tends to be accompanied by voices of
frustration and irritation by established users who have learned the
habits the software forced them to learn. In no way is such
frustration or irritation alone evidence that the change was wrong: it
is entirely to be expected.

Agile user testing in small groups is a well-established methodology
for engineering a better user experience and surfacing key impediments
for new users of a given interface. The improvements we've made have
been grounded in real impediments people with no prior editing
experience have encountered when navigating Monobok's cluttered and
tiny tabs, utilizing the mystery toolbar (a trumpet? really?) [*],
finding the tiny search box in the sidebar, etc.

Thus, we are in favor of continued conversations about the best user
experience for Wikipedia, but we're not going to roll back the user
interface only because a self-selected majority of active editors vote
to decide to make it so. Let's have focused conversations about
whether the changes we've made serve the established need (creating a
better participation experience for new users) without unintended side
effects and unacceptable trade-offs. Surfacing normal change
resistance is not particularly helpful; surfacing facts and thoughtful
arguments certainly is, and we've tried to respond to those.

As many of you have seen, we've continued to make changes and apply
fixes to the new UX at a fast pace (see
http://www.mediawiki.org/w/index.php?path=/trunk/extensions/UsabilityInitiative&title=Special:Code/MediaWiki/path
) ; that pace will slow down in July due to Wikimania, but will resume
at full swing thereafter. We are also incrementally improving our
analytics (using open source tools) so we can better measure the
actual impact of everything we do.

All best,
Erik

[*] I'm personally responsible for the initial design of the edit
toolbar, and deeply appreciate the work that's been done by the team
to identify what people actually click on, come up with sensible
icons, and remove clutter. The toolbar was always conceptualized with
new editors in mind, and the new design serves that audience much
better.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Call for Volunteers: Wikimedia Research Committee

[Erik Moeller]

Hello all,

The Wikimedia Foundation is looking for volunteers who would like to
support the management of relationships between Wikimedia communities
and the broader communities of researchers who study Wikimedia
projects. We hope to create a committee with volunteers from both
groups with a rich combination of skills and backgrounds.

Here are some areas of work that this new Wikimedia Research
Committee, with help from the Wikimedia Foundation staff, is intended
to explore:

* developing policy around researcher permissions for non-public data
* supporting the development of subject recruitment processes
* reviewing research projects when conflicts-of-interest arise
* articulating and channeling requests for data and technical resources
* helping to formulate the key strategic research objectives of the
Wikimedia movement (see strategy.wikimedia.org)
* helping to formulate small tactical experiments related to
Wikimedia's strategic goals
* developing an open access policy as a requirement for significant
support from the Wikimedia Foundation
* helping create a "starter kit" for researchers to avoid duplication of effort

To date, many of these issues have been handled by the Wikimedia
Foundation on a case-by-case basis, with various points of contact and
unclear responsibilities. The research committee will act as a first
point of contact for many, if not most, of these requests, and help us
to formulate processes and policy beyond the boundaries of projects
and languages.

We are estimating the minimum time commitment for membership in this
committee to be 2-4 hours per week.

To be clear, we are also hiring additional research and engineering
staff. This committee is intended to work in close partnership with
Wikimedia Foundation staff.

If you are interested in joining this committee, please write an
off-list e-mail response to  with the
following information:

1) Your name and background;
2) Explanation of your role and interest in research projects and/or community;
3) Key areas of activity you'd like to focus on as a member of such a committee.

This will help us seed the committee with a diverse group of
individuals. The committee can later be expanded beyond the initial
membership, once internal processes for doing so are established
(similar to the chapters committee).

We look forward to hearing from you. :-) Please disseminate this
message further where relevant. We will aim to respond to applications
within two weeks.

All best,
Erik

-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Vice President?

[Erik Moeller]

On Wed, Feb 1, 2012 at 10:15 AM, Ryan Kaldari  wrote:
> Many organizations have dozens or hundreds of vice presidents, like Vice
> President of Vending Machines and Vice President of Pencil Sharpeners.

Heh. I've certainly been in the VP of Odds and Ends role before. :)

A little bit of context. As Stu and Kaldari mentioned, the VP title is
fairly common in the US, where it's actually often situated below the
"C-level" in the org. The reason Sue and I agreed on the title VP of
Engineering/Product for the engineering department has more to do with
the organizational vocabulary in this part of the world, where that
title does carry a very specific meaning relative to the CTO title.
You can read more about the differences in these posts:

http://www.bothsidesofthetable.com/want-to-know-difference-between-a-cto-and-a-vp-of-engineering/
http://www.feld.com/wp/archives/2007/10/cto-vs-vp-engineering.html
http://falseprecision.typepad.com/my_weblog/2007/10/cto-vs-vp-engin.html

Right now, we don't have a CTO, but we do have three Lead Architects
in the engineering department (Mark, Brion, and Tim). We may choose to
ultimately create a CTO role again, but it would probably be different
from the way we've treated that role in the past (as architectural
lead/visionary and process/delivery manager combined into one person).
We may also need to split the product/engineering responsibilities if
scale requires it.

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Wikimedia Foundation monthly meeting video

[Erik Moeller]

Every month, there's a meeting at the Wikimedia Foundation offices
(with remote call-in) where we review recent metrics and activities in
the different departments for the previous month. Starting with the
meeting covering January, which took place on February 2, we are now
capturing these meetings on video.

You can see the video capture for the most recent meeting here:
http://commons.wikimedia.org/wiki/File:Monthly_Metrics_Meeting_February_2,_2012.theora.ogv

Going forward, we will simply link to these videos from the monthly
report and not announce it separately.

Note that I've uploaded the highest resolution copy, which clocks in
at 1.9G (this should allow you to see pretty well what's going on on
the screen). This is inconvenient for streaming unless you have a very
good connection, so I recommend downloading. In future, videos will be
automatically transcoded to multiple resolutions, but if you'd like to
make a lower resolution copy available for the interim, it's
appreciated.

Feel free to respond in this thread if you have any questions about
the contents of the meeting. Generally the structure is as follows,
interspersed with questions, discussion and lawyer jokes:

* Erik, Garfield and Gayle walk through impact, finance and HR
metrics, respectively
* Department heads give updates about their respective areas
* Sue closes with some final words, typically referring to recent
events or organizational priorities

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] [Wikimedia Announcements] Announcement: Building a new Legal and Community Advocacy Department & Promotion of Philippe Beaudette

[Erik Moeller]

On Thu, Feb 9, 2012 at 8:44 PM, Casey Brown  wrote:
> "Advocacy" is a much more general term in this context than people
> seem to be taking it as. It does not mean lobbying or fighting for
> something controversial with outside organizations. As I understand
> it, it's the opposite: advocating to the Wikimedia Foundation on
> behalf of the community.

Yeah, that's my understanding of the game plan here as well. I think
the announcement could have been clearer in that regard, but that's
pretty much what Philippe and Maggie have already been doing, and what
they'll continue to do in a structure that's set up for growth.

Sometimes we have a tendency to speak in management lingo when we
should be choosing simple, crisp & clear terms. Honest feedback: Burn
the chart on 
http://meta.wikimedia.org/wiki/Legal_and_Community_Advocacy/LCA_Announcement
and draft a super crisp mission statement to slap on the first page
for this group. I know, I've been guilty of this as well -- no
criticism of the team. When working in an organization this kind of
communication style is often expected from you in day-to-day work, but
it's not necessarily helpful when communicating with people who have
very little time and interest to parse it.

I think the brainstorming page is a great start and hope it'll be
utilized and further advertised in coming days:

http://meta.wikimedia.org/wiki/Legal/Community_Advocacy

Congratulations to Philippe and Maggie for their new roles. I think
it's about time that we're creating this structure, and I think it'll
generate lots of tangible value for the community.

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] [Wikimedia Announcements] Announcement: Building a new Legal and Community Advocacy Department & Promotion of Philippe Beaudette

[Erik Moeller]

On Thu, Feb 9, 2012 at 10:46 PM, Theo10011  wrote:
> Then my suggestion would be, rename the department.

I think the name's pretty spot-on, actually: advocating on behalf of
the community. It's the elucidation of that concept that needs to
happen to avoid confusion.

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] [Wikimedia Announcements] Terry Chay joins WMF as Director of Features Engineering

[Erik Moeller]

Hello all,

It’s with great pleasure that I’m announcing that Terrence (Terry) Chay is
joining the Wikimedia Foundation as Director of Features Engineering.

Terry comes to us from Automattic, where he helped improve the
WordPress.com user experience by implementing an A/B testing framework,
improving the blog domain name registration process (which contributed to
doubling the revenue for WordPress.com), creating better support mechanisms
for fist-time users, and making many other changes. In that role, he was an
individual contributor to the WordPress codebase.

Before Automattic, Terry worked as an engineering manager and software
architect for multiple start-ups and tech companies between 1999 and 2009,
most recently at Tagged and Plaxo. He has a B.S. in Physics from the
California Institute of Technology and an M.S. in Physics from the
University of Illinois at Urbana-Champaign (UIUC).

If you’ve ever been to OSCON, you may have seen Terry present one of his
infamous PHP talks there (he’s been invited back repeatedly for some
reason). All in, he’s given more than 25 public talks about web
development. He’s also a prolific blogger and photographer (
http://terrychay.com/ ), joining the nascent photography cabal at Wikimedia.

As Director of Features Engineering, Terry will be responsible for helping
ensure the success of some of our key feature teams: the visual editor
team, the editor engagement team (including the article feedback project),
and the fundraising engineering team.

This announcement also means that Alolita Sharma will be transitioning into
a new director-level role at the Wikimedia Foundation. While we’ve not
finalized all details, the role will include responsibility for the
internationalization team, for experimental features projects and
technology evaluation. We’ll announce details about that shortly. I want to
thank Alolita for her track record of excellent leadership at Wikimedia
to-date.

Terry's first day will be February 27. Please join me in welcoming Terry to
the Wikimedia movement. :-)

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
___
Please note: all replies sent to this mailing list will be immediately directed 
to Foundation-L, the public mailing list about the Wikimedia Foundation and its 
projects. For more information about Foundation-L:
https://lists.wikimedia.org/mailman/listinfo/foundation-l
___
WikimediaAnnounce-l mailing list
wikimediaannounc...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Communicating effectively: Wikimedia needs clear language now

[Erik Moeller]

On Sun, Feb 19, 2012 at 3:16 AM, Tom Morris  wrote:

> Mostly though, thanks to the Internet and multinational corporations,
> godawful business jargon crosses all national borders. Words and
> phrases like 'onboarding', 'stakeholders', 'mission statements',
> 'platforms', 'proactive', 'sectors' and pretty much anything
> 'strategic', for instance.

Terms like "strategy", "mission statement" and "stakeholder" have
concrete organizational meaning. Yes, they are also often used as part
of marketing copy or organizational copy in ways that are unhelpful,
because people who aren't good writers feel the need to plug holes by
picking from the shared vocabulary of organization-speak. That doesn't
make them meaningless, anymore than the fact that every idiot has an
opinion on quantum physics makes quantum physics meaningless.

Where I agree with you: It's the job of any writer to make their
message accessible and understandable, where possible by using plain
language. It's probably good to maintain a healthy degree of prejudice
against "organizational jargon", just because it is so prevalent and
often used poorly.

However, organizational development and management are serious human
endeavors that merit open-mindedness and willingness to discover and
learn on the reader's part just as much as they merit clarity and
brevity on the writer's or speaker's part. Being simplistic about the
"corporate world" is no more charming or noble than is ignorance about
any other field.

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Wikimedia Foundation Mid-Year Presentation to the Board of Trustees

[Erik Moeller]

Hi folks,

on February 3, the Wikimedia Foundation senior staff gave a
presentation to the Board of Trustees as part of its Board meeting in
San Francisco, recapping the fiscal year so far (our year begins July
1) and looking ahead. The slide deck is now available here:

https://wikimediafoundation.org/wiki/File:Wikimedia_Foundation_Mid-Year_Review_February_2012.pdf

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] A discussion list for Wikimedia (not "Foundation") matters

[Erik Moeller]

Hi all,

We currently have this public list for Wikimedia Foundation matters,
as well as a private list called "internal-l" which in practice is in
large part used for WMF/chapters discussions, because chapter board
members are added to it by default. The latter is often used for
discussions that impact community members, but neither the discussions
nor the results are always a matter of public record.

Unfortunately, the name foundation-l is also one which signals
exclusion; it pre-dates the very complex and large network of
organizations and individuals that we are today.

Others have made this suggestion before me, and I like it, so I've
tried to put it into a proposal: Let's have a public list that's
clearly named and scoped to be relevant to all Wikimedia matters.
We're too big and too complicated to fit comfortably under the
"Foundation" umbrella any longer.

That new list wouldn't be intended to replace foundation-l (which
would continue to be used for matters strictly related to the
Wikimedia Foundation) or to internal-l (which may have some legitimate
uses, although I personally find it unnecessary and unsubscribed from
it).

The full proposal is here:
https://meta.wikimedia.org/wiki/Wikimedia-l_proposal

I'd appreciate your thoughts and comments here or on-wiki.

All best,
Erik

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] A discussion list for Wikimedia (not "Foundation") matters

[Erik Moeller]

On Thu, Mar 1, 2012 at 7:14 AM, Samuel Klein  wrote:
> That sounds reasonable.  Most things discussed on this list are not
> specially relevant to the Foundation.

OK. Any strong objections to changing the list name and scope (the
latter being the description at
https://lists.wikimedia.org/mailman/listinfo/foundation-l ) to be
all-encompassing for Wikimedia-wide issues?

The rename would likely occur by unsubscribing current members from
this list and re-subscribing them to the new one, to avoid breaking
links or accidentally corrupting archives -- meaning that list
archives pre-move would be accessible via a different URL, which could
be prominently advertised in the list description.

> I do think many discussions can be moved from internal-l to this list;
> and on occasion people have suggested that foundation-l is a less
> suitable place for an otherwise public discussion simply because the
> name seems exclusive to the WMF.

Agreed -- creating a forum that feels welcoming to everyone,
regardless of their specific affiliations, is one of my strongest
motivations here.

Erik

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] introduction (community communications for Wikidata)

[Erik Moeller]

On Fri, Mar 9, 2012 at 12:36 PM, Kim Bruning  wrote:

> http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/Wikidata/
>
> I haven't looked at that in a while.
> Heh, I wonder what the current status is?

Kipcool's the primary maintainer, and I believe it's exclusively used
on http://www.omegawiki.org/ at this point (which is still alive,
warts and all).

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Guidelines for the use of iframes?

[Erik Moeller]

HR recently switched to an externally hosted applicant tracking system
called Jobvite. It's sadly proprietary, but very feature-rich and used
by many tech companies, including e.g. Mozilla. Basically the previous
process was for candidates to be dumped in a shared inbox, where
recruiters and hiring managers would have to keep track of them with
the aid of tracking spreadsheets and lots of emails. An ATS automates
a lot of the tracking and workflows, and helps ensure that people
don't get dropped. It also sends hiring managers reminders to submit
all the required hiring documentation, etc. So in general it's a good
thing, although we sometimes curse at aspects of its UI.

The rationale for the iframe is to automate the job listings on the
WMF site and surface the various Jobvite features.

Yes, that means that the user's browser will contact hire.jobvite.com
when loading the page (although all its resources will be loaded in
the context of the iframe). AFAICT the main issue here is to clarify
in the footer that job applications and job descriptions are run
through an external service called Jobvite and subject to the Jobvite
privacy policy, to avoid any confusion.

Whether the iframe is a good idea still remains to be seen. Jobvite
makes it unnecessarily hard to link to JDs directly (because their
ideology is that everyone should come through some social media
funnel, I think), and the navigation is heavily JS dependent right
now. So we might want to switch back to a hybrid format. The job pages
are also still actively being re-designed, and the setup might change
significantly in coming weeks.

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] [Wikimedia Announcements] Fwd: Announcement: New editor engagement experiments team!

[Erik Moeller]

On Tue, Mar 20, 2012 at 11:10 PM, Liam Wyatt  wrote:
> I think it would greatly help if we could have an updated organisation
> chart of who is reporting to whom, and what departments they are all in.

The static graphics stopped being maintainable. We're exploring a
couple of options for data-driven org chart generation and should have
a publicly visible up-to-date org chart again soon.
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Pages very slow to load since March 21

[Erik Moeller]

On Sat, Mar 24, 2012 at 5:00 PM, Sarah  wrote:

> Could someone from the Foundation confirm that they're looking into
> it? It's getting to the point where it's quite hard to edit.

Tim's investigating it now.

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Pages very slow to load since March 21

[Erik Moeller]

On Sat, Mar 24, 2012 at 5:16 PM, Erik Moeller  wrote:
>> Could someone from the Foundation confirm that they're looking into
>> it? It's getting to the point where it's quite hard to edit.

> Tim's investigating it now.

This appears to have been a networking issue causing packet loss and
timeouts, which should be resolved. Please reopen bug 35448 and
provide details if you can reproduce the issue at this time.

Thanks to Leslie and Tim for investigating.

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] A discussion list for Wikimedia (not "Foundation") matters

[Erik Moeller]

On Mon, Mar 5, 2012 at 7:29 AM, Nathan  wrote:
> I think wikimedia-l would work fine and make sense. We probably don't need
> an additional list, a lot of the lists we have now are lightly used.

Picking this up again .. I'll go ahead and make this change on
Saturday 4/7, unless there are strong objections. Moving this list to
wikimedia-l seems like the least disruptive change for now,
acknowledging that its scope has long expanded beyond WMF matters.

This is the only change -- all other list parameters would stay the
same, so as to not surprise and annoy people by rolling up unrelated
changes.

In future we may -
a) find that this is perfectly sufficient and leave it at that,
b) create "movement-l" to discuss the wonderful bureaucracy that we're
busily creating in more dedicated and extensive depth,
c) create any other divisions that make sense, or not. :-)

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] A discussion list for Wikimedia (not "Foundation") matters

[Erik Moeller]

On Mon, Apr 2, 2012 at 10:37 PM, MZMcBride  wrote:
> It's a matter of creating a separate list and importing the members from the
> current list (foundation-l), right?

Yep.

> Will foundation-l@lists.wikimedia.org
> continue to function after April 7 (as a redirect/alias) or will only the
> new address?

Only the new address unless we're being extra clever, which I'm not
sure is necessary.

> Will the archives be permanently split?

Probably -- advanced mailman surgeries carry a high risk of fatal
mistakes (e.g. we have a fancy pipermail URL alias, but the archive
rebuild is causing URLs to change, or some such nonsense), so it's
generally best to avoid them. But I'll ask Daniel Zahn, who's
performed some trickier surgeries recently without fatalities (as far
as I know).

> Are there any other consequences of a list rename?

You will feel a great disturbance in the Force, as if millions of
voices suddenly cried out in terror and were suddenly silenced.

> I'll note (again) that in your 2004 proposal to create "foundation-l" you
> specifically cited the desire to "avoid 'Wikipedia/Wikimedia' style typos"
> by not choosing "wikimedia-l" as the list name.[1] I'm still not sure a move
> (from "foundation-l" to "wikimedia-l") has more benefit than cost.

I am indeed aware of my own objection, even if it is somewhat dated.
The main reason for making this change, IMO, is to account for
sensibilities and perceptions that largely did not exist in 2004, when
"Foundation" first and foremost referred to a bunch of people who
cared more about meta-issues than others -- the org as such barely
existed beyond paper, let alone the complex network of chapters, the
GLAM groups, etc.

Now, when you have discussions like the recently posted Draft Charter
of the Wikimedia Chapters Association, or the previous extensive
discussions about fundraising, to undertake them in a venue named
after one specific org serves as a distraction, and has caused some
people to express that they don't want to participate because it's a
list for "Wikimedia Foundation matters", giving people justification
to move things to private lists that should be public.

So, names do matter. I'd be happy to have an even more generic name
that avoids potential typo issues, but I do think the benefit of
making the name less WMF-centric outweighs the cost.

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] WMF Engineering org charts

[Erik Moeller]

Hi folks,

as I mentioned in a response to Liam the other day, we've been working
on having org charts generated in a more automatic, scalable form.

A contractor, Mark Holmquist, has been working on an open source tool
for this the last few weeks to do this. It's still highly
experimental. In particular, we're exploring alternative layout
options (full horizontal only works well for small org charts). Don't
be surprised if it breaks or behaves weirdly, and Mark may be making
changes to the labs setup at any time.

Most importantly, it's only engineering right now. I've plopped in a
couple of examples for the other depts, but ignore those until they're
built out, provided my colleagues are happy with the tool. This is not
authoritative, and there are almost certainly errors, beyond the
aforementioned omission of all other departments. :)

Explanations:
* The little flags represent locations. Typically they're ccTLD
country codes, except for SF for the SF office.
* Mousing over a node in the chart gives you extended information.
* (E) = employee, (C) = contractor
* Dashed border = this is a contractor role that's not part of the
overall capacity plan and funded out of the general "outside
contractor services" budget

The tool makes it possible to have unique URLs for any subset view of
the chart, and that's the best way to use it. These are the
departments in engineering/product:

TechOps:
http://orgcharts.wmflabs.org:/#of-unit-box-for-4f5e806d0b3d0d0f2e09

Features:
http://orgcharts.wmflabs.org:/#of-unit-box-for-4f5e806c0b3d0d0f2e03

Platform:
http://orgcharts.wmflabs.org:/#of-unit-box-for-4f5e806c0b3d0d0f2e07

Mobile:
http://orgcharts.wmflabs.org:/#of-unit-box-for-4f6cd85eeef7b9380402

I18N/R&D:
http://orgcharts.wmflabs.org:/#of-unit-box-for-4f6cff2d9f293f1b1301

Product:
http://orgcharts.wmflabs.org:/#of-unit-box-for-4f6d01199f293f1b1303

All of engineering:
http://orgcharts.wmflabs.org:/#of-unit-box-for-4f5e806c0b3d0d0f2e02

Code is currently here and will be moved to WMF git repo soon:
http://code.marktraceur.info/?p=wmf-orgchart;a=summary

If you'd like to be involved or provide detailed feedback for
improvement, please post to the talk page here:
https://www.mediawiki.org/wiki/Wikimedia_tools/Org_chart_tool

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] WMF Engineering org charts

[Erik Moeller]

On Wed, Apr 4, 2012 at 5:45 PM, George Herbert  wrote:
> Has this been an observed issue within the WMF?

In some areas. In my view, a well-functioning agile team is
self-organizing and self-managed, and it's a manager's job to
primarily set that team up for success, hire the right people, replace
the people who aren't working out, and help escalate/resolve blocker
or coordination issues outside the team's scope. Putting so much
responsibility on the team's shoulders is in my opinion a good thing,
because it treats them as adults accountable and responsible for the
success or failure of their own work.

Where we're trying to complete complex projects with a part of a
person's time here, a part of a person's time over there, we lean
heavily on managers to help with the resource scheduling and project
organization, and that's where things are currently getting iffy at
times. In our 2012-13 hiring plan submission, we're proposing a
Dev-Ops Program Manager position to help with some of the particularly
hairy cross-coordination of complex, under-resourced backend projects
with operations implications (an example of that kind of project is
the SWIFT media storage migration).

There'll likely also be another layer of depth in the org chart as we
grow and evolve further, but that's something to do very carefully
because it increases real or perceived distance between people, and
making people managers of 1-2 people is fairly inefficient.
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] help.wikimedia.org - Q&A site

[Erik Moeller]

On Fri, Apr 6, 2012 at 2:07 PM, Peter Coombe  wrote:
> Wasn't there a proposal a while back for a Stack Exchange [1] site
> like this? It seems like the ideal software for it.

StackExchange and the open source OSQA equivalent are indeed powerful
tools and worth experimenting with. Anyone wanting to set up a public
instance of these or other tools to play with can do so through
Wikimedia Labs and of course the toolserver. See
https://labsconsole.wikimedia.org/wiki/Help:Access for Labs access and
policies.

We've focused on creating a more integrated help experience with two
projects, the feedback dashboard (FD) and the teahouse.

The FD gives new editors an opportunity to ask a question or register
a complaint. It pops into view the moment you first click edit, which
is a more obvious affordance than a separate help site you have to
find out about and visit. It's been active on en.wp and nl.wp for a
few months, and was recently activated on French Wikisource as well.
On en.wp, we register about 100 feedback submissions a day, and about
30-50 responses.

FD includes a few features which elevate it above ordinary talk page responses:
- an in-line response tool on the dashboard itself which shortcuts the
path to the user's talk page
- a "mark as helpful" feature which the recipient of a message can use
to indicate that they were helped.
- friendly email notifications (not the standard talk page notifiers)
- a leaderboard of top responders, which has been helpful at
incentivizing participation

FD for English Wikipedia: http://en.wikipedia.org/wiki/Special:FeedbackDashboard
FD for Dutch Wikipedia:
http://nl.wikipedia.org/wiki/Speciaal:DashboardTerugkoppeling
FD for French Wikisource:
http://fr.wikisource.org/wiki/Sp%C3%A9cial:FeedbackDashboard

We're currently letting the project sit for a while to gather metrics
about any impact it has on editors who are being helped.

The teahouse is a less technical and more social initiative:
http://en.wikipedia.org/wiki/Wikipedia:Teahouse

It is supported by some shiny templates and a nice little in-line
response gadget. But it's primarily an effort to mobilize lots of
people to engage in user-to-user help. As you can see, lots of folks
have signed up as hosts (people who respond), and early metrics
indicate that there's indeed a positive impact on retention.

http://meta.wikimedia.org/wiki/Research:Teahouse/Metrics

IMO setting up a separate Q/A site would be in some ways a workaround
for Wikimedia's poor internal discussion system, and would incur lots
of disadvantages (detached from workflows, no easy login integration,
no easy integration of wiki markup / templates, separate technical
infrastructure with additional maintenance/scalability/security
burden, need for additional policy development on copyright, terms of
use, etc. ..). But it's worth experimenting with, for sure, if
only to find out what UI/UX patterns are worth applying to our own
solutions.

LQT is on hold for now, because it's an overambitious and
underresourced project. We're going to start work soon on this
project:
http://www.mediawiki.org/wiki/Echo_(Notifications)

This is a larger effort to improve Wikimedia's notifications
infrastructure, and will lay the groundwork for messaging
improvements, as well as other next generation features. We hope that
we'll be able to improve user-to-user messaging features in this
process,  which would be a technical foundation for improved direct
user support systems.

For the tech side of things, our goals for next fiscal are still
draft, but give a good idea what we're thinking about (pending
approval of associated staffing/funding):
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2012-13_Goals

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] WMF Engineering org charts

[Erik Moeller]

On Wed, Apr 4, 2012 at 9:46 PM, Thomas Dalton  wrote:
> What about personal development? Do your managers play an active role
> in helping their reports develop with objectives, feedback, training,
> etc?

Yes, of course. There's a standard $ allotment for each employee in
the budget to support training, courses, coaching, etc. and
managers/employees are encouraged to explore options together. In
practice, some people take more advantage of this than others, of
course -- and to be fair, some managers do a better job at it than
others, which in my experience is more a function of management
experience and personality than it is of number of reports.

Gayle's office plays an important role in bringing fairness into the
process, sharing info about development opportunities and options,
setting standards about goal-setting and performance management, being
available for deeper conversations, exploration of coaching options,
etc.

Erik

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] A discussion list for Wikimedia (not "Foundation") matters

[Erik Moeller]

Looking a bit further into the best way to do this - since mailman
doesn't have any sensible export/import features that retain list
member settings, we'll probably need to make a full copy of the list
on the server, and then remove the members of the old one. I'll ask
Daniel to look into that next week and have held off for now.

As for archives, Daniel says it shouldn't be a problem to keep the old
archives under the old URL, but to also to copy them (with new URLs)
into the new list. The only disadvantage I see that in the event we
need to do any removals of old posts, we'll need to remember to do it
in both places.

All best,
Erik

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

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Wikimedia Foundation Elections 2009 ( 2011 ? ) & Bots

[Erik Moeller]

On Fri, Jun 10, 2011 at 7:41 AM, Andrew Garrett  wrote:
> In this case, the bot qualified on Norwegian Wikipedia.
>
> It's looking like global bots which aren't flagged everywhere are an
> edge case that should be addressed next time around.

I for one welcome our new interwiki bot overlords.

Thanks Andrew for getting this out, and our apologies for the quirks
this time around.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Fwd: Announcement: WMF engineering promotions and role changes

[Erik Moeller]

FYI :-)


-- Forwarded message --
From: Erik Moeller 
Date: Mon, Jun 20, 2011 at 5:58 PM
Subject: Announcement: WMF engineering promotions and role changes
To: Wikimedia developers 


Hi folks,

I’m pleased to announce the following promotions and role changes in
engineering, effective immediately.

* Rob Lanphier is the Director of Platform Engineering.
* Tomasz Finc is the Director of Mobile and Special Projects.
* Alolita Sharma is the acting Director of Features Engineering.
Alolita has gracefully agreed to take on this role, for which we’re
kicking off a full search process.
* Mark Bergsma is now the Lead Operations Architect, reporting to CT.
* Tim Starling is now the Lead Platform Architect, reporting to Rob.

I’ll explain a bit more what these roles mean below, but first, please
join me in congratulating Rob, Tomasz, Alolita, Mark and Tim! :-)

Let me also take this opportunity to thank Danese Cooper for helping
to build and professionalize the Wikimedia Foundation engineering
organization as Wikimedia’s CTO.  She also set these changes in
motion, and our overall strategy is one that we’ve begun developing
and socializing together in the last few months.

Here’s how these roles fit together. The engineering department is
principally structured into four sub-departments, each headed by a
director who is the functional manager of all people within that
sub-department:

* Technical Operations - CT Woo: Keep Wikimedia Foundation sites and
services running, increase uptime and performance, support code
deployments, and ensure recoverability of data and services.
* Platform Engineering - Rob Lanphier: Maintain and support the
MediaWiki platform; ensure reliability, maintainability, and
performance of our software; lead the release management process; grow
and nurture the developer community and ecosystem.
* Features Engineering - Alolita Sharma (Acting): Advance Wikimedia’s
strategic priorities by focusing resources on specific feature
projects such as the visual editor, or interventions designed to
increase editor retention.
* Mobile and Special Projects - Tomasz Finc: Advance Wikimedia’s
mobile platform and ensure that mobile devices are fully considered
across the engineering development process; execute projects with
strong overlapping requirements (e.g. offline delivery of Wikimedia
content).

We’re also recognizing the importance of architectural engineering
leadership in the development of a mature engineering organization
(which also represents an additional career path for our distinguished
engineers beyond “become a manager”). The three architects - Tim, Mark
and Brion - will work together as follows:

* Brion Vibber, as Lead Software Architect, has key architectural
responsibility for getting MediaWiki ready to be the world’s leading
tool for mass collaboration, by enabling the development of new
technologies like the visual editor (his current priority), real-time
collaboration, improved discussion systems, etc. This also includes
architectural leadership to support bottom-up feature development.
Brion reports directly to me.
* Mark Bergsma, as Lead Operations Architect, is responsible for
creating and communicating the vision and roadmap for the
infrastructure needed to run all Wikimedia projects, for ensuring the
design/implementation of our operating environment is reliable,
scalable, supportable, secure and cost-effective, and for driving
cross-functional alignment, especially with other engineering
functions.
* Tim Starling, as Lead Platform Architect, is responsible for the
performance, stability, security and architectural cleanliness of the
MediaWiki platform. Tim is leading potentially transformative
engineering projects like the HipHop support in MediaWiki. He’s also a
key mentor to all MediaWiki developers and is keeping us honest while
we’re pursuing our feature dreams.

In addition, we’re considering the shape of product and project
management outside the Director-level leadership in the department.
Currently, Howie Fung (Senior Product Manager) and Dario Taraborelli
(Senior Research Analyst) are continuing to support our feature
development projects to ensure that 1) development is aligned with
strategic priorities, 2) we’re focusing the development on the needs
of the user, 3) we’re making data-driven decisions and working
effectively with the global wiki research community, 4) we’re engaging
with the Wikimedia editor and reader community on complex feature
development projects.

I’m taking on the role of VP of Engineering and Product Development,
on an interim basis for now. We’re not going to immediately hire
either for that role or a CTO role. Thanks to Mark, Tim and Brion, we
have very strong architectural leadership in the department. Moreover,
we’ve got more than enough disruptive change as an engineering
organization to absorb for now, so we’ve decided that it doesn’t make
sense to immediately bring in a new person to lead the department.

We may decide

Re: [Foundation-l] [Wikimedia Announcements] Welcome Tilman Bayer to the Wikimedia Foundation

[Erik Moeller]

Welcome HaeB! Great to have you on-board. :-) I've been waiting for
this announcement -- lots of stuff to do!


-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Start "questions and answers" site within Wikimedia

[Erik Moeller]

On Fri, Jul 22, 2011 at 1:25 AM, Oliver Moran  wrote:
> The issues you raise about open-source vs. proprietary software, that's an
> open-source vs. proprietary software debate - and one that sounds like it is
> on the ideological edge of that arena. As a software engineer who develops
> proprietary software, I can almost guarantee that a whole bunch of
> open-source software (e.g. MIT licenced) is in the Stack Exchange software.
> Indeed, just by looking at their web source its possible to see proof of
> that. Because of this, the matter of the benefits of open source software
> vs. the proprietary software is a theoretical one. In modern practise, the
> two cannot be so cleanly separated.

There's a simple question: Can you run all key services relevant to
Wikimedia using only free/open software? If the answer is no, we're
losing something very important, which isn't merely about sticking to
our guns, but about ensuring the survivability of what we're doing for
not just years, but decades to come.

I think the idea of a dedicated Q/A site is an interesting one -- but
not necessarily the best way to address the underlying problem. We're
test-deploying a small feature for microfeedback (including requests
for help) from new users next week. The initial deployment is designed
to assess the signal/noise ratio of such microfeedback & make a
decision about whether to iterate further on that model. You can read
a bit more here:
http://en.wikipedia.org/wiki/Wikipedia:VPT#Quick_Feedback_on_Editing_Experience:_New_Editors

Such systems could potentially be expanded further, as can systems
like the new Article Feedback tool, to carefully manage, curate and
respond to a wide variety of subjective information flows from
questions to comments to reviews. In the meantime, StackOverflow,
Quora & friends are spending very substantial effort improving their
editing features, e.g.:
http://blog.stackoverflow.com/2011/07/faster-edits-with-inline-editing/

IMO the convergence of curation and collaboration systems for
subjective & objective information flows is a pretty natural
development and one which we shouldn't be afraid of.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] [Wikitech-l] Tragedy: videos and slides from presentations Wikimanias (lately 2011 in Haifa)

[Erik Moeller]

On Tue, Sep 6, 2011 at 11:02 AM, Brion Vibber  wrote:
> The code exists and has been revamped a few times in response to reviews,
> but I'm not sure whether there are actually any assigned resources for
> pushing it to production at this time.

Yes, there are. Ian and Neil are scheduled to do a code review of TMH,
once remaining high priority issues with UploadWizard have been
resolved, later this month. Before we've done an initial assessment of
the code, it's hard to give a realistic deployment estimate -- there
may be parts that need to be rewritten or taken out. So I won't commit
us to a public date just yet, just to say that it's definitely
something I'd like to see user-visible progress on this calendar year.

Whatever remaining bugbears are lurking in the code, TMH definitely
represents the key set of features that are needed to make video in
Wikimedia projects suck significantly less (multi-codec and
multi-bitrate derivatives generation; a non-ugly player skin; subtitle
support). This is really a baseline feature set that we have to get
done (this and better large file upload support) to not give users an
embarrassingly bad video experience.

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Very sad news

[Erik Moeller]

On Wed, Sep 7, 2011 at 4:52 PM, emijrp  wrote:
> Michael S. Hart has died http://www.gutenberg.org/wiki/Michael_S._Hart

:-(

A terrible loss. A beautiful legacy.

Erik

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] A Wikimedia project has forked

[Erik Moeller]

On Mon, Sep 12, 2011 at 1:50 PM, Tempodivalse  wrote:
> I thought the Wikimedia community should know that a large portion
> of WIkinews' contributor base has forked into its own project 
> (http://theopenglobe.org)

Congratulations to the successful launch of the fork and good luck!
Hopefully this will lead to some new discoveries that will benefit all
efforts in this space.

All best,
Erik

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] A Wikimedia project has forked

[Erik Moeller]

On Mon, Sep 12, 2011 at 3:24 PM, MZMcBride  wrote:
> The current reality is that nearly any
> project besides the English Wikipedia has almost no technical support.

That's a misunderstanding of what's happening.

I would characterize WMF's prioritization as an "A rising tide lifts
all boats" policy. Improvements are generally conceived to be widely
usable, both in Wikimedia projects and even outside the Wikimedia
environment, and to have the largest possible impact. Even if a first
deployment is Wikipedia, they will generally benefit other projects as
well.

But let's take other completed extensions as examples.

1) WikiLove has been enabled on Swedish, Malayalam, Hungarian, Hebrew,
Arabic, and Hindi Wikipedia, as well as Commons, all on request of the
respective project communities.

2) ArticleFeedback has been enabled on Hungarian Wikipedia, Portuguese
Wikibooks, and Hindi Wikipedia. (Wikinews, BTW, still runs the
predecessor ReaderFeedback extension.)

3) Narayam (an extension to support Indic languages) has been enabled
on Malayam Wikibooks, Wikiquote, Wiktionary, Wikisource and Wikipedia,
Tamil Wikibooks and Wikisource, and Sanskrit Wikipedia, Wikibooks,
Wikisource, and Wiktionary.

MoodBar will be made more widely available as it matures. And so on
and so forth.

It's true that English Wikipedia often (not always) serves as a
staging ground for new features, but that's an entirely different
matter and doesn't negate the intent of achieving maximum
cross-project/cross-site impact with the work we do.

It's also not true that Commons development has anything to do with
grant money. WMF received a one-time grant for Commons-related
development, but all recent development has been funded from WMF's
operating budget, and it's part of our standard roadmap -- for the
simple reason that investing in Commons serves all our projects and
increases our impact world-wide. And that's, of course, why we sought
the grant in the first place, not the other way around.

It is true that projects like Wikinews and Wiktionary, to fully
succeed (if success is possible), almost certainly require more
specialized product development and devotion in addition to the
general development work that benefits all projects.

It's my own view that specialized development is best-served by
ensuring that we give the global community great spaces to innovate
and create new things. We've put quite a bit of development effort
recently into improving MediaWiki's support for gadgets, and we're
also working on the Wikimedia Labs project to this end (
http://www.mediawiki.org/wiki/Wikimedia_Labs ). WMF's role for
specialized improvements should ideally be to review and deploy code
that's ready to serve a well-identified purpose and that doesn't have
harmful side-effects.  Where we haven't don't do so in a timely and
reasonable fashion, we must strive to do better.

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] A Wikimedia project has forked

[Erik Moeller]

On Mon, Sep 12, 2011 at 4:45 PM, K. Peachey  wrote:
> Ahem, The first of those were Hindi, and that was basically only after
> a B# fight in the bug report that there shouldn't be any restriction
> to installing it on the non en.wikipedia project

With any feature there are normal considerations about when it's ready
to be pushed out more widely. Having a feature that's under very
active development, with known issues, widely deployed beyond its
original staging ground can cause significant and avoidable burden.
That's what those discussions are about (which were mirrored by
internal conversations about readiness). There's no internal WMF
faction that argues for "only serving English Wikipedia", and there
never has been.

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] A Wikimedia project has forked

[Erik Moeller]

On Mon, Sep 12, 2011 at 5:26 PM, MZMcBride  wrote:
> My point is that without specific focus, these
> other sites languish and slowly die. A software package that was built for
> an encyclopedia can't work for a dictionary. It doesn't work for a
> dictionary. It also can't and doesn't work for a number of other concepts.

Of course, up to this point we all agree. That said, far from a myopic
focus on English Wikipedia, strategies to support specialized needs
and exploration of new ideas have long been very much a high priority
for WMF. It's an issue that's very clearly articulated in the
"Encourage Innovation" section of the strategic plan:

[begin quote]
  Support the infrastructure of networked innovation and research.
  - Develop clear documentation and APIs so that developers can create
applications that work easily with our platforms.
  - Ensure access to computing resources and data for interested
researchers and developers, including downloadable copies of all
public data.
  - Continually improve social and technical systems for volunteer
development of core software, extensions, gadgets and other technical
improvements.

  Promote the adoption of great ideas.
  - Develop clear processes for code review, acceptance and deployment
so that volunteer development does not linger in limbo.
  - Organize meetings and events bringing together developers and
researchers who are focused on Wikimedia-related projects with
experienced Wikimedia volunteers and staff.
  - Showcase and recognize the greatest innovations of the Wikimedia
movement, and create community spaces dedicated to the exploration of
new ideas.
[end quote]

http://strategy.wikimedia.org/wiki/Wikimedia_Movement_Strategic_Plan_Summary/Encourage_Innovation

That strategy is very much reflected in our actions and our budgeting,
as is evident from consulting recent activity reports.

One can legitimately criticize that this helps achieve incremental
improvements across the board, but leaves a gap of "large, focused
investment to meet specialized needs" (e.g. build new software to
support a wiki-based dictionary). But it doesn't necessarily have to
do so.

IMO, the question that's worth asking is: What's the constraint that's
keeping more people from launching successful initiatives under the
Wikimedia umbrella?  There are clearly both technical and social
constraints. One technical constraint is the fact that taking an
initiative from scratch to a successful launch requires considerable
WMF support along the way. How can we reduce the need for WMF
organizational support?

The Wikimedia Labs project (
http://www.mediawiki.org/wiki/Wikimedia_Labs ) is designed to push
that boundary. In the "Test Dev Labs" environment, the goal is to make
it possible to test and develop software under conditions that are
very close to the WMF production environment. This means that,
provided you're willing to invest sufficient resources, you should be
able to get a project much closer to "WMF readiness" than you are
today with far less WMF help. Indeed, it is designed to not become an
on-ramp for new volunteers not just in development, but also site
operations.

That's of course a risky project and it may not live up to our
expectations. But it's IMO a smarter bet to make than just picking
(with an unavoidable element of arbitrariness) one of the many
specialized areas in which we currently aren't succeeding and throwing
$ and developers at it. Because it could enable us to approach far
more organizations and individuals to invest time and money in complex
free knowledge problems without having to pass through the WMF
bottleneck.

There are literally thousands of mission-driven organizations that
would love to find ways to help solve problems in the free knowledge
spaces we're occupying. Yet, even Wikimedia's own chapter
organizations are still only a relatively small part of the ecosystem
of technical innovation (which is no discredit to the many things they
have done, including some great technical work).

Having organizations take on challenges either because they are
inherently suited to do so, or simply because they have the
organizational bandwidth, seems like a fairly rational path to
increase our ability to get things done. If that's the world we want
to live in, it also seems entirely rational to me that WMF should
focus on general high impact improvements while continually investing
a considerable amount of its capacity in helping more people to build
great things.

In addition to technical support systems, forks can be a very good and
healthy part of that development (to break out of social constraints),
as can be the development of new organizations.  A Wikinews
Foundation, or a Wiki Journalism Foundation, or some other such
construct may make a lot of sense in the long run, specifically when
it comes to the problem of citizen journalism.

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

Support Free Knowledge: http://wikim

Re: [Foundation-l] Blog from Sue about censorship, editorial judgement, and image filters

[Erik Moeller]

On Wed, Sep 28, 2011 at 11:45 PM, David Gerard  wrote:
> The complete absence of mentioning the de:wp poll that was 85% against
> any imposed filter is just *weird*.

The intro and footer of Sue's post say: "The purpose of this post is
not to talk specifically about the referendum results or the image
hiding feature"

She also wrote in the comments: "What I talk about in this post is
completely independent of the filter, and it’s worth discussing (IMO)
on its own merits"

So it's perhaps not surprising that she doesn't mention the de.wp poll
regarding the filter in a post that she says is not about the filter.
;-)

Now, it's completely fair to say that the filter issue remains the
elephant in the room until it's resolved what will actually be
implemented and how. And it's understandable that lots of people are
responding accordingly. But I think it's pretty clear that Sue was
trying to start a broader conversation in good faith. I know that
she's done lots of thinking about the conversations so far including
the de.wp poll, and she's also summarized some of this in her report
to the Board:

http://meta.wikimedia.org/wiki/Image_filter_referendum/Sue%27s_report_to_the_board/en#What_has_happened_since_the_referendum

The broader conversation she's seeking to kick off in her blog post
_can_, IMO, usefully inform the filter conversation.

What Sue is saying is that we sometimes fail to take the needs and
expectations of our readers fully into account. Whether you agree with
her specific examples or not, this is certainly generally true in a
community where decisions are generally made by whoever happens to
show up, and sometimes the people who show up are biased, stupid or
wrong. And even when the people who show up are thoughtful,
intelligent and wise, the existing systems, processes and expectations
may lead them to only be able to make imperfect decisions.

Let me be specific. Let's take the good old autofellatio article,
which was one of the first examples of an article with a highly
disputed explicit image on the English Wikipedia (cf.
http://en.wikipedia.org/wiki/Talk:Autofellatio/Archive_1 ).

If you visit http://en.wikipedia.org/wiki/Talk:Autofellatio , you'll
notice that there are two big banners: "Wikipedia is not censored" and
"If you find some images offensive you can configure your browser to
mask them", with further instructions.

Often, these kinds of banners come into being because people (readers
and active editors) find their way to the talk page and complain about
an image being offensive. They are intended to do two things: Explain
our philosophy, but also give people support in making more informed
choices.

This is, in other words, the result of reasonable discussion by
thoughtful, intelligent and wise people about how to deal with
offensive images (and in some cases, text).

And yet, it's a deeply imperfect solution. The autofellatio page has
been viewed 85,000 times in September. The associated discussion page
has been viewed 400 times.  The "options not to see an image" page,
which is linked from many many of these pages, has been viewed 750
times.

We can reasonably hypothesize without digging much further into the
data that there's a significant number of people who are offended by
images they see in Wikipedia but who don't know how to respond, and we
can reasonably hypothesize that the responses that Wikipedians have
conceived so far to help them have been overall insufficient in doing
so. It would be great to have much more data -- but again, I think
these are reasonable hypotheses.

The image filter in an incarnation similar to the one that's been
discussed to-date is one possible response, but it's not the only one.
Indeed, nothing in the Board resolution prescribes a complex system
based on categories that exists adjacent to normal mechanisms of
editorial control.

An alternative would be, for example, to give Wikipedians a piece of
wiki syntax that they can use to selectively make images hideable on
specific articles. Imagine visiting the article Autofellatio and
seeing small print at the top that says:

"This article contains explicit images that some readers may find
objectionable. [[Hide all images on this page]]."

As requested by the Board resolution, it could then be trivial to
selectively unhide specific images.

If desired, it could be made easy to browse articles with that setting
on-by-default, which would be similar to the way the Arabic Wikipedia
handles some types of controversial content ( cf.
http://ar.wikipedia.org/wiki/%D9%88%D8%B6%D8%B9_%D8%AC%D9%86%D8%B3%D9%8A
).

This could possibly be entirely implemented in JS and templates
without any complex additional software support, but it would probably
be nice to create a standardized tag for it and design the feature
itself for maximum usability.

Solutions of this type would have the advantage of giving
Wiki[mp]edians full editorial judgment and responsibility to use them
as they see fit, as opposed to being an im

Re: [Foundation-l] Blackout at Italian Wikipedia

[Erik Moeller]

On Wed, Oct 5, 2011 at 4:00 AM, Domas Mituzas  wrote:
> Except that WMF as steward of the open information can roll any of that 
> blackout crap back.

The only thing we truly could do is restore read access. But if the
it.wikipedia community really wants to strike, there's very little we
can do to stop them. :)

Wikis are great for organizing work. By necessary extension, they are
also great for organizing its discontinuation.


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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] [Wikimedia Announcements] Wikimedia Foundation Report, September 2011

[Erik Moeller]

Hello all,

please find below the WMF report for September, in plain text.

As always, the editable and formatted version is on Meta:

https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Report,_September_2011

The reports are posted on the Wikimedia blog, too:

http://blog.wikimedia.org/c/corporate/wmf-monthly-reports/

As an experiment, we are publishing a separate "Highlights" summary of key
Wikimedia Foundation reports.

Please consider helping non-English-language communities to stay updated
on the most important WMF activities in the past month, by providing a
translation:

https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Highlights,_September_2011

Let us know how we can make this more useful for you :-)

Many thanks,
Erik

--

 * 1 Data and Trends
 * 2 Financials
 * 3 Highlights
 o 3.1 Public Policy Initiative and Global Education Program
 o 3.2 Technology
 o 3.3 Community
 o 3.4 Global Development
 * 4 Technology
 o 4.1 Tech Highlights
 o 4.2 Operations
 o 4.3 Features Engineering
 o 4.4 Mobile
 o 4.5 Special projects
 o 4.6 Platform Engineering
 * 5 Research
 * 6 Community
 o 6.1 Projects
 o 6.2 Fundraising
 o 6.3 Public Policy Initiative
 o 6.4 Fellowship Program
 * 7 Global Development
 o 7.1 Grants Awarded and Executed
 o 7.2 Chapter Relations
 o 7.3 Global South
 o 7.4 Brazil Catalyst
 + 7.4.1 Research on Portuguese Wikipedia
 o 7.5 MENA Catalyst
 o 7.6 Mobile Strategy and Business Development
 o 7.7 Editor Survey
 o 7.8 Reader Survey
 o 7.9 Mobile Research
 o 7.10 Global Education Program
 o 7.11 Student organizations
 o 7.12 India Programs
 o 7.13 Communications
 + 7.13.1 Global Communications
 + 7.13.2 Storylines through August
 + 7.13.3 Other worthwhile reads
 + 7.13.4 Global media coverage
 + 7.13.5 Wikipedia Signpost
 + 7.13.6 WMF Blog posts
 o 7.14 Media Contact
 * 8 Human Resources
 o 8.1 Staff Changes
 o 8.2 Statistics
 o 8.3 Department Updates
 * 9 Finance and Administration
 * 10 Legal
 * 11 Visitors and Guests


== Data and Trends ==

   Global unique visitors for August:
   422 million (+7.9% compared with July; +13.7% compared with the
   previous year)
   (comScore data for all Wikimedia Foundation projects; comScore will
   release September data later in October)

   Page requests for September:
   15.8 billion (+5,1% compared with August; +9.0% compared with the
   previous year)

   Report Card for August 2011: The report card is currently undergoing
   a redesign as a more fully-featured dashboard.


== Financials ==

(Financial information is only available for August 2011 at the time of
this report.)

Financial information as of August 31, 2011

Revenue: $1,415,075

Expenses:

 * Technology Group: $1,474,075
 * Community/Fundraiser Group: $493,102
 * Global Development Group: $552,953
 * Governance Group: $183,732
 * Finance/Legal/HR/Admin. Group: $921,318

Total Expenses: $3,625,273

Total surplus/(loss): ($2,210,198)

Revenue was ahead of plan at $1.4M due to an increase in donations.

Expenses were below plan at $3.6M actual vs. $4.5M plan. Expenses were
below plan due to lower than plan expenditures in Capital Expenditures,
Chapter Grants and other activities due to being only two months into
the fiscal year.

Cash of $15.5M, which is six months of cash reserves at current spending
levels.


== Highlights ==

=== Public Policy Initiative and Global Education Program ===

https://commons.wikimedia.org/wiki/File:Wikipedia-Ambassador-Program-Logo.png
Logo of the Wikipedia Ambassador Program (which originated as part of
the Public Policy Initiative) >

In September, the Public Policy Initiative wrapped up after 17 months.
Collaboratively, the team created a final report for the Stanton
Foundation (awaiting financial summary) and documented achievements,
best practices and lessons learned. Other team activities included:
Overall project documentation for Chapters Report; last PPI Regional
Ambassador trainings throughout the United States; wrapping up the
project research components and presenting results on-wiki, in papers
and at the end of the month in a final presentation to the rest of the
staff at one of the Wikimedia Foundation's brown bag meetings.
Additionally, we transitioned specific project activities to the new
Global Education Team. With the end of the Public Policy Initiative, the
contracts of three team members, Sage Ross, Amy Roth and Mishelle
Gonzales, ended by convention. We thank them for their hard work and
their commitment to our mission. Sage's, Amy's and Mishelle's
involvement in the Public Policy Initiative was key in linking Wikipedia
peer production with higher education. We wish them all the very best
for their future.

Also in September, the new Global Education Program team worked on
preparing the first "Global Education Program Metrics and Activities
Meeting" (O

Re: [Foundation-l] News from Germany: White Bags and thinking about a fork

[Erik Moeller]

On Sat, Oct 22, 2011 at 10:07 AM, Dirk Franke
 wrote:
> And people who talked privately about a fork for some time, start to think
> and say it loud.

Thanks for the update, Dirk. I think it's good that people are
seriously discussing what it would mean to fork and how it would be
done. Forking the project if WMF policies or decisions are considered
unacceptable is one of the fundamental ways in which Wikimedia
projects are different from most of the web; it's a key freedom, one
which should be exercised judiciously but which should be preserved
and protected nonetheless.

With that said, I also think it's important to remember that Sue has
explicitly affirmed that the development of any technical solution
would be done in partnership with the community, including people
who've expressed strong opposition to what's been discussed to date.
[1]

The vote in German Wikipedia, and most of the discussions to date,
have focused on the specific ideas and mock-ups that were presented as
part of the referendum. But as Sue has made clear, those ideas and
mock-ups are just that, and the Board resolution creates room for
different ideas as well, ranging from the simple (disabling/blurring
all images) to the complex (like a category-based filtering system).

Some of these ideas are explored here:
http://meta.wikimedia.org/wiki/Image_filter_referendum/Next_steps/en#Potential_models_for_hiding_images

Is there a similar brainstorming page on dewiki already? If not, would
you be interested in organizing some community discussion on whether
there are solutions within the scope of the resolution that the dewiki
community would find acceptable, or whether the prevailing view is
that the resolution itself should be scrapped altogether?

Thanks,
Erik

[1]http://lists.wikimedia.org/pipermail/foundation-l/2011-October/069472.html

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] News from Germany: White Bags and thinking about a fork

[Erik Moeller]

On Sat, Oct 22, 2011 at 1:16 PM, David Gerard  wrote:
> This would appear to indicate the opposition is to *any* personal
> image filter per the Board resolution, and the category-based proposal
> additionally as an example of such rather than as the main topic of
> the vote. I think that says "should be scrapped" pretty blindingly
> clearly.

The literal translation of what was being voted on:

"Persönliche Bildfilter (Filter, die illustrierende Dateien anhand von
Kategorien der Wikipedia verbergen und vom Leser an- und abgeschaltet
werden können, vgl. den vorläufigen [[Entwurf]] der Wikimedia
Foundation) sollen entgegen dem Beschluss des Kuratoriums der
Wikimedia Foundation in der deutschsprachigen Wikipedia nicht
eingeführt werden und es sollen auch keine Filterkategorien für auf
dieser Wikipedia lokal gespeicherte Dateien angelegt werden."

"Personal image filters (filters, which hide illustrating files based
on categories and which can be turned on and off by the reader, see
the preliminary [[draft]] by the Wikimedia Foundation) should,
contrary to the Board's decision, not be introduced in the German
Wikipedia, and no filter categories should be created for locally
uploaded content."

The [[draft]] link pointed to
http://www.mediawiki.org/wiki/Personal_image_filter

So it was pretty closely tied to the mock-ups, just like the "referendum" was.

Erik

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] News from Germany: White Bags and thinking about a fork

[Erik Moeller]

On Sat, Oct 22, 2011 at 1:13 PM, Jussi-Ville Heiskanen
 wrote:
> There has always been a consensus that what you are
> proposing is evil and against what we as a non-profit free content
> site stand for.

What am I proposing, Jussi-Ville? So far, the only material proposal
I've made as part of this debate is here:

http://lists.wikimedia.org/pipermail/foundation-l/2011-September/069077.html

And, I don't think you're being accurate, historically or otherwise.
Arabic and Hebrew Wikipedia have implemented their own "personal image
hiding feature" (http://ur1.ca/5g81t and http://ur1.ca/5g81w), and
even paintings like "The Origin of the World" are hidden by default
(!) e.g. in Hebrew Wikipedia ( http://ur1.ca/5g81c ) , or images of
the founder of the Bahai faith in Arabic Wikipedia (
http://ur1.ca/5g81s ).

Do you think that the Hebrew and Arabic Wikipedians who implemented
these templates are evil?

Do you think that it is evil to leave it up to editors whether they
want to implement similar collapsing on a per-article basis (and to
leave it up to communities to agree on policies around that)? Because
that's what I'm proposing. And I don't think it's particularly evil,
nor inconsistent with our traditions.

Erik

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] News from Germany: White Bags and thinking about a fork

[Erik Moeller]

On Sat, Oct 22, 2011 at 1:50 PM, Tobias Oelgarte
 wrote:
> No one said it would be evil. But since we already have working
> solutions for this projects, why do we need another, now global,
> solution, based on categories? Thats when it becomes hairy.

The Board of Trustees didn't pass a resolution asking for the
implementation of a filter based on categories.

The Board asked Sue "in consultation with the community, to develop
and implement a personal image hiding feature that will enable readers
to easily hide images hosted on the projects that they do not wish to
view, either when first viewing the image or ahead of time through
preference settings."

Based on the consultation and discussion that's taken place so far, I
think it's pretty safe to say that a uniform approach based on
categories has about a snowball's chance in hell of actually being
widely adopted, used and embraced by the community, if not triggering
strong opposition and antagonism that's completely against our goals
and our mission.

With that in mind, I would humbly propose that we kill with fire at
this point the idea of a category-based image filtering system.

There are, however, approaches to empowering both editors and readers
that do not necessarily suffer from the same problems.

Erik

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] News from Germany: White Bags and thinking about a fork

[Erik Moeller]

On Sat, Oct 22, 2011 at 2:51 PM, Tobias Oelgarte
 wrote:
> What approaches do you have in mind, that would empower the editors and
> the readers, aside from an hide/show all solution?

1) Add a "collapsible" [*] parameter to the File: syntax, e.g.
[[File:Lemonparty.jpg|collapsible]].
2) When present, add a notice [*] to the top of the page enabling the
reader to collapse collapsible images (and to make that the default
setting for all pages if desired).
3) When absent, do nothing.

[*] The exact UI language here could be discussed at great length, but
is irrelevant to the basic operating principles.

Advantages:
* Communities without consensus to use collapsible media don't have to
until/unless such a consensus emerges. It can be governed by normal
community policy.
* One community's judgments do not affect another community's.
Standards can evolve and change over time and in the cultural context.
* Readers of projects like Hebrew and Arabic Wikipedia (which are
already collapsing images) who are currently not empowered to choose
between "collapsed by default" vs. "expanded by default" would be
enabled to do so.
* Readers only encounter the notice on pages that actually have
content where it's likely to be of any use.
* Respects the editorial judgment of the community, as opposed to
introducing a parallel track of "controversial content assessment".
Doesn't pretend that a technical solution alone can solve social and
editorial challenges.
* Easy to implement, easy to iterate on, easy to disable if there are issues.

Disadvantages:
* Doesn't help with the specific issues of Wikimedia Commons (what's
educational scope) and with issues like sorting images of masturbation
with electric toothbrushes into the toothbrush category. Those are
arguably separate issues that should be discussed separately.
* Without further information about what our readers want and don't
want, we're reinforcing pre-existing biases (whichever they may be) of
each editorial community, so we should also consider ways to
continually better understand our audience.

Erik

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] News from Germany: White Bags and thinking about a fork

[Erik Moeller]

On Sat, Oct 22, 2011 at 2:56 PM, David Gerard  wrote:
> On 22 October 2011 22:51, Tobias Oelgarte
> And, in detail, why is a hide/show all solution inadequate? What is
> the use case this does not serve?

Clearly Hebrew and Arabic Wikipedia found a "show/hide all" solution
inadequate. Are folks from those communities on the list? It would be
interesting to hear from them as to why they ended up with the
collapsing approach they took.

To the extent that there's a discernible institutional view as to why
these options are being discussed in the first place, it's not about
morality of the images, but it's about helping our audience to not be
freaked out, alienated or pissed off by the editorial choices we make
in our projects. And they might be so because they're in a public or
professional setting, or because they're using our projects together
with their kids, or they don't know what to expect when looking up a
given topic, or because they have particular sensibilities.

A show/hide all images function is likely too drastic to serve some of
these use cases well. So for example, if you're at work, you might not
want to have autofellatio on your screen by accident, but you'd be
annoyed at having to un-hide a fabulous screenshot of a wonderful
piece of open source software in order to mitigate that risk.

True, most of the time it's fairly self-evident what images an article
might contain and you could make the choice to show/hide before
looking it up. Not always, though, and of course it's somewhat
illusionary to think that Wiki[mp]edia consumption always follows a
highly predictable, intentional pattern.

Making it easy for editors to say, based on normal editorial judgment
and established practices in their project, "Hey, reader, there's
something here you might not want to see  ... and BTW, would you like
to remember that choice?" seems like a more straightforward
accommodation of the concerns that we're talking about than saying
"We're not censored! Click here to turn off images if you don't like
it".

With that said, the mobile site already has a generic "Disable images"
view and something similar would definitely make sense on the main
site as well. If both options were available (marking images as
collapsible in a standard way, & show/hide all for all media),
communities could evolve standards and practices within that framework
as they see fit.

Erik

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] News from Germany: White Bags and thinking about a fork

[Erik Moeller]

On Sat, Oct 22, 2011 at 4:14 PM, Tobias Oelgarte
 wrote:
> Isn't that the same as putting some images inside the category
> "inappropriate content"? Will it not leave the impression to the reader
> that "we" think that this is something not anybody should see? Can it be
> easily used by providers to filter out this images?

http://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Template:Censor&namespace=1&limit=500
http://en.wikipedia.org/wiki/MediaWiki:Bad_image_list
http://commons.wikimedia.org/wiki/Category:Nude_men

Simply in the process of doing our normal editorial work, we're
already providing a number of ways to identify content in the broad
area of "someone might be upset of this" or even in specific
categories, and of course censorship also often relies on deriving
characteristics from the content itself without any need for
additional metadata (keyword filters, ranging from simple to
sophisticated; image pattern matching, etc.).

It's not clear that a low-granularity identification of content that
some editors, in some projects, have identified as potentially
objectionable to some readers, for a wide variety of different
reasons, adds meaningfully to the existing toolset of censors. A
censor who's going to nuke all that content from orbit would probably
be equally happy to just block everything that has the word "sex" in
it; in other words, they are a reckless censor, and they will apply a
reckless degree of censorship irrespective of our own actions.

Erik

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Office Hours on the article feedback tool

[Erik Moeller]

On Wed, Oct 26, 2011 at 3:11 AM, Oliver Keyes  wrote:
> To be clear, we're not talking about junking the idea; we will still have an
> "Article Feedback Tool" that lets readers provide feedback to editors. The
> goal is more to move away from a subjective rating system, and towards
> something the editors can look at and go "huh, that's a reasonable
> suggestion as to how to fix the article, I'll go do that" or "aw, that's
> really nice! I'm glad they liked it so much"

And, the idea is to experiment with some alternative approaches in
parallel with the existing deployment, not to scrap the existing
deployment and start over immediately. We don't know yet which reader
feedback mechanisms are going to be the most useful to meet the two
core objectives (engaging readers as much and as usefully as possible
in article development, and measuring change-over-time in quality).
Initial wireframes to be tested against each other can be found here:

http://www.mediawiki.org/wiki/Article_feedback/Version_5/Feature_Requirements
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] On certain shallow, American-centered, foolish software initiatives backed by WMF

[Erik Moeller]

On Fri, Oct 28, 2011 at 3:00 PM, Teofilo  wrote:
> Now we are seeing the appearance of a feedback tool on the English
> Wikipedia ? How long are the non-English Wikipedias going to be free
> from this new stupid tool which has nothing to do with writing an
> encyclopaedia ?

In addition to English Wikipedia, WikiLove has been enabled on Arabic
Wikipedia, Hebrew Wikipedia, Hindi Wikipedia, Hungarian Wikipedia,
Macedonian Wikipedia, Malayalam Wikipedia, Norwegian Wikipedia,
Portuguese Wikipedia, Swedish Wikipedia, Oriya Wikipedia, Chinese
Wikipedia, MediaWiki.org and Commons.

So, WikiLove is spreading. Maybe one day it will even come to German
Wikipedia. I'm guessing 2020. ;-)

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Show community consensus for Wikilove

[Erik Moeller]

On Mon, Oct 31, 2011 at 12:14 AM, MZMcBride  wrote:
> A user preference or some other way of disabling the use of WikiLove on a
> per-user basis might be nice.

Absolutely, disabling it on the recipient side (so that a sending user
gets a disabled icon saying "This user prefers more personal notes to
WikiLove messages" or something similar) is in the backlog. I've held
that the existing preference to disable should go both ways.
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Community consensus for software changes (Re: Show community consensus for Wikilove)

[Erik Moeller]

On Mon, Oct 31, 2011 at 6:54 AM, Nathan  wrote:
> I see Brandon replied to this thread several times; did anyone notice
> if the question in the OP (if community consensus is required for
> implementation, where was it demonstrated for en.wp) was answered?

As a matter of general practice, the Wikimedia Foundation aims to be
responsive to the community both before and after the deployment of
software, but it doesn't obtain community consensus before deploying
software which it would like to deploy on its sites and services, nor
does it necessarily write or deploy software changes if a consensus to
do so exists. That has always been the case; indeed, there was no
explicit consensus ahead of time for the vast majority of major
software changes in Wikimedia's history.

Being responsive and applying appropriate effort towards a problem
shouldn't be confused with a constitutional commitment to act only
with, or never against, a consensus in a community. We've never made
such a commitment as a general principle. Some features, like
WikiLove, require community customization to be useful in the first
place; others, like FlaggedRevs, influence a community's practices so
deeply that they require both the community's expertise and buy-in to
succeed.  And of course there are lots of small tweaks and
customizations that communities can request from us, but we can only
respond to them if  they can demonstrate that there's a consensus to
proceed.

However, if we found evidence that, say, WikiLove turns out to be the
best thing since sliced bread (which of course it isn't, duh -- it's
just a small bit of culture shift), then we might put lots of effort
towards working with the community to localize it and deploy it
globally. As it is, that particular feature is still experimental, and
will likely continue to change shape and application, as we better
understand the dynamics of how it is used.

The partnership between WMF and the community is founded on mutual
trust. If you don't trust WMF, you can - and probably should -
contribute your effort elsewhere, because WMF may - and probably will
- do things you won't like.

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Community consensus for software changes (Re: Show community consensus for Wikilove)

[Erik Moeller]

On Mon, Oct 31, 2011 at 11:22 AM, Michael Snow  wrote:
> If I understand correctly, the English Wikipedia is the main test
> deployment for this as an experimental feature. While the feature
> remains experimental, additional deployments to other wikis would only
> happen if requested by community consensus.

That's right. Because we're not actively organizing or vetting any
efforts to localize the feature beyond its initial test deployment, we
can't deploy to other languages unless there's a clear, proposed
configuration and a consensus to use it. Given the still experimental
nature of the feature, and the relatively high cost to manage a
community-wide change, that's purely a pragmatic choice. We've made
the same choice for ArticleFeedback and other experimental features,
and will likely do so with others.
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Community consensus for software changes (Re: Show community consensus for Wikilove)

[Erik Moeller]

On Mon, Oct 31, 2011 at 11:08 AM, Nathan  wrote:
> That's a pretty bold statement for the WMF to make - "If you don't
> trust the WMF, don't contribute to WMF projects." Are you sure that's
> what you meant?

Hi Nathan,

let me try to clarify what I mean by trust in this context. We can,
indeed must, talk very openly about what works and what doesn't, and
whether we're doing the right kinds of things. That discourse, and the
readiness to engage in it and to change course for the right reasons,
is key for a relationship based on mutual trust to work.

It's easy for us to accidentally send mixed messages, though, as this
thread has shown. Because so many things are done in response to
community consensus, there may be an expectation that this is always
the case, and that that's just how we work. Change in Wikimedia
projects has, however, always been a continuous process of give and
take, with a certain element of arbitrariness, seeking to find the
right balance between acceptance and progress, and "being bold" to try
new things. That process can be very messy, as the image filter
discussion has shown.

So, what I'm saying is that if you (generic "you") believe, for
whichever reason (lack of trust, philosophical reasons, or whatever),
that WMF shouldn't be permitted to make meaningful changes in
Wikimedia projects without obtaining upfront community consensus,
you'll probably find more satisfaction and joy in volunteering in a
different context. That's not how WMF projects operate, and they are
very unlikely to ever do so, for reasons that have been articulated
here and elsewhere. Indeed, it's part of WMF's understanding of itself
that part of its job is to continually challenge existing agreements
and practices in order to support positive change.

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Ideas for newbie recruitment

[Erik Moeller]

On Mon, Oct 31, 2011 at 7:14 PM, Jussi-Ville Heiskanen
 wrote:
> Would it be overwhelmingly hard to program a pop-up dialogue which
> would first ask which type of source the editor is citing from, which
> would lead to a form with labeled textboxes for the
> various elements of a reference citation with an asterisk beside the
> elements considered vital. My guess is that quite a few of the
> elements of such are already in the code.

A lot of this already exists in the cite toolbar on the English Wikipedia:
http://en.wikipedia.org/wiki/File:Cite_toolbar_2.png
http://en.wikipedia.org/wiki/File:Citing_sources_tutorial,_part_2.ogv

It's very en.wp specific (because the templates are), and the
usability is still a bit poor. It's one of those low-hanging fruit
things where a little bit of effort could go a long way.

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Fwd: Wikimedia India Program Trust

[Erik Moeller]

On Thu, Nov 10, 2011 at 9:11 PM, Hisham  wrote:
> Announcement of Wikimedia India Program Trust

Congratulations, Hisham. I know this has been a lot of work for you
and the team over the last few months. I look forward to seeing the
programs that the trust and the chapter develop together.

There's tons of work to do. :-)

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Fwd: Wikimedia India Program Trust

[Erik Moeller]

On Fri, Nov 11, 2011 at 9:34 AM, Bishakha Datta  wrote:
> My personal view is that there is enough work ahead for not just one, or
> two, but numerous entities, formal and informal, to enter the fray and
> actualize this potential. Already, there are many more requests for
> collaboration within India than either WMIN or WIPT or both put together
> can handle.

No kidding. Nor do I think there's any point in playing blame games
when a first pilot (!) like the India Education Program doesn't meet
expectations. The point of trying things is to learn so we can improve
over time.

I look forward to seeing some of you based in India at the Hackathon
and WikiConference next week:

https://www.mediawiki.org/wiki/India_Hackathon_2011
https://meta.wikimedia.org/wiki/WikiConference_India_2011

Cheers,
Erik

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Fwd: Wikimedia India Program Trust

[Erik Moeller]

On Fri, Nov 11, 2011 at 11:04 PM, rupert THURNER
 wrote:
> to get a feeling about the size, the number of readers, contributors, and a
> trend in it, i tried to find the india country statistics on editing and
> reading:

The major program initiative undertaken by Hisham's team so far is the
India Education Program. See:
http://en.wikipedia.org/wiki/Wikipedia:India_Education_Program/Courses

So far there's been a pilot program, which uncovered lots of serious
issues with the quality of content contributed by the participating
courses. This is now driving further iteration of the program, as it
should.

The pilot very much built on, and was informed by, the lessons learned
in the Public Policy Initiative, which was the largest and most
successful student engagement program ever undertaken in the Wikimedia
movement (!). Both the India Education Program and the PPI have been
led by Frank Schulenburg, who is an experienced and accomplished
Wikipedian.

> at the same time, another part of the world, a foto competition, no trust,
> no consultants, no KPMG involved, but a lot of volunteers and chapters. it
> gave 160'000 images for wikimedia commons, in one month. and, 30% new
> contributors. [2]

WLM is a wonderful project, one which WMF actively supported (most
importantly by improving Upload Wizard to directly support the
management of the upload campaigns). It really is credit to all the
people who developed it, and built on the lessons from last year's WLM
in the Netherlands.

It's also a photo competition, which by its very nature is a very
different kind of program than something like the IEP, with very
different risks and opportunities. It's easy to compare apples and
oranges and say "those apples are rotten, my oranges are so much
nicer". But they are very different fruit entirely. :)

I don't think anyone is served by stereotyping people or programs.
We're all pulling towards the same goal. That doesn't mean constantly
patting ourselves on the back, but let's focus on the the substance of
the work rather than on peddling stereotypes about ignorant
consultants and "outsiders".

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Image filter brainstorming: Personal filter lists

[Erik Moeller]

On Mon, Nov 28, 2011 at 10:21 AM, David Gerard  wrote:
> Unfortunately, the issue is not dead.

That's correct; nobody from WMF has said otherwise. What's dead is the
idea of a category-based image filter, not the idea of giving
additional options to readers to reversibly collapse images they may
find offensive, shocking, or inappropriate in the context in which
they're viewing them (e.g. at work). However, Sue has made it clear
that she wants the WMF staff to work with the community to find a
solution that doesn't mean strong opposition. Her presentation on the
issue in Hannover begins with this slide:

http://commons.wikimedia.org/w/index.php?title=File%3APresentation_Gardner_Hannover.pdf&page=15

My personal view is that such a solution will need to take into
account that actual current editorial practices and perceptions in our
projects vary a great deal, as did the image filter poll results by
language. As I pointed out before, projects like Arabic and Hebrew
Wikipedia are currently collapsing content that's not even on the
radar in most of these discussions (e.g. the 1866 painting L'Origine
du monde in Hebrew Wikipedia), while German Wikipedia put the vulva
photograph on its main page. A solution that pretends that this
continuum of practice can be covered with a single approach, one which
doesn't give a lot of flexibility to readers and editors, is IMO not a
solution at all.

I'm not convinced that the "collapse image one-by-one" approach to
develop a filter list is very valuable in and of itself due to lack of
immediate practical impact and likely limited usability. The idea of
making it easy to build, import and share such lists of images or
image-categories would move the process of categorization into a
market economy of sorts where individual or organizational demand
regulates supply of available filters. This could lead to all kinds of
groups advertising their own filter-lists, e.g. Scientology, Focus on
the Family, etc. From there, it would be relatively small step for
such a group to take its filter list and coerce users to only access
Wikipedia with the filter irreversibly in place.

While third parties are already able to coerce their users to not see
certain content, creating an official framework for doing so IMO puts
us dangerously close to censors: it may lead to creation of regimes of
censorship that did not previously exist, and may be used to exercise
pressure on WMF to change its default view settings in certain
geographies since all the required functionality would already be
readily available.

My personal view on this issue has always been that one of the most
useful things we could do for readers is to make NPOV, well-vetted and
thorough advice too users on how to manage and personalize their net
access available to them. Wikipedia is only one site on the web, and
whatever we do is not going to extend to the rest of the user's
experience anyway. There are companies that specialize in filtering
the Net; we could point people to those providers and give advice on
how to install specific applications, summarizing criticism and praise
they have received.

On the other hand, such advice would be pretty removed from the
experience of the reader, and l do think there are additional
reasonable things we could do. So I'm supportive of approaches which
give an editing community additional flexibility in warning their
readers of content they may find objectionable, and give readers the
ability to hide (in the general or specific case) such content. As I
said previously, this wouldn't create a new regime of filter lists or
categories, merely a broad community-defined standard by which
exclusion of some content may be desirable, which could vary by
language as it does today.

Kim, I just read the conversation on your talk page. In general, I
agree that more research into both the current practices of our
editing communities as well as reader expectations and needs would be
valuable. Right now we have some anecdotal data points from the
projects, Robert's original research which mostly focuses on
establishing definitions and principles, and the image filter poll
results. I think the latter are useful data if carefully analyzed, but
they do mingle low-activity users who are chiefly readers with the
core editing community in ways that don't give us tremendously clear
information by group. The poll also referred to a filtering concept
that's now been rejected.

At the same time, I do think that we shouldn't hesitate to build some
cheap prototypes to make abstract ideas more understandable. I think
to advance our understanding, as well as the state of the
conversation, through both additional pointed research, as well as
discussion of some interactive prototypes, without spending tremendous
amounts of time and money on either, feels like a response that's
commensurate to the scale and importance of the issue.

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

Re: [Foundation-l] Fundraising is for men

[Erik Moeller]

On Tue, Nov 29, 2011 at 3:42 PM, Nathan  wrote:

Hey Nathan,

a bit OT from the thread title, but just clarifying a couple of points:

> * The WMF spends over $2 million on fundraising alone

In FY 2010-11, WMF raised $23M in contributions, not counting $
restricted to future time periods. In the same time period, $2.142M
expenses were allocated to fundraising, including $556K in credit card
processing fees. [1][2] That's altogether less than 10 cents on the
dollar, which by the standards of charity watchdog organizations, is
qualified as an excellent fundraising efficiency (cf. [3][4]). This
includes very different types of fundraising activity (grant-writing
and grant management, donor cultivation, usability testing of credit
card forms, etc.).

> * The travel budget is nearly $2m (that's right, two million dollars
> in travel costs)

The 2011-12 travel budget is $1.742M [5]. A little bit of detail as to
how this breaks out is included in the Audited Financials FAQ [1], but
in a nutshell:

* WMF is a global organization and is doing work on the ground in many
corners of the world, in partnership with chapters where they exist,
and WMF staff routinely have to travel internationally as a normal
part of their day-to-day work;
* WMF sponsors volunteer travel extensively, for Wikimania, for
hackathons, for WMF site visits and meetings, and for many other
purposes;
* Many contractors work for WMF from all over the world, and it's part
of the cost of doing business in this way that you bring people
together for face-to-face meetings on a regular basis.

Travel is regulated by the WMF travel policy which ensures that
individual travel expenses are not excessive or profligate. [6]

> * The budget includes a whopping $14 million on staffing costs (at the
> planned 117 number of staff, that is nearly $120k per staff member)

The 2010-11 staffing budget is $13.3M. [5] Staffing costs include
payroll taxes, recruiting costs, and benefits, and of course pay bands
for different roles vary significantly, but are consistent with
similar non-profit organizations, i.e. below the market rate paid at
for-profit companies.

More background about the guiding principles of Wikimedia's
compensation practices can be found in [7].

> * The last fundraiser sent over $6 million to chapters, with little
> insight or transparency into how that money is spent

Chapters processing donations in the 2010 fundraiser were required, as
part of their participation, to commit to various obligations. See [8]
for the Wikimedia UK agreement as an example. Specifically with regard
to transparency, WMF, community, and chapters have worked together to
ensure that key information about chapter activities and financial
information can be easily found. [9]

At its July 2011 Board meeting, the WMF Board of Trustees agreed to a
letter regarding fundraising accountability [10] which further
emphasized principles of accountability, transparency, and fairness,
and led to shifting chapters increasingly towards applying for grants
to fund program work. Program plans both for chapters receiving grants
and processing payments through the fundraiser are shared and reviewed
publicly. [11]

> * The number of staff is planned to more than double between 2009-10
> and 2011-12, with almost 70% of that increase attributed to non-tech
> staff

The planned staffing increase from FY 2009 to FY 2012 is from 50 to
117 (+67). [12] In the same time period, tech staffing specifically is
projected to grow from 22 to 50 (+28). That's 41.8% of the increase,
not 30%. The tech share is higher in the current fiscal year, where it
accounts for 56% of the planned staffing growth.

Simply put, the Global Development and Community Department did not
exist and were newly created; WMF has decided to tackle new areas of
work that never happened before, as exemplified e.g. by the Summer of
Research, the Global Education Program, etc.

> And, let's be honest - aside from the $3m or so spent on hosting,

The costs that you find labeled "Internet hosting" in the Annual Plan
should never be confused with the cost of hosting Wikipedia. Those are
two very different numbers (and we should make this clearer in the
next plan). The "hosting cost" only covers bandwidth and operating
expenses for running our sever farms.

There's a separate cost center called "capital expenditures" which
covers actual hardware purchases ($2.6M budgeted in 2011-12). To
arrive at a meaningful "cost of hosting Wikipedia" (without any
software improvements) one would have to back out of that experimental
projects like Wikimedia Labs, but further add essential engineering
staffing and contractors.

> But the 11-12 plan called for the Visual Editor and
> Wikimedia Labs to go into initial production mode in December 2011 -
> which is in two days, without any recent announcements or updates
> about either improvement. (Labs closed beta has 13 users in its active
> list, defined as more than 1 edit in the last 30 days. Only 2 h

Re: [Foundation-l] The Mediawiki 1.18 image rotation bug on Commons and on all Wikimedia projects

[Erik Moeller]

On Mon, Dec 12, 2011 at 7:55 AM, David Gerard  wrote:
> * How many existing uploads, used on the wikis, were previously
> wrongly rotated and were fixed by the feature?
> * How many existing uploads, used on the wikis, were previously
> correctly rotated and were messed up by the feature?

As far as I understand the issue, and others can jump and correct me
if I'm getting it wrong:

Technically, nothing was "messed up" by the feature. Rather, the
software previously did not take EXIF rotation into account, and some
images had incorrect EXIF rotation information to begin with. Those
images are now shown in an incorrect rotation to the user, because the
incorrect EXIF rotation info is being evaluated.

It's important to understand this, because it means that those images
have been causing problems for re-users all along. If you open those
images with modern image editing/viewing software, they will either be
automatically rotated, or you'll be prompted by the software whether
to apply the rotation noted in the EXIF tag.

The situation has been significantly exacerbated by a recent need to
purge old thumbnails to free up diskspace.

So, while the cleanup that's happening now is very frustrating (and I
definitely agree we could have anticipated and communicated this
better), it's a cleanup that's long overdue. (Either by stripping EXIF
info from files altogether, or by ensuring that the rotation of the
image matches the one in the metadata.)

Is there more that we can do at the present time to help?

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] The Mediawiki 1.18 image rotation bug on Commons and on all Wikimedia projects

[Erik Moeller]

On Mon, Dec 12, 2011 at 12:12 PM, David Gerard  wrote:

> What was messed up was the
> presentation of images that were already displayed correctly.

Well, technically, they were displayed incorrectly. ;-) The image told
the software "Please rotate me", and the software didn't. But the
image would tell any other software the same thing, causing pain for
re-users. So it was definitely an issue that needed to get resolved,
one way or another. I don't know off-hand how many images are affected
(the estimate on Commons is about 50,000, but I don't know what that's
based on).

The thing is, we've always gotten "drive-by" uploads by users who
didn't bother to fix any rotation issues with their images after
upload, and so we can't just go back and strip EXIF info from all old
files, because some old files were fixed by the change. It looks to me
like the only sensible response is human review followed by rotation
of images that need to be fixed -- which is precisely what's
happening, with a bot performing rotations as needed.

I've asked Rob Lanphier to look at this as well and determine if an
additional response is needed; if you think there's more we can/should
do to help, please let him know.

The best place for further discussion of this issue is:
http://commons.wikimedia.org/wiki/Commons_talk:Rotation
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] The Mediawiki 1.18 image rotation bug on Commons and on all Wikimedia projects

[Erik Moeller]

On Mon, Dec 12, 2011 at 7:48 PM, Erik Moeller  wrote:
> The best place for further discussion of this issue is:
> http://commons.wikimedia.org/wiki/Commons_talk:Rotation

And, lots more discussions here as well:
http://commons.wikimedia.org/wiki/Commons:Bots/Work_requests#Maintenance_category_for_files_with_EXIF_rotation_other_than_0_degrees

If I interpret that discussion correctly, the number of globally used
files that were affected is estimated to be about 20,000, with an
additional 35,000 files that weren't globally used, based on analysis
of the image metadata dumps.

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] The Mediawiki 1.18 image rotation bug on Commons and on all Wikimedia projects

[Erik Moeller]

On Mon, Dec 12, 2011 at 9:52 PM, David Richfield
 wrote:
> What effect would a less aggressive tone have had?  Would you have
> been more likely to convince your audience?  less likely to alienate
> people?

It's a fair point. I think part of the problem is that people are
feeling that reasonable, calm, friendly inquiries are likely to be
ignored and "making noise" is necessary to get attention. I want to
make sure we do our best to respond to reasonable inquiries in a
timely manner, and would ask all WMF staff and contractors to help me
in that regard.

In general, if you feel that an engineering issue merits escalation,
never hesitate to email me directly and, unless I'm totally swamped,
I'll try to help. There are other folks whose job it is to help with
triaging, like Mark Hershberger (mah at wikimedia dot org) and Sumana
Harihareswara (sumanah at wikimedia dot org, especially for things
like patch review), and of course you can also contact any of the
engineering directors for tech issues, raise them on IRC, on Bugzilla,
etc.

It's true that sometimes people complaining loudly helps us to take an
issue more seriously, but ideally that shouldn't be necessary and our
processes should work to understand what's causing pain and what
isn't.
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Article Feedback Tool 5 testing deployment

[Erik Moeller]

On Wed, Dec 21, 2011 at 3:57 AM, Liam Wyatt  wrote:
> One thing I'd like to ask (which may be in the on-wiki documentation, sorry 
> if you've
> already answered there) is what is going to happen to the other articles that 
> are not
> part of this new test group?

Hi Liam,

this is the first time we're experimenting with free text feedback in
a serious way. We've not decided yet whether that's a good idea or
not. This will depend in large part on the signal/noise ratio and
volume of the feedback we're getting, which will be coded through the
process described here:

http://en.wikipedia.org/wiki/Wikipedia:Article_Feedback_Tool/Version_5/Feedback_evaluation

Note, also, that some of the forms include different forms of
quantitative feedback as well. We'll evaluate those as well, and
compare our findings with what we've learned, and are still learning,
from AFTv4. This evaluation will precede any site-wide changes to the
current AFT deployment.

All best,
Erik

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Blink tag jokes are now obsolete.

[Erik Moeller]

On Sat, Dec 31, 2011 at 12:59 AM, geni  wrote:
> We appear to have actual blinking ads. Unfortunate. Still I suppose
> the occasion should be marked.

You're a year late to mark it. The year-end fader banner was first
used in 2010, e.g.:
http://meta.wikimedia.org/w/index.php?title=Special:NoticeTemplate/view&template=20101229_JAFS003fader_US

A fundraising campaign is not a switch-on/switch-off affair. It has an
arc. It's that arc that helps it be successful. This is the last day
of the campaign, and a final invitation to give to reach our goal. It
should communicate a sense of urgency towards closure and resolution,
coinciding with people's increased year-end willingness to give (which
isn't just about taxes). Utilizing a tasteful but slightly
unconventional banner that one time is entirely appropriate to wrap
things up.

Last year's December 31 was, up until this year, our most successful
fundraising day ever. This year's first day of the campaign seems
likely to stay our most successful fundraising day of all time,
followed by this year's December 31. Those are great successes worth
celebrating.

But what's especially worth noting is that the fundraising team has
worked enormously hard this year to build a fundraising story that's
_not_ simply about maximizing revenue. This deserves celebration, too,
but I'll send a separate note about that.

Happy new year all -

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Celebrating the 2011 campaign

[Erik Moeller]

Hello all,

I just want to send a note to celebrate the enormous success of the
2011 fundraiser. It used to be the case that I was pretty involved in
the annual campaign. For the last two fundraiser, Zack Exley's been
running the show, and I'm enormously impressed by and proud of what he
and his team have been able to accomplish.

When we prepared the budget for 2011-12, I worried that we'd need to
cross new lines in order to generate that much revenue. The 2010
campaign already felt like we were hitting the ceiling of how much can
be raised from a large number of individual donations. Last year, we
were showing Jimmy's face and appeals in many different variations
through much of the fundraiser. We had tried some pretty aggressive
banners, like these ones:

http://meta.wikimedia.org/w/index.php?title=Special:NoticeTemplate/view&template=2010_JA1_Banner3_rtl
http://meta.wikimedia.org/w/index.php?title=Special:NoticeTemplate/view&template=2010_JA1_Banner4_US
http://meta.wikimedia.org/w/index.php?title=Special:NoticeTemplate/view&template=2010_JA1_Banner7
http://meta.wikimedia.org/w/index.php?title=Special:NoticeTemplate/view&template=2010_JA1_Banner6

Jimmy certainly didn't crave this level of attention, but he was a
good sport and gave his approval. The campaign was tremendously
successful. But after it was over, we weren't just worried that our
readers might be feeling "Jimmy fatigue", we were all feeling it,
including, I'm sure, Jimmy himself. But it simply remains true that
people strongly identify with him, and that his appeals tend to
motivate people to give more clearly than anything else.

So it was with some anxiety that we approached the 2011 campaign. Zack
isn't the kind of person who makes a grand master plan and then sticks
to it, so until it played out, I really didn't know what the 2011
campaign would look like. Instead of dreaming up plans, though, Zack
and team had spent the months leading up to the fundraiser A/B testing
and experimenting with ways to shorten the fundraiser and reduce our
reliance on a single message/message-bearer. And so they learned tons
of stuff: How long an appeal needed to be to work, what kind of
photo/lighting/background was effective, what payment process would
work, etc. And there was the usual usability testing, optimization of
donations forms, etc.

This, by the way, told us that we didn't need graphically obnoxious
banners -- the simple text on plain white with a photo worked just
fine. (But it needed to be the right kind of photo, and yes, moving it
to the left helped as well.)

And Zack hired storytellers, not an uncontroversial idea at the time,
whose job it would be to go out there and collect the most compelling
personal stories from people in our movement, wherever they may be and
whatever role they may play. This allowed us to share lots of those
stories, both through the testing and then through the actual
fundraiser itself.

There's more -- prior to the campaign, the tech team worked enormously
hard to integrate a new payment system, GlobalCollect. This would
allow us to accept payments not just in all major currencies, but also
through bank transfer, direct debit, and country-specific payment
methods:

https://wikimediafoundation.org/wiki/Ways_to_Give/en

This, too, in combination with more effectively organized efforts by
hundreds of volunteer translators, meant that banner impressions that
were previously wasted (because people had no way to actually donate)
were now going to turn into support for our work.

All the testing and infrastructure improvements meant that the first
day of the fundraiser was our most effective day ever, by far. And it
meant that we could raise our goal in less time than before. We've
also turned off the banners for registered users in record time, and
for the first time disabled banners for anyone making a donation. But
most importantly it allowed us to share appeals like these:

http://blog.wikimedia.org/2011/12/22/who-is-asking-you-to-donate-to-wikipedia-and-the-wikimedia-foundation/

These letters help people understand what Wikimedia is about through
many different voices, metaphors and experiences. The story of an
editor like Sengai Podhuvanar from India, or of a donor like Akshaya
Iyengar, or Ward Cunningham's own story. The storytellers worked hard
to capture the essence of these voices, so that they would be heard
loud and clear.

The team could have chosen to use that time to show more effective
Jimmy banners, or to pick one or two other banners and focus the
entire campaign on them. Instead it sacrificed short term revenue
impact for a more diverse and interesting campaign.

Years ago, we used to worry that people wouldn't/didn't understand
that Wikimedia is a non-profit, that it's created by volunteers, that
it's international/multilingual. Many misconceptions still exist, but
for anyone paying attention, we've demolished them.

I know that everyone involved is enormously proud of working their
butts off for Wi

Re: [Foundation-l] Blink tag jokes are now obsolete.

[Erik Moeller]

On Tue, Jan 3, 2012 at 5:34 AM, Domas Mituzas  wrote:
> This year pictures at top left, blinking banners, etc - are becoming a norm.

This is simply untrue hyperbole. The fader was used in the same way as
last year, at the same time. (In fact, I think last year they used the
word "urgent", which I don't believe was used this year.)

So what's your slippery slope argument? That we've had photographs on
the left side of the banner this time? While at the same time, 1)
we've shortened the fundraiser, 2) we've disabled banners for logged
in users more quickly, 3) we've (for the first time) disabled banners
for donors once they made a donation, 4) we've reduced reliance on
Jimmy dramatically.

Yeah, sure sounds like a slippery slope to dancing monkeys to me.

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

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] A fundraiser for editors

[Erik Moeller]

On Mon, Jan 2, 2012 at 8:53 AM, James Heilman  wrote:
> The fundraiser for money has been working exceedingly well with our
> number of donors increasing 10 fold since 2008. What we need now is a
> fundraiser for editors. I meet well educated professionals who use
> Wikipedia but have no ideas that they can edit it. We need to run a
> banner with the same energy we use to raise money to raise editor
> numbers. This idea has been trialed to a limited extent here
> http://en.wikipedia.org/wiki/Wikipedia:Invitation_to_edit but the
> effort did not have sufficient data crunching behind it to determine
> if it works.

James,

thanks for this note! The problem, as I see it, is that we know that
new editors, once they attempt to make their first edit, hit an
enormous number of barriers. Even if they master mark-up (which is a
big IF), they're likely to fail when their edits get reverted due to
lack of proper citations or other issues.

We built http://en.wikipedia.org/wiki/Special:FeedbackDashboard as a
way to surface what frustrations new editors have. Ignoring the noise
(people who shouldn't edit or who're trying to do harm), you'll get
the same issues again and again:
- basic editing is very hard
- communication via talk pages is very confusing
- copyright issues are complicated and unfamiliar
- article rejections or reverts feel arbitrary and unfair
- finding the right way to upload images is complicated

It's now possible to help those users with a built-in response tool,
and it's possible for new users to mark these responses as helpful or
not. Over time, this may surface easy ways in which the community can
ease the pain of new users. (FeedbackDashboard is on English and Dutch
Wikipedia and on Incubator. We're happy to install it on more wikis,
but it probably won't work well in smaller communities due to lack of
scale.)

There are certain types of new user recruitment which do _not_ hit as
many issues. One is the high-touch recruitment at universities via
assignment or other means. It requires a fair amount of effort per
student, but provided that the preconditions are right, those students
tend to turn out high-quality work. The biggest issues have been in
India where the quality of edits was much lower than hoped for. See:
http://outreach.wikimedia.org/wiki/Wikipedia_Education_Program
and related links -- again, there's lots of opportunity here to help
these students.

A second area is multimedia campaigns. While finding the right way to
upload is hard when you're a new user, if you point people directly at
a customized UploadWizard at Commons, the success rate is pretty high.
This has been demonstrated by community/chapter campaigns like "Wiki
Loves Monuments 2011" (~180,000 photos) and "TamilWiki Media Contest
(~5,500 photos so far), which have brought lots of new users into the
fold.

I'd love to hear other successes/failures. I'm skeptical about a
sitenotice/banner-focused approach until we've addressed some of the
_known_ issues that new users are likely to encounter. We could
shortcut things a little by focusing a lot on mentoring tools, but IMO
that would be more band-aid -- we need to address the fundamental
issues. Here are some of the things we're doing:

1) Steven and Maryana in the Community Department have been running
tests to see if different types of warning messages reduce people's
early frustration and increase their retention:
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_user_warnings/Testing

2) The Feedback Dashboard itself has response mechanisms, including
now a "Mark as Helpful" feature for new users to quickly acknowledge
whether a given response has been useful to them.

3) The Visual Editor, once completed, will hopefully reduce a huge
amount of the basic usability challenges people encounter. Projects
like UploadWizard help with that, as well.

4) Tools like AFTv5 potentially offer a casual entry-way into the
world of editing without the risk of reversion or other negative
experiences. Some users may only ever submit comments/suggestions, but
hopefully some of them will also "graduate" to editing given
sufficient encouragement.

5) Next we're going to experiment specifically with the mechanisms
used for patrolling and creating pages. See:
http://www.mediawiki.org/wiki/New_Page_Triage
http://www.mediawiki.org/wiki/Article_creation_workflow

This is a frequent pain point both for new and experienced editors and
we hope we can take some of that away by working closely with the
community in reforming processes and tools.

6) After that we'll have to think about challenges like messaging
(talk pages are horribly broken), identity (user profile setup), and
affiliation (joining and managing WikiProjects etc.).

Lots to do :)
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

___
foundation-l mailing list
foundation-l@lists.wikimedia.org