Re: [Foundation-l] Job openings - Bugmeister

[Rob Lanphier]

On Tue, Mar 15, 2011 at 10:34 AM, Jan Kucera (Kozuch)
 wrote:
> what about this job opening? Has it been filled already?

Hi Jan,

We've asked Mark Hershberger to step in as Bugmeister.  More details:
http://lists.wikimedia.org/pipermail/wikitech-l/2011-January/051185.html

We plan to revisit this in the summer after we've filled some of our
other positions.  Mark may like the job so much and be well-suited
enough to it that we keep him in the role.

Rob

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

[Foundation-l] Another 1.17 maintenance window

[Rob Lanphier]

( repost from http://techblog.wikimedia.org )

Continuing with the work started last week[1], we plan to deploy 1.17
to more wikis in a couple hours.  We had hoped we would be able to
figure out the performance issues in the past week, but unfortunately,
the only practical way we have to see the load problems we witnessed
last week is to put the software into production.  We have put a lot
of instrumentation in place to help us diagnose our load issues.  We
plan to start the upcoming deployment by rolling out to
nl.wikipedia.org, and do some debugging (rolling back if necessary).
If we’re able to diagnose and fix the problems quickly, we then plan
to roll out 1.17 more widely.  If we’re still stumped, we may still
roll out to a few more low-traffic wikis, but leave the high-traffic
sites until we figure this out.

We plan to have more updates and detailed information on the
deployment page on mediawiki.org[2].  Thanks for your patience!

Rob
[1]  http://techblog.wikimedia.org/2011/02/1-17deployment-attempt2/
[2]  http://www.mediawiki.org/wiki/MediaWiki_1.17/Wikimedia_deployment

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

Re: [Foundation-l] New two-part schedule for 1.17 deployment

[Rob Lanphier]

Hi everyone

Deployment is underway now.  Please drop in on #wikimedia-tech and
ping me if you spot anything bad.

On Thu, Feb 10, 2011 at 9:49 PM, K. Peachey  wrote:
> On Fri, Feb 11, 2011 at 8:59 AM, Rob Lanphier  wrote:
>> http://usability.wikimedia.org/ (usabilitywiki)
> Um, usability is closed and no longer used... Perhaps mediawiki wiki
> would be a better choice instead?

Well, as it turns out, it was sufficient for us to spot a couple of
problems, so it's already been a pretty good choice.  I suppose we
didn't really have to wait until our deploy window to deploy to that
one, but what the heck  :)

Rob

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

[Foundation-l] New two-part schedule for 1.17 deployment

[Rob Lanphier]

Hi everyone,

In case you missed it on the techblog, here's an update on the revised
deployment plan for 1.17, part 1 of which starts in 7 hours:
http://techblog.wikimedia.org/2011/02/1-17deployment-attempt2/

Also copied below.

Rob
--

As covered on this blog this week, we had a few problems with our
initial deployment of 1.17 to the Wikimedia cluster of servers.  We’ve
investigated the problems, and believe we have fixed many of the
issues.  Some of the unsolved issues are complicated enough that the
only timely and reasonable way to investigate them is to deploy and
react, so we’ve come up with a plan that lets us do it in a safe way
by deploying on just a few wikis at a time (as opposed to all at once,
as we tried earlier).

We’re scheduling two deployment windows:

First window – This wave will be deployed between Friday, February 11,
6:00 UTC – 12:00 UTC (10pm PST Thursday, February 10 in San
Francisco).  This first wave will be to a limited set of wikis (see
below).
Second window – Wednesday February 16 (between 6:00 UTC – 12:00 UTC) –
full deployment (tentative)
Repeating what is new about 1.17:  There are many, many little fixes
and improvements (see the draft release notes for an exhaustive list),
as well as one larger improvement: Resource Loader.  Read more in the
previous 1.17 deployment announcement.


First window
This first deployment window will be to a limited set of wikis:

http://simple.wikipedia.org/ (simplewiki)
http://simple.wiktionary.org/ (simplewiktionary)
http://usability.wikimedia.org/ (usabilitywiki)
http://strategy.wikimedia.org/ (strategywiki)
http://meta.wikimedia.org/ (metawiki)
http://eo.wikipedia.org/ (eowiki)
http://en.wikiquote.org/ (enwikiquote)
http://en.wikinews.org/ (enwikinews)
http://en.wikibooks.org/ (enwikibooks)
http://beta.wikiversity.org (betawikiversity)
http://nl.wikipedia.org (nlwiki)
Note that the point of this first round of wikis being switched over
is to be able to observe the problem or problems without overloading
the site and bringing it down.  This deployment should be small enough
in scope that even if there are moderate performance problems, no one
should notice without watching our monitoring tools.  We may not roll
out to every wiki listed above during the first wave, but we plan to
roll out to enough of them that we can gather enough debugging
information to make the second wave (full deployment) go smoothly.

Second window
We will continue to roll this out to the rest of the wikis during this
window.  Depending on our confidence level, we may deploy to the
remaining wikis, or we may decide to deploy to a portion of the
remaining wikis.  If necessary, we will schedule another window to
finish the deployment.

Technical details
Here’s some more technical detail: one problem with the original
Tuesday deploy was that the cache miss rate went up quite
substantially.  We believe the problem was a problem with the
configuration of the $wgCacheEpoch variable, which caused more
aggressive culling of our cache than the servers could handle.  We
have made adjustments, and so this shouldn’t be a problem during our
next deployment attempt.

