-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all!
This Thursday, October 1, 2009 between 9:00 AM and 10:00 AM PDT (UTC
16:00 and 17:00) Rand Montoya, Wikimedia's Head of Community Giving will
be joining us for office hours. Rand will be online to answer your
questions and talk about the role of fundraising for the Wikimedia
Foundation and the upcoming Fundriaser.
The IRC channel that will be hosting Rand's conversation will be
#wikimedia-office on the Freenode network. If you do not have an IRC
client, you can always 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. It's fine.
- --
Cary Bass
Volunteer Coordinator, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
PS: I'll be sending a follow up email to start a thread to discuss the
times of the office hours.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkrBLZ0ACgkQyQg4JSymDYmBRwCfTEu4qbPCvAmWg09/cs4ESwOy
vnQAniw77gSugbNW/GmwCoQ4fJitiWAv
=p3Sc
-----END PGP SIGNATURE-----
I've spoken with a lot of media folks about flagged revision of late. In one, I was told I'd be on at the last minute with a WP "critic" and never got the chance to correct the egregious errors in the intro segment (i.e., WP was hiring people to review the quality of articles.) That was disappointing.
However, an interview with Bryan Crump on Radio New Zealand was just posted -- and its only up this week -- that I think was rather excellent. But it lasts 40 minutes, so perhaps that's why :).
http://www.radionz.co.nz/national/programmes/nights/20090928
This discussion about splitting off sections to articles, notability and
undue weight reminded me of something I encountered recently:
What do you do if you find an article with a short description of the
subject followed by a huge criticism/controversy section with subsections
for every negative opinion about the subject ever published? It is sourced
so just removing most of it will get you reverted by the people who wrote
the article.
I think the ideal thing to do is to expand the other sections until the
criticism is balanced. Is there anything I can do if I don't have the time
or the expertise on the subject to write a long and good article? This must
be a rather common situation for obscure subjects in controversial areas.
One method I heard is effective is to split off the criticism section to a
separate article leaving a short summary. Someone else will probably
nominate it for deletion, which will often end in a delete/merge. Then you
just have to make sure the whole things isn't merged back. It just feels a
bit too underhanded.
There will be a slight delay ...
- d.
---------- Forwarded message ----------
From: Erik Moeller <erik(a)wikimedia.org>
Date: 2009/9/28
Subject: Re: [Foundation-l] Status of flagged protection (flagged
revisions) for English Wikipedia.
To: Wikimedia Foundation Mailing List <foundation-l(a)lists.wikimedia.org>
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(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>From the article:
"He is also known for his turbulent and controversial personal
life.[6] In 1969, his pregnant wife, Sharon Tate, was murdered by the
Manson Family, and in 1977, he was arrested in Los Angeles and pleaded
guilty to "unlawful sexual intercourse with a minor", a 13-year-old
girl; he fled the US and subsequently was a fugitive from US justice,
living in France and continuing to direct films."
This kind of transition is deplorably poor form. Separate events of
extreme difference in consequence cannot be stated in the same breath.
-Stevertigo
On Sep 28, 2009, at 10:56 AM, Philippe Beaudette wrote:
> IRC office hours for the strategy project are upon us again.... Our
> next office hours will be: 20:00-21:00 UTC, Tuesday 29 September.
> Local timezones can be checked at http://timeanddate.com/worldclock/fixedtime.html?month=9&day=29&year=2009&h…
>
> Office hours are on IRC (#wikimedia-strategy at freenode)
>
>
> You can access the chat by going to https://webchat.freenode.net/ and
> filling in a username and the channel name (#wikimedia-strategy). You
> may be prompted to click through a security warning. It's fine.
> Another option is http://chat.wikizine.org.
>
Re Risker's concern at the new page patrol problems being replicated
at flagged revisions. I agree that there are problems at new page
patrol, including both excessive speediness where pages are judged and
tagged within seconds of being created and occasional underkill where
plausible looking hoaxes are tagged as patrolled.
The underkill problem simply means that this is not perfect and we
will still need other methods of spotting vandalism such as watchlists
and looking at vandals previous edits.
The excessive speediness problem I would hope will be less serious
with flagged revisions as it merely establishes the principle that
every edit needs to be a net positive one. In my view it is a problem
if an editor creates a page with a good faith line or two and then has
it deleted before they can add the next line. I'm hoping that overkill
will be less at flagged revisions, and more easily dealt with. One
reason why I think this is that my experience has been that hugglers
and others who revert vandalism tend to be quick to apologise and
revert mistakes when IPs and newbies ask why their edit was reverted.
But tagging of one line articles for deletion is less likely to be
challenged by newbies or seen as an error by new page patrollers (I've
had lots of good feedback from new page patrollers for other CSD tags
I've declined - but rescued one line articles can get the response
"nicely rescued, but it wasn't like that when I tagged it").
I think that flagged revision patrolling will work best if we learn
the lessons of our existing systems and think of it as a series of
sieves of different grades. An initial very coarse grade that
identifies a lot of obviously good edits such as typo fixes and
obviously bad edits but leaves the complex minority flagged. A few
days for watchlisters to revert subtle vandalism and mark some good
edits as good. Followed by some more detailedl checking by those who
work at the back of the list on the oldest edits still flagged. One
enhancement that may seem counterintuitive would be to fix the back of
the list at a short interval such as a week, with anything not flagged
after then going live at that point. This would mean that everyone who
checks their watchlist weekly would have had a chance to revert
vandalism before it went live, and would mean that the wait would
never be longer than 7 days.
WereSpielChequers
> Given that New Page Patrol is constantly at a backlog of between 27-30 days
> (that is, there are always a significant number of new pages of that age),
> while at the same time we have problems with new pages being patrolled *too
> quickly* and CSD'd within 2 minutes, I think we will see the same issue with
> flagged revisions: that is, some edits being quickly passed without proper
> review, allowing sneaky vandalism in, while others take so long to be
> reviewed it takes away the wiki flavour.
>
> On the other hand, it might be a very different way of managing edit
> warring.
>
> Risker