Erik Zachte <erikzachte(a)infodisiac.com> wrote:
> Revision Review (or any similar term) clearly signals this is a human
> process, which IMHO gets it 80% right already.
Review of a "revision cue" or "edit cue" works. You are right, as both
words "Flagged" and "Protections" convey an autocratic sense.
Note, on wikien-l, some are discussing what kind of "revert etiquette"
that Revision Review (formerly Flagged Protections) should use.
"Revert etiquette" seems inherently contradicted, though its at a good
sign that people are mindful that Revision Review can and probably
will be used in the wrong way.
-SC
(crossposted to foundation-l and wikien-l)
[ simulcasted to
http://en.wikipedia.org/wiki/Wikipedia_talk:Identifying_reliable_sources#Re…
]
"Though he remains the president of the Wikimedia Foundation," ...
"'He had the highest level of control, he was our leader,' a source
told FoxNews.com. When asked who was in charge now, the source said,
'No one. It’s chaos.'"
http://www.foxnews.com/scitech/2010/05/14/exclusive-shake-wikipedia-porn-pr…
In the classic tradition of WP:POINT violation I very much want to go
around to the "Wikimedia", "Wikipedia", and "Jimmy Wales" articles
editing them to reflect these surrealist "facts" as reported by this
"Reliable Source"... but that would be needlessly disruptive. (And I
fear similarly inspired people would continue that initiative,
grotesquely smearing Erik to reflect the repeated libel from prior
articles.) So, for the purpose of discussion, imagine that I did.
Many of us have long been aware that the reporting in some
professional media frequently has very little connection to reality.
Many of us know that they usually perform little to no fact checking,
and seldom even run their final drafts past someone with any
experience in the relevant area for a sniff test. Since they
apparently no longer suffer even the most minor harm from publishing
some of the most outrageous errors, why should they? In particular,
the online editions from many of these organizations appear to be
fairly comparable to randomly selected blogs. Presumably they feel
that they are just matching the qualities of their competition. So why
do we treat them differently?
I don't believe that this is, by any means, only a problem with Fox
although they might be the most obvious and frequent example.
Wikipedia reports what people say, not the truth of it— but we could
report the words of a random blog in context exactly as we do
Foxnews.com. We have an ethical obligation to not further
misunderstanding when we know better, which is what I always saw as
the most important justification for treating some sources as lesser
than others.
We know high-profile groups with a reputation to lose are going to
take more care to get it right, and that their errors are more likely
to trigger others to publish corrections. We could reasonably
speculate that their journalists' affiliation is primarily to the
truth, and this might not be as true of other information sources. We
can also argue that the views, even false ones, from a major news
provider are obviously more notable.
But I can't say that these points really apply in many cases that we
appear to be applying them: We would reject as reliable sources many
hobbyist blogs (or even webcomics) with a stronger reputation to
preserve, less obviously-compromised motivations, and _significantly_
greater circulation than some obscure corner of Fox News's online
product. What can be the explanation for this discrepancy?
Can we really continue in denial when these so-called 'reliable
sources' make such obvious and egregious errors about our own
projects?
If nothing else, is it possible to write a circulation based criteria
which reflects the reality that not all parts of a source have equal
exposure?
At 09:55 AM 5/24/2010, Abd ul-Rahman Lomax wrote:
>At 09:13 PM 5/22/2010, Rob Lanphier wrote:
>>What this means is that there would not actually be a separate "autoreview"
>>group. Autoconfirmed users would be given the access rights. I made this
>>simplification because I wasn't able to find any documentation of any clear
>>decision on this front.
>>
>>Since that time, a debate was started over here:
>>http://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Flagged_revisio…
I've commented in that discussion. Briefly, it should be a separate
privilege. It could be granted on request and approval, I'd assume,
by any administrator, but it definitely should be a revocable
privilege, not purely automatic (and not revocable except by
blocking) with autoconfirmation.
>> I suspect that any action by an autoconfirmed user will automatically
>> accept something of any actions not yet reviewed. Will those
>> autoconfirmed users get a warning that they might unwittingly be
>> accepting edits they might not have reviewed?
>>
>
> Yup, they do. There's a banner at the top of the page that tells them
> exactly this.
>
> Rob
>
>
I think this could cause complications. If I'm sorting out a typo like
artists preforming songs or discuss throwers then I assume that if I'm
marking my edit as minor no-one expects me to have checked the rest of
the article.
Is it going to be possible for admins to disable their autoreviewer status?
WereSpielChequers
Due to numerous requests we have extended the submission deadline for
Wikimania 2010 as follows:
* Abstract Registration: May 24, 11.59 p.m. (Pacific Time)
* Notification for workshops: May 29, 11.59 p.m. (Pacific Time)
* Notification for panels, tutorials, presentations: June 3, 11.59
p.m. (Pacific Time)
See the Call for Participation for more details:
http://wikimania2010.wikimedia.org/wiki/CFP
Thank you for helping make Wikimania 2010 a successful event. :-)
See you in Gdansk, July 9-11!
With best regards,
Wikimania Team
--
Casey Brown
Cbrown1023
On 5/21/10, Carcharoth <carcharothwp(a)googlemail.com> wrote:
> now need to try typing the title of the longest article (which was
> mentioned somewhere recently) to see if that will break the new gizmo.
> :-)
http://en.wikipedia.org/wiki/Longest_word_in_English ;-)
--
Casey Brown
Cbrown1023
On Fri, May 21, 2010 at 9:58 PM, Carcharoth <carcharothwp(a)googlemail.com>wrote:
> By the way, I'm assuming that some edits will be of the sort "I would
> normally remove the material and start a talk page discussion". In
> that case, is the right thing to do to approve the edit and then
> remove the material and start a talk page discussion, and presumably
> as a reviewer, your edit removing the material won't be caught up in
> flagged revisions itself?
Starting a separate thread since this is off of the naming topic.
I don't think it's necessary to accept the edit, since the unaccepted
version is never really marked as "rejected" in the edit history per se, but
rather, just never gets promoted. The edit will still exist in the edit
history, so it's not lost forever.
The right thing to do is to do the exact same thing you would do with an
unprotected page. If it's not obviously vandalism, you can use the undo
function with a polite note in the edit comment to discuss the change on the
talk page. Presumably, you're doing this as an autoconfirmed user, which
means that your edits will be automatically accepted.
Rob
Hi, everyone.
We have received problem reports and feedback that search queries were
truncated sometimes and the search suggestions were hard to read or
chose due to the limited width. We apologize for introducing broken
behaviors in using the search. In order to mitigate spreading the
problem, the new search function was disabled on May 15, and the search
field was increased by fifty percent on May 18. We are aware that this
temporary fix still does not accommodate the search for long article
names.
We have updated the new search interface to address the issues above and
it is currently staged on the the prototype [1]. This update addresses
the reported issues such as truncation of search queries [2] and the
search suggestions are cut-off [3]. Prototypes in various languages are
also available here[4].
Please give it a spin and let us know your feedback. If the
functionality is confirmed solid, we would like to re-enable the new
search feature later this week.
Thanks a bunch in advance,
- Naoko
User Experience Programs @ WMF
[1] http://prototype.wikimedia.org/en.wikipedia.org
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=23498
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=23558
[4] http://usability.wikimedia.org/wiki/Prototype
--
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
cc'd to lists that people read
On Tue, May 18, 2010 at 4:03 PM, Amir E. Aharoni
<amir.aharoni(a)mail.huji.ac.il> wrote:
> I sincerely hate to sound repetitive and annoying, but since the switch to
> Vector in en.wikipedia it's impossible to run a full-text search of
> Wikipedia using the search box if there's an article by the same name.
>
> The "Search" button is gone, because it was supposed to be possible to run a
> full-text search in the redesigned search box without that button, but
> apparently this doesn't actually work. It's only possible to run a full-text
> search by switching back to Monobook or by manually going to Special:Search
> (there's no link to it anywhere).
>
> So basically, for five days already it's practically impossible to search
> for information within Wikipedia. Read this again: it's impossible to search
> Wikipedia. Am i crazy if i think that this is a very severe problem?
>
> This is reported as a bug:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=23558
>
> The right thing to do is to restore the go and search buttons immediately
> and consider reintroducing the new search box after it has been thoroughly
> tested. Is there any reason not to do this?
>
> --
> אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> Amir Elisha Aharoni
>
> http://aharoni.wordpress.com
>
> "We're living in pieces,
> I want to live in peace." - T. Moore
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikipedia-l
>
As requested, here's the weekly Flagged Protection update.
The quick summary is that we are continuing with pre-rollout activities,
including UI polish, text and naming cleanup, and rollout planning.
One important milestone passed is that Tim Starling has looked over the
code and done some profiling and given it his blessing from a
performance perspective. He and the rest of the ops folks feel like the
production gear is also in good shape for rolling this out. However, to
prevent unpleasant launch surprises we've put in a configurable limit to
the number of pages protected with this. We'll start out at a limit of
2000 and bump it up based on actual production performance.
We believe we are technically ready to try out a labs version of the
German config, just to double-check that our recent work will cause them
no headaches. However, we need some German-speaker at least hazily
familiar with FlaggedRevs to prepare the main page and help us with a
call for testers. Any assistance there would be appreciated!
Speaking of assistance, we always welcome people trying out the
extension before it goes live. You can do that here:
http://flaggedrevs.labs.wikimedia.org/wiki/Main_Page
To see what we've changed this week, there's a list here:
http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Flagged_Protection_upd…
To see the upcoming work, it's listed in our tracker, under Current and
Backlog:
http://www.pivotaltracker.com/projects/46157
We expect to release to labs again next week, and each week thereafter
until this goes live on the English Wikipedia.
William