The $wgCacheEpoch problem explains some of the problems we had, but
not all of them.  Since we don’t have a clear explanation for all of
the problems, we plan to modify the way we deploy this software so
that we aren’t rolling this out to every wiki simultaneously.  As our
software is currently built, this isn’t easy to do in a general way,
but it turns out this release is suited to an incremental deployment.
(Note: we also plan to develop a more general capacity to roll out
incrementally for future releases).

Thank you for your patience!  We hope that this time around we can
deploy this in a way that you won’t notice anything other than the
improvements.

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

Re: [Foundation-l] [Wikitech-l] Big problem to solve: good WYSIWYG on WMF wikis

[Rob Lanphier]

Hi Brion,

Thanks for laying out the problem so clearly!  I agree wholeheartedly
that we need to avoid thinking about this problem too narrowly as a
user interface issue on top of existing markup+templates.  More
inline:

On Tue, Dec 28, 2010 at 9:27 AM, Brion Vibber  wrote:
> This isn't a problem specific to Wikimedia; established organizations of all
> sorts have a very difficult time getting new ideas over that hump from "not
> good enough for our core needs" to "*bam* slap it everywhere". By
> concentrating on the areas that aren't served at all well by the current
> system, we can make much greater headway in the early stages of development;
> Clayton Christensen's "The Innovator's Dilemma" calls this "competing
> against non-consumption".

Thankfully, we at least we're not trying to defend a business model
and cost structure that's fundamentally incompatible with making a
change here.  However, I know that's not the part that you're
highlighting, and I agree that Christensen's "competing against
non-consumption" concept is well worth learning about in this
context[1], as well as the concepts of "disruptive innovation" vs
"continuous innovation"[2].  As you've said, we've learned a lot in
the past decade of Wikipedia about how people use our the technology.
A new editing model that incorporates that learning will almost
certainly take a while to reach full parity in flexibility, power, and
performance.  The current editor base of English Wikipedia probably
won't be patient with any changes that result in a loss of
flexibility, power and performance.  Furthermore, many (perhaps even
most) things we'd be inclined to try would *not* have a measurable and
traceable impact on new editor acquisition and retention, which will
further diminish patience.  A mature project like Wikipedia is a hard
place to hunt for willing guinea pigs.

> For the Wikipedia case, we need to incubate the next generation of
> templating up to the point that they can actually undercut and replace
> today's wikitext templates, or I worry we're just going to be sitting around
> going "gosh I wish we could replace these templates and have markup that
> works cleanly in wysiwyg" forever.
>
> My current thoughts are to concentrate on a few areas:
> 1) create a widget/gadget/template/extension/plugin model built around
> embedding blocks of information within a larger context...
> 2) ...where the data and rendering can be reasonably separate... (eg, not
> having to pull tricks where you manually mix different levels of table
> templates to make the infobox work right)
> 3) ...and the rendering can be as simple, or as fancy as complex, as your
> imagination and HTML5 allow.

Let me riff on what you're saying here (partly just to confirm that I
understand fully what you're saying).  It'd be very cool to have the
ability to declare a single article, or probably more helpfully, a
single revision of an article to use a completely different syntax.
There's already technically a kludgy model for that now:  wrap the
whole thing in a tag, and put the parser for the new syntax in a tag
extension.  That said, it would probably exacerbate our problems if we
allowed intermixing of old syntax and new syntax in a single revision.
 The goal should be to move articles irreversibly toward a new model,
and I don't think it'd be possible to do this without the tools to
prevent us from backsliding (for example, tools that allow editors to
convert an article from old syntax to new syntax, and also tools that
allow administrators to lock down the syntax choice for an article
without locking down the article).

Still, it's pretty alluring to think about the upgrade of syntax as an
incremental problem within an article.   We could figure out how to
solve one little corner of the data/rendering separation problem and
then move on to the next.  For example, we could start with citations
and make sure it's possible to insert citations easily and cleanly,
and to extract citations from an article without relying on scraping
the HTML to get them.  Or maybe we do that certain types of infoboxes
instead, and then gradually get more general.  We can take advantage
of the fact that we've got millions of articles to help us choose
which particular types of data will benefit from a targeted approach,
and tailor extensions to very specific data problems, and then
generalize after we sort out what works/doesn't work with a few
specific cases.

So, which problem first?

Rob

[1]  Those with an aversion to business-speak will require steely
fortitude to even click on the url, let alone actually read the
article, but it's still worth extracting the non-business points from
this article:
http://businessinnovationfactory.com/weblog/christensen_worldinnovationforum
[2]  While there is a Wikipedia article describing this[3], a better
description of the important bits is here:
http://www.mail-archive.com/haskell@haskell.org/msg18498.html
[3]  Whee, footnote to a footnote!
http://en.w

Re: [Foundation-l] Old Wikipedia backups discovered

[Rob Lanphier]

On Tue, Dec 14, 2010 at 7:54 AM, Tim Starling  wrote:
> I was looking through some old files in our SourceForge project. I
> opened a file called wiki.tar.gz, and inside were three complete
> backups of the text of Wikipedia, from February, March and August 2001!
>
> This is exciting, because there is lots of article history in here
> which was assumed to be lost forever.

Wow, this is really, really amazing!  I'm not sure just how you
avoided having a heart attack after seeing this:
> --
> HomePage|979586833
> 1c1
> < Describe the new page here.
> ---
> > This is the new WikiPedia!

Great work!

Rob

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

[Foundation-l] Pending Changes development update: October 25

[Rob Lanphier]

Hi everyone,

This is another update on Pending Changes work.  Over the Hack-a-ton
weekend, Chad Horohoe and Priyanka Dhanda worked on two of the bigger
features for the November 16 Pending Changes update:

Bug 25294 - "Reject" button confirmation screen in Pending Changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=25294

Bug 25289 - Make review load faster by speeding up display of old revisions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25289

As of today, both of these are now deployed to our test site:
http://prototype.wikimedia.org/flaggedrevs

Additionally, since the last update, Brandon Harris has made a mockup
available of some additional UI changes:
http://www.mediawiki.org/wiki/Pending_Changes_enwiki_trial/NovemberReleaseDesignChanges

The full list of issues for the November 16 release is listed here:
https://bugzilla.wikimedia.org/showdependencytree.cgi?id=25293

We're not sure at this point just how much of the list we're going to
make it through, but we plan to do additional updates shortly after
November 16 with things that we don't get to.

Please provide your input in Bugzilla if you're comfortable with that;
otherwise, please remark on the feedback page:
http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback

Rob

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

Re: [Foundation-l] Page views

[Rob Lanphier]

On Sun, Oct 17, 2010 at 9:52 AM, Joan Goma  wrote:
> Is there any explanation for the extraordinary jump in page views this
> month?
>
> http://stats.wikimedia.org/EN/TablesPageViewsMonthly.htm

Hi Joan,

We're currently investigating.  We'll update here as more info becomes
available:
https://bugzilla.wikimedia.org/show_bug.cgi?id=25564

Rob

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

[Foundation-l] Pending Changes development update: October 6

[Rob Lanphier]

Hi everyone,

Pending Changes work continues apace.  The big thing we'd like to call
everyone's attention to:
http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback#Call_for_specific_feedback_on_UI_elements

We'd really like to get your input on specific suggestions that we can
implement quickly.  Speak now or forever hold your peace.  Well, maybe
not forever, but until after November.  At least, if you want to
implement your idea by November.

Here are the main development tasks that are active right now:
Bug 25294 - "Reject" button confirmation screen in Pending Changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=25294

Bug 25289 - Make review load faster by speeding up display of old revisions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25289

We'll be deploying the updates to these just as soon as they get
checked in.  Here's the location of the wiki we're using for testing
development versions:
http://prototype.wikimedia.org/flaggedrevs

...and finally, here's the full list of issues:
https://bugzilla.wikimedia.org/showdependencytree.cgi?id=25293

For those of you who might have missed it, Pending Changes was the
primary topic for Sue Gardner's office hour last week.
http://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_Sue_2010-09-30

Please provide your input in Bugzilla if you're comfortable with that;
otherwise, please remark on the feedback page:
http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback

Thanks!
Rob

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

Re: [Foundation-l] Pending Changes development update: September 27

[Rob Lanphier]

On Wed, Sep 29, 2010 at 7:46 PM, Risker  wrote:
> The test wiki is here:  http://flaggedrevs.labs.wikimedia.org/wiki/Main_Page
> (MZMcBride seems to be the most responsive local bureaucrat, if you want to
> have admin permissions there.)

Actually, we're not updating the flaggedrevs.labs site anymore.  I've
just posted a little more about this here:
http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Pending_Changes_updates

> The current list of bugzillas being worked on is here (cribbed from RobLa's
> post)
>
> We're currently tracking the list of items we intend to complete in
> Bugzilla. You can see the latest list here:
> https://bugzilla.wikimedia.org/showdependencytree.cgi?id=25293

...and I'll note that there have been surprisingly few comments there.
 While I recognize Bugzilla may not be for everyone, I'd really
appreciate if we got some help bridging Bugzilla to our other modes of
communication, and with organizing the feedback.  Specific input mixed
in with an unorganized sea of general input is not nearly as likely to
find its way to the right person as specific input that's easily
rediscovered by the developer at the time that the problem is assigned
to them.

> Also cribbed from RobLa's message:
> Ongoing use of Pending Changes is contingent upon consensus after the
> deployment of an interim release of Pending Changes in November 2010,
> which is currently under development. The roadmap for this deployment
> is described here:
> http://www.mediawiki.org/wiki/Pending_Changes_enwiki_trial/Roadmap
>
>
> On looking at the bugzillas, I note that many of the more serious issues
> identified in the Roadmap are not addressed. I will leave it to RobLa to
> explain that rationale.

Can you please leave specific instances of the gaps you're referring
to on the talk page?
http://www.mediawiki.org/wiki/Pending_Changes_enwiki_trial/Roadmap

Generally, the plan is to fix the easy and obvious stuff for the
November release, while simultaneously developing a more comprehensive
plan.

Thanks
Rob

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

Re: [Foundation-l] Pending Changes development update: September 27

[Rob Lanphier]

On Tue, Sep 28, 2010 at 10:54 AM, Risker  wrote:
> Rob, without wanting to take any wind out of your sails, please don't start
> the next trial so soon.  The analysis from the first trial is nowhere near
> finished, the community has just started to consider criteria for a new
> trial, and following the very abnormal "majority rules" poll, there needs to
> be a lot of goodwill rebuilt in the community for the second trial to have
> any chance of success.


Hi Risker,

I think Erik has already covered a lot of ground in this thread, but
additionally, I'll point out that many of us were already planning to
be present talk about Pending Changes at the IRC office hour that
Philippe announced below, so that would seem a great time to cover the
disconnect here.

Rob
-- Forwarded message --
From: Philippe Beaudette 
Date: Tue, Sep 28, 2010 at 10:02 AM
Subject: [Foundation-l] Office hours with Sue Gardner
To: Wikimedia Foundation Mailing List
, English Wikipedia
, wikibook...@lists.wikimedia.org,
Mailing list for Wikiversity ,
wikiquot...@lists.wikimedia.org, wiktionar...@lists.wikimedia.org


Hi all,

Sue Gardner, the Executive Director of the Wikimedia Foundation, will
be having office hours this Thursday (September 30)  at 23:00 UTC
(16:00 PT, 19:00 ET, 01:00 Friday CEST) on IRC in #wikimedia-office.

If you do not have an IRC client, there are two ways you can come chat
using a web browser:  First, using the Wikizine chat gateway at
.  Type a
nickname, select irc.freenode.net from the top menu and
#wikimedia-office from the following menu, then login to join.

Or, you can access Freenode by going to http://webchat.freenode.net/,
typing in the nickname of your choice and choosing wikimedia-office as
the channel.   You may be prompted to click through a security warning,
which you can click to accept.

Please feel free to forward (and translate!) this email to any other
relevant email lists you happen to be on.


Philippe Beaudette
Head of Reader Relations
Wikimedia Foundation

phili...@wikimedia.org

Imagine a world in which every human being can freely share in
the sum of all knowledge.  Help us make it a reality!

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 mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Pending Changes development update: September 27

[Rob Lanphier]

Hi everyone,

As many of you know, the results of the poll to keep Pending Changes
on through a short development cycle were approved for interim usage:
http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Straw_poll_on_interim_usage

Ongoing use of Pending Changes is contingent upon consensus after the
deployment of an interim release of Pending Changes in November 2010,
which is currently under development. The roadmap for this deployment
is described here:
http://www.mediawiki.org/wiki/Pending_Changes_enwiki_trial/Roadmap

An update on the date: we'd previously scheduled this for November 9.
However, because that week is the same week as the start of the
fundraiser (and accompanying futzing with the site) we'd like to move
the date one week later, to November 16.

Aaron Schulz is advising us as the author of the vast majority of the
code, having mostly implemented the "reject" button.  Chad Horohoe and
Priyanka Dhanda are working on some of the short term development
items, and Brandon Harris is advising us on how we can make this
feature mesh with our long term usability strategy.

We're currently tracking the list of items we intend to complete in
Bugzilla. You can see the latest list here:
https://bugzilla.wikimedia.org/showdependencytree.cgi?id=25293

Many of the items in the list are things we're looking for feedback on:
Bug 25295 - "Improve reviewer experience when multiple simultaneous
users review Pending Changes"
https://bugzilla.wikimedia.org/show_bug.cgi?id=25295

Bug 25296 - "History style cleanup - investigate possible fixes and
detail the fixes"
https://bugzilla.wikimedia.org/show_bug.cgi?id=25296

Bug 25298 - "Figure out what (if any) new Pending Changes links there
should be in the side bar"
https://bugzilla.wikimedia.org/show_bug.cgi?id=25298

Bug 25299 - "Make pending revision status clearer when viewing page"
https://bugzilla.wikimedia.org/show_bug.cgi?id=25299

Bug 25300 - "Better names for special pages in Pending Changes configuration"
https://bugzilla.wikimedia.org/show_bug.cgi?id=25300

Bug 25301 - "Firm up the list of minor UI improvements for the
November 2010 Pending Changes release"
https://bugzilla.wikimedia.org/show_bug.cgi?id=25301

Please provide your input in Bugzilla if you're comfortable with that;
otherwise, please remark on the feedback page:
http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback

Thanks!
Rob

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

[Foundation-l] Pending Changes update for July 28

[Rob Lanphier]

Hi folks,

It's been a little while since I've sent out an update (sorry about that).
 The Pending Changes trial continues apace, with 1,382 articles configured
to use the feature as of this writing.

Most of the work on the software that powers Pending Changes is focused on
refactoring and stability.  Some of the performance problems associated with
this feature have been fixed, and we believe we have fixed all of the
user-visible performance problems.  Looking at our backend systems, there's
some areas where this feature is still causing more load than it should,
which is where our work is focused now.

Aaron Schulz, who has done the lion's share of the development to date
(thanks Aaron!) continues to stay involved, but at a much reduced level as
he focuses on non-Wikimedia stuff, while Chad Horohoe ramps up.

We'll be publishing some statistics soon which outline per page metrics on
revisions under Pending Changes.  Nimish Gautam and Devin Finzer (Devin is
an intern that is working for Wikimedia Foundation this summer) are working
on some statistics that they'll be publishing soon.  More discussion is
here:
http://en.wikipedia.org/wiki/Wikipedia_talk:Pending_changes/Metrics

It will be time for a vote soon about whether to keep Pending Changes
enabled on en.wikipedia.org.  We'll be pinging folks in the community about
the post-trial discussion.  If we're rigidly following the proposal, the
trial will end on August 15, regardless of whether a vote has happened.
 However, we're probably already running late for making a decision by then.
 For a variety of operational reasons, we plan to leave the feature running
while the community decides whether to keep the feature on, assuming that
process lasts no more than a month or so after August 15.

The main discussion area for this feature is here:
http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback

If you have comments/suggestions/questions, that's a good place to post
them.

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

Re: [Foundation-l] [Wiki-research-l] WikiCite - new WMF project? Was: UPEI's proposal for a "universal citation index"

[Rob Lanphier]

On Mon, Jul 19, 2010 at 1:20 PM, Brian J Mingus
 wrote:
> I have been working with Sam and others for some time now on brainstorming a
> proposal for the Foundation to create a centralized wiki of citations, a
> WikiCite so to speak, if that is not the eventual name. My plan is to
> continue to discuss with folks who are knowledgeable and interested in such
> a project and to have the feedback I receive go into the proposal which I
> hope to write this summer.

This sounds great.  Just speaking as a community member, I've been
thinking about this topic a long time myself, and have plenty to add
to the conversation.

> The proposal white paper will then be sent around
> to interested parties for corrections and feedback, including on-wiki and
> mailing lists, before eventually landing at the Foundation officially. As we
> know WMF has not started a new project in some years, so there is no
> official process. Thus I find it important to get it right.

I'd suggest finding an on-wiki spot to discuss this work.  Here's one
place this has been discussed in the past that may be a good place to
revive the conversation:
http://strategy.wikimedia.org/wiki/Proposal:Building_a_database_of_all_books_ever_published

Rather than commenting on list about the subject itself, I've
commented on the discussion page there:
http://strategy.wikimedia.org/wiki/Proposal_talk:Building_a_database_of_all_books_ever_published#Fact_database_6531

Rob

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

[Foundation-l] Pending Changes update for June 18

[Rob Lanphier]

Hi everyone,

As I'm sure you're all aware, the Pending Changes trial began earlier this
week, and seems to be off to a great start.  There are many issues to be
sorted out both on the community policy side and on the technical side, but
everyone here seems to grappling with the community issues without a lot of
prodding.  On the development front, the team now has a blissfully mundane
software maintenance/incremental improvement process to deal with, as
opposed to feeling antsy about needing to deploy.

With the launch out of the way, William is now wrapping up and turning the
project management reigns over to me.  When I first started contracting with
WMF back in the beginning of May, I had the mistaken assumption that I'd be
taking over then, since William had/has another huge opportunity that is
looming on the horizon that appeared likely to take 100% of his time.  In
our first meeting as we started going over the transition, he resolutely
pointed out "no, I'm staying until we deploy this, however long it takes".
 We are really glad he was able to stick with us through this, and we're
extremely grateful for his tenacity and commitment.  This feature would
likely have been delayed longer and would have missed many critical details
without him.  I learned a lot about project management working with him, and
enjoyed it a great deal.  Thanks William!

The main developers, (Aaron and Chad) plan to continue knocking down issues
as they discover them, as well as continuing to whittle down the backlog of
issues we postponed until after the initial deployment:
http://www.pivotaltracker.com/projects/46157

Some of the most significant work surrounds the "reject" button an a few
related tweaks.  Since the topic of how exactly to optimize the workflow is
still a subject of debate, we'd appreciate some feedback on the subject.
 The features in question are all linked to from here:
http://www.mediawiki.org/wiki/Extension:FlaggedRevs/Specifications

The trial itself is slated to last until August 15.  After that, community
consensus will be required to leave the feature on permanently.  A strict
reading of the proposed trial would suggest we're obligated to turn the
feature off immediately around August 15, but I've seen at least one comment
suggesting we leave it on that time.  I've proposed here that we instead
leave the feature turned on while we discuss the permanent status:
http://en.wikipedia.org/wiki/Wikipedia_talk:Pending_changes/Trial#leaverunningforvote

If you have any concerns that need the dev team's attention, please bring
them up here:
http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Pending_Changes_issues

We're a little behind in looking at that page, but we will get back to you
if you post there.  We'll also get back to you if you prefer to post to
Bugzilla:
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&component=FlaggedRevs

That's all for now.  Thanks for reading!
Rob
p.s. I didn't want to turn this email into a parody of an overly-long Oscar
speech, but I also did want to specially call out Aaron Schulz, the lead
developer on this project, who did a remarkable job developing and preparing
the software for this launch as well as making sure that any problems that
we did inadvertently introduced were knocked down extremely quickly (often
within minutes of finding out).  Great work, Aaron!
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

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

[Rob Lanphier]

On Thu, Jun 10, 2010 at 8:59 AM, Birgitte SB  wrote:

> --- On Wed, 6/9/10, Rob Lanphier  wrote:
> > From the vantage point of the "vendor" in this case, the
> > problem is compounded by the cognitive bias Erik pointed to (belief
> > that the group you're a member of is diverse, whereas other groups are
> > not).  The net result of different expectations in the community is that,
> > from the vendor point of viewer, it looks like the community is demanding
> a
> > customer-to-peer relationship, since that is the "average" opinion of a
> > pretty large and diverse group.  That's why I'm generally pretty
> > careful about using the term "the community", because for those not used
> to working out
> > in the open, it's really scary to get mixed up in public conversations.
>
> I think you are conflating two very seperate issues here.  There is a
> peer-to-peer relationship between developers (staff and volunteer) and a
> customer-vendor relationship between the larger non-technical consensus that
> is formed and developers (both staff and volunteer). Although I don't think
> I would describe it as "the customer is always right"; technical vetos by
> developers are common. The suggestion here is to eliminate the barriers
> between two groups of developers.  There will always be some kind of barrier
> between the largely non-technical community and developers.  There are a
> alot of rough edges to that customer-vendor relationship, but the volunteer
> developers have had alot of experience with the pitfalls there and can help
> staff developers navigate them.


My point is that many people conflate these two relationships, and that
furthermore, the two are inextricably bound in a world of total
transparency, since its impossible to communicate to one group without the
other overhearing.  Furthermore, a "customer-vendor"-style relationship
between the larger non-technical consensus and the development community is
probably not sustainable in the world of completely transparent open source.
 It still needs to be more collaborative in nature.  The latter point is
fairly well understood when the development community is almost completely
decentralized (think Linux or Apache), but becomes muddier (but no less
true) when there is a central organization involved.

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

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

[Rob Lanphier]

On Wed, Jun 9, 2010 at 7:08 PM, MZMcBride  wrote:

> Rob Lanphier wrote:
> > So, I'll start chipping in my work at the page Erik has started:
> > http://usability.wikimedia.org/wiki/Product_Development_Process_Ideas
>
> You all really just don't get it, do you? Part of the problem is that the
> usability wiki is viewed as a walled garden. Your "solution" is to create a
> page there for others to add comments?
>
> Meta-Wiki is the Wikimedia community's wiki. Go there and create a
> dialogue.
>
>
Um, ok:
http://meta.wikimedia.org/wiki/Product_Development_Process_Ideas
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

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

[Rob Lanphier]

On Tue, Jun 8, 2010 at 6:28 PM, Aryeh Gregor

> wrote:

> It's not specific to Wikimedia, it's practically universal in
> open-source development.  To get it to happen, you need pushing from
> the top: formally stating it as part of people's job duties (so they
> don't feel they have to do "real work" instead), and forcing them to
> engage by only giving them public media to discuss things in with
> their co-workers.


Hi Aryeh,

First, let me state from the outset: I think it's great to work out in the
open, and I find that the people I'm working with at WMF are at the leading
edge of community collaboration on a number of fronts (compared to peers at
typical tech companies or even non-profits).  Feel Free to ping me on IRC,
email about anything I'm working on right now (that goes for others as
well).  Note also: in the spirit of this conversation, I didn't run this by
anyone at WMF, and I'm still using my @wikimedia.org address anyway (and I'm
only a contractor).  We'll see if I get in any hot water for that ;-)  Just
so you know, part of my job here (besides work on Pending Changes) is to
work on development process at WMF, so this thread is pretty relevant to my
day job here.

As you know, any time you want to compel someone to do something, there's
always the carrot and the stick.  One thing I don't like about the way
you've phrased that is that is that you seem to be advocating the stick.  Am
I reading that right?

One undertone that I've witnessed everywhere is that people in open source
communities that have a clear organizational "owner" is that there is a very
uneven distribution of people who want a peer-to-peer relationship versus a
customer-vendor relationship.  This makes it really difficult to work out in
the public, because some people seem to prefer the trappings of a
peer-to-peer relationship (let me in on your early thinking, publish your
roadmaps, work in the fishbowl), where others prefer the trappings of the
customer-vendor relationship (the customer is always right, the customer is
the boss).  Some will even go so far as to want a customer-to-peer
relationship, which is clearly not sustainable.  To be really clear here,
most of my impressions on this topic come from my previous work experience
(been doing the corporate open source thing for a while), and only in a
limited way with this community, but I've seen hints that the
WMF<=>community relationship has some of the same traits.

>From the vantage point of the "vendor" in this case, the problem is
compounded by the cognitive bias Erik pointed to (belief that the group
you're a member of is diverse, whereas other groups are not).  The net
result of different expectations in the community is that, from the vendor
point of viewer, it looks like the community is demanding a customer-to-peer
relationship, since that is the "average" opinion of a pretty large and
diverse group.  That's why I'm generally pretty careful about using the term
"the community", because for those not used to working out in the open, it's
really scary to get mixed up in public conversations.

One thing to consider about the IBM example is that IBM is a company of
about 400,000 employees, and was probably in the middle of their "we're
spending $1 billion/year on Linux" year when they instituted that policy.
 They could probably stand to be a little inefficient in the name of
insinuating themselves in the community.  We're not working with that sort
of cushion.

As someone who currently works from Seattle (and worked on a distributed
team in my last job), I also know that long distance collaboration (even in
the same timezone as SF) has its disadvantages from an efficiency
perspective.  Most people have a strong preference for face-to-face
communication for collaboration for good reason...it's high bandwidth.  Even
people who are really good at doing it take some time to figure out how to
be effective using only email and IRC; forcing people who aren't good at it
is really a productivity hit.

My recommendation is to strive to make it incredibly compelling for WMF
staff to work out in the community.  That means adhering to WP:BITE and
WP:GOODFAITH in spades, and reminding each other that we're all on the same
team here.  It means making sure that it actually feels like it's increasing
our productivity to do it, rather than feeling like a drag.  That's not to
say the burden needs to be solely on you all, but I think "forcing"
employees to work in the community is some customer-vendor thinking at play.

Don't get me wrong: I think it's an incredibly good idea for us to figure
out how to all work together better, and clearly a big part of that is going
to be strengthening our working relationship with non-employees.  It wasn't
that long ago I was a non-employee Wikipedian, and may be one again soon.  I
share your goal.  We have an amazingly diverse community with (very
importantly) a fantastic volunteer work ethic, and I think we should be able
to figure this out.

[Foundation-l] Renaming "Flagged Protections" to "Pending Changes"

[Rob Lanphier]

Hi everyone,

After much debate, we've settled on a name for the English Wikipedia
implementation of FlaggedRevs:  "Pending Changes".  This is a slight
variation on one of the finalists ("Pending Revisions") which has the
benefit of using the less jargony term "changes" instead of "revisions".
 The MediaWiki extension will continue to be named "FlaggedRevs", but the
greatly simplified subset of functionality that editors and readers on
en.wikipedia.org will see will be referred to as "Pending Changes" in the
user interface, help documentation, and other places that we'll talk about
this feature for non-developers working on English Wikipedia.

Thanks everyone for weighing in!  We'll be updating the message strings on
flaggedrevs.labs to reflect the new name:
http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Message_updates

Rob

On Wed, May 26, 2010 at 3:27 PM, Rob Lanphier  wrote:

> Hi everyone,
>
> It looks like the discussion on the name is dying down, so I'd like to
> summarize what I think we've heard here:
> 1.  There's no clear favorite out there.  In addition to the two ideas we
> put forward ("Pending Revisions" and "Double Check"), there's been quite a
> bit of discussion around alternatives, for example:  "Revision Review" and
> "Pending Edits".
> 2.  There's are still some that aren't comfortable changing the name away
> from "Flagged Protection", but that doesn't appear to be a widely held view.
> 3.  Some people like "Double Check", but some people dislike it a lot.  The
> people who like it seem to be comfortable with the colloquial use of it,
> whereas the people that dislike it don't like the lack of precision and the
> possible confusion created by the use of the word "double".
> 4.  "Pending Revisions" seems to be something most people would settle for.
>  It's probably not the hands down favorite of too many people, but it
> doesn't seem to provoke the same dislike that "Double Check" does.
> 5.  "Pending Edits" is a simplification of "Pending Revisions" that seems
> to have some support, as it replaces the jargony "Revision" with the easier
> "Edits"
> 6.  "Hyperion Frobnosticating Endoswitch" seems to have gathered a cult
> following.  Yes, we have a sense of humor.  No, we're not going there.  :-)
>
> A little background as to where we're at.  "Double Check" had an
> enthusiastic following at the WMF office, but we're not inclined to push
> that one if it's going to be a fight (it's far from the unanimous choice at
> WMF anyway).  "Revision Review" seems to be heading a bit too far into
> jargon land for our comfort.  "Pending Revisions" is the compromise that
> seems to stand up to scrutiny.  A variation such as "Pending Edits" or
> "Pending Changes" also seems acceptable to us.
>
> That's where we stand now.  If you haven't spoken up yet, now is the time,
> since we're only a couple of days from making a final decision on this.
>  Please weigh in here:
>
> http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolled_revisions/Terminology
>
> Thanks
> Rob
>
>
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Which pages to apply Flagged Protection to (Re: Renaming "Flagged Protections)

[Rob Lanphier]

On Thu, May 27, 2010 at 11:39 AM, James Heilman  wrote:

> I think the best way of rolling this out if it is possible would be to
> replace all semi protected articles with flagged protected or"double check"
> protected.  If it works well we could than either add more pages or apply
> it
> to all pages.
>

Hi James,

I think it'd be good to have a conversation on this talk page about the
subject of where to roll this out to:
http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolled_revisions/Trial

There's already been a little bit of discussion there, and should probably
be more.

Note that this page:
http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_revisions/Trial

...has a section titled "Initial article count limits".  We're planning on
putting an upper bound of 2000 articles, so putting all semi-protected
articles under the new regime is probably off the table.  Just speaking for
myself as a community member, it seems smart to limit this to pages that
would qualify for semi-protection.  It would be very appropriate to add a
policy sec

Speaking as a member of WMF, we think it's really important that the
community has policies ready when this rolls out, so thank you for
(re)starting the conversation.

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

Re: [Foundation-l] Renaming "Flagged Protections"

[Rob Lanphier]

Hi everyone,

It looks like the discussion on the name is dying down, so I'd like to
summarize what I think we've heard here:
1.  There's no clear favorite out there.  In addition to the two ideas we
put forward ("Pending Revisions" and "Double Check"), there's been quite a
bit of discussion around alternatives, for example:  "Revision Review" and
"Pending Edits".
2.  There's are still some that aren't comfortable changing the name away
from "Flagged Protection", but that doesn't appear to be a widely held view.
3.  Some people like "Double Check", but some people dislike it a lot.  The
people who like it seem to be comfortable with the colloquial use of it,
whereas the people that dislike it don't like the lack of precision and the
possible confusion created by the use of the word "double".
4.  "Pending Revisions" seems to be something most people would settle for.
 It's probably not the hands down favorite of too many people, but it
doesn't seem to provoke the same dislike that "Double Check" does.
5.  "Pending Edits" is a simplification of "Pending Revisions" that seems to
have some support, as it replaces the jargony "Revision" with the easier
"Edits"
6.  "Hyperion Frobnosticating Endoswitch" seems to have gathered a cult
following.  Yes, we have a sense of humor.  No, we're not going there.  :-)

A little background as to where we're at.  "Double Check" had an
enthusiastic following at the WMF office, but we're not inclined to push
that one if it's going to be a fight (it's far from the unanimous choice at
WMF anyway).  "Revision Review" seems to be heading a bit too far into
jargon land for our comfort.  "Pending Revisions" is the compromise that
seems to stand up to scrutiny.  A variation such as "Pending Edits" or
"Pending Changes" also seems acceptable to us.

That's where we stand now.  If you haven't spoken up yet, now is the time,
since we're only a couple of days from making a final decision on this.
 Please weigh in here:
http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolled_revisions/Terminology

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

Re: [Foundation-l] Renaming "Flagged Protections"

[Rob Lanphier]

On Mon, May 24, 2010 at 10:21 AM, William Pietri wrote:

> That did cross my mind, and it was tempting. But practically, many busy
> journalists, causal readers, and novice editors may base a lot of their
> initial reaction on the name alone, or on related language in the
> interface. By choosing an arbitrary name, some fraction of people will
> dig deeper, but another fraction will just retain their perplexity
> and/or alienation.


This is a really good point, and brings up another point for everyone to
consider.  If the name is not *immediately* evocative of something to the
casual reader, it might as well be called the "Hyperion Frobnosticating
Endoswitch".  It will be a blank slate as far as journalists and the world
at large is concerned.  I think we're better off with a term that gets us in
the ballpark with little or no mental energy than we are picking something
that has clinical precision, but takes more than a few milliseconds of
consideration to get the the gist.

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

Re: [Foundation-l] [WikiEN-l] Renaming "Flagged Protections"

[Rob Lanphier]

On Fri, May 21, 2010 at 3:34 PM, FT2  wrote:

> Might help to sum up what exactly it does or how it's used (2-4 bullet
> points) so that people trying to pick a name to match its features but
> haven't followed the lengthy debate, are up to date on it.
>

That's fair.  Here's the gist of it:
*  An unprotected article gets put under "Pending Revisions"/"Double Check"
by an admin
*  From that point forward, edits from anonymous users are listed as
"pending revisions", and aren't displayed to other anonymous readers by
default (though they'll be accessible from a "pending revisions" tab)
*  Any autoconfirmed user can then mark the latest pending revision as
"accepted", or revert to the latest accepted revision.

I just uploaded a bunch of images that may help people visualize the feature
as we see it:
http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_revisions/Terminology

Here's the permissions as we're currently planning to deploy them for the
trial:
http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_revisions/Trial

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

[Foundation-l] Renaming "Flagged Protections"

[Rob Lanphier]

Hi everyone,

As William alluded to, a bunch of us have been studying the user interface
for Flagged Protections and figuring out how to make it more intuitive.

In trying to solve the user interface problems as well as generally figuring
out how we're going to talk about this feature to the world at large, it
became clear that the name "Flagged Protections" doesn't adequately describe
the technology as it looks to readers and editors. It's a tough name to work
with. This iteration of the technology is very different from the German
implementation, and there's no "flagging" in the proposed configuration.
Additionally, "protection" in our world implies "no editing" whereas this
feature actually opens up pages currently protected so that everyone can
edit.

So, we would like to make a change to the name of the "Flagged Protections"
feature prior to deploying it to en.wikipedia.org. Under the hood, we would
still be using the "FlaggedRevs" extension (no change there), but the name
that we talk about in the user-visible portions of the site and
documentation would be something new.

Here were some criteria we're using to find a name:

   - Must not introduce obsolete terminology (e.g. there's no "flagging" in
   our proposed deployment)
   - Terminology should be consistent with terms we want to use in the user
   interface
   - Must not make too strong of a statement of quality/consensus or terms
   that make us out as publishers approving content from the mountaintop
   - Should not imply we're creating an elite new classes of users
   - Should not convey a strong sense of restriction. The feature, as
   proposed for the trial [1], is less restrictive than semi-protection
   - Should not be too geeky/too technical/too jargony
   - Should not be too slick/too cutesy. We're not doing this in the name of
   creating glossy brochures with pictures of a conference room full of people
   in formal business attire nodding with approval at a projection of a pie
   chart - we just want a name that won't be confusing.

It turns out that filters out quite a few names (including "Flagged
Protection" among other things). Here's the alternatives that made the cut:

   - "Pending Revisions" - this name is very consistent with what everyone
   will see in many parts of the user interface, and what it will be used for
   (i.e. providing a queue of pending revisions)
   - "Double Check" - this was a late entrant, but has the distinct
   advantage of clearly communicating what we envision this feature will be
   used for (i.e. enforcing a double check from a very broad community).

A protracted debate on the name will likely delay the eventual launch on the
feature, so we're hoping we can have a quick, respectful discussion on the
merits of the different proposals so that we can make the change quickly and
move on. We really need to have a name fully locked down no later than
Friday, May 28. Please let us know your thoughts here:

http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolled_revisions/Terminology

We're in the process of working on a lot of terminology tweaks in the user
interface in anticipation of the launch. If you're interested in that detail
work, I'll post more information about that on wikitech-l (hopefully by
end-of-day Monday), as well as on the talk page above.

Rob

[1] - See the proposed configuration for trial phase:
http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolled_revisions/Trial
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] FlaggedRevs - Do you forget about other projects?

[Rob Lanphier]

On Fri, May 21, 2010 at 12:26 PM, Rob Lanphier  wrote:

> On Fri, May 21, 2010 at 8:32 AM, William Pietri wrote:
>
>> We're very aware of the power of names. For those who have been
>> following my updates or the status of tasks in Tracker, you may have
>> noticed that a text and naming task has been in progress for weeks.
>> That's because good names are hard, and we really want to get them
>> right. I'm not really involved in that, so perhaps Howie or RobLa can
>> speak more directly to recent action there.
>>
>
>
> A much clearer explanation of the plan is on my list of things to do in the
> very near future (this afternoon if I'm lucky, more realistically by 6pm PDT
> on Monday).
>
> The strategy for dealing with the strings under the hood is a good
> conversation to have on wikitech-l, I think.  Any objection to moving the
> conversation there?
>
>
Oops, I forgot to mention, I'm planning on putting much of this
documentation here:
http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_revisions/Terminology

<http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_revisions/Terminology>That's
for those of you who don't want to join wikitech-l, but still want to be
part of the conversation.

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

Re: [Foundation-l] FlaggedRevs - Do you forget about other projects?

[Rob Lanphier]

On Fri, May 21, 2010 at 8:32 AM, William Pietri  wrote:

> We're very aware of the power of names. For those who have been
> following my updates or the status of tasks in Tracker, you may have
> noticed that a text and naming task has been in progress for weeks.
> That's because good names are hard, and we really want to get them
> right. I'm not really involved in that, so perhaps Howie or RobLa can
> speak more directly to recent action there.
>


A much clearer explanation of the plan is on my list of things to do in the
very near future (this afternoon if I'm lucky, more realistically by 6pm PDT
on Monday).

The strategy for dealing with the strings under the hood is a good
conversation to have on wikitech-l, I think.  Any objection to moving the
conversation there?

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