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:
On Wed, May 26, 2010 at 3:27 PM, Rob Lanphier <robla(a)wikimedia.org> 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
> 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:
Hello. I've just joined the list, as soon as I've known about the Wikidata
I've been thinking about a Wikidata project even before I knew about the
ideas proposed at Meta. I've explained it to several people in Spanish
wikipedia, and there I've begun work on "Wikidata-compliant" population
data templates, which are also found in en.wiki and de.wiki. Obviously
Wikidata seems almost "a must" for me, not only for providing up-to-date
data once for all the wikis, but also for providing global solutions to
show it (graphics, tables...), and many other ideas.
But the proposals at Meta don't seem to advance, and the Wikidata mailing
list (!) is inactive from 2007. Recently I asked in IRC, and Gerard talked
to me about Omegawiki; currently used for dictionaries, but could possibly
expand to Wikidata. On the other hand, the "global templates" or
"Commons-like" solution for Wikidata would need no "extra interface" as
Omegawiki does (so, faster implementation and adaptation) and there could
be useful global templates not related to data. But that wouldn't be a
real database to interact with (from Toolserver, for example).
Anyway, it seems clear to me that Wikidata is necessary, and that it
should be an independent Wikimedia project, whichever the way it is
implemented. I hope it can be "pushed" from here, and I'm ready to help
with the work when appropiate.
Looking forward to more ideas...
José Emilio Mori Recio, -jem- in the projects
It looks like a solution to bug 4547 is on the horizon.
See also [Wikitech-l] Reasonably efficient interwiki transclusion
This will be very useful for templates which Commons has developed,
especially language related templates, however I am concerned that
people are also planning on using Commons as a repo for Wikipedia
infoboxes, and including the *data* on Commons rather than just the
template code. e.g.
This centralisation of data makes sense on many levels, however using
Commons as the host of this data will result in many edit wars moving
to the Commons project, involving people from many languages. Even
the infobox structure can be the cause of edit wars.
I think it is undesirable to have these Wikipedia problems added to
Commons existing problems. ;-)
Tying Wikipedia and Commons closer together is also problematic when
we consider the differing audience and scope of each project,
especially in light of the recent media problems. If the core
templates and data used by Wikipedia are hosted/modified on Commons,
it will be more difficult to justify why Commons accepts content which
isn't appropriate on Wikipedia.
A centralised data wiki has been proposed previously, many times:
Non-WMF projects, such as freebase, dbpedia, etc., have been exploring
Isn't it time that we started a new project!? ;-)
A wikidata project could use semantic mediawiki from the outset, and
be seeded with data from dbpedia.
A lot of existing & proposed projects would benefit from a centralised
wikidata project. e.g. a genealogy wiki could use the relationships
stored on the wikidata project. wikisource and commons could use the
central data wiki for their Author and Creator details.
On Thu, May 27, 2010 at 11:39 AM, James Heilman <jmh649(a)gmail.com> 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
> to all pages.
I think it'd be good to have a conversation on this talk page about the
subject of where to roll this out to:
There's already been a little bit of discussion there, and should probably
Note that this page:
...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
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.
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.
This would make it more seamless, draw less potentially negative media
attention, and allow all those who will be dealing with these edits to
figure out how the system works. We do not want to end up like the baggage
terminal at that new terminal in London.
MD, CCFP-EM, B.Sc.
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
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
- 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 , 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:
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.
 - See the proposed configuration for trial phase:
I don't believe we should aim at a completely meaningless name out of
concern that some people may not get the finer details of what we try to
If we make that a rule for all features yet to be named we will again have
made our world a bit more impenetrable.
Remember how our 100+ acronyms are often cited as big hurdle for outsiders?
Revision Review (or any similar term) clearly signals this is a human
process, which IMHO gets it 80% right already.
If Mediawiki had been named Mediawiki Engine, and Wikimedia had been named
Wikimedia Organization, part of the current confusion for outsiders would
already have gone.
They may not understand from the name what kind of engine, of what kind of
organization, but they will have less trouble to tell these terms apart.
I'm very excited to welcome Ryan Kaldari to the Wikimedia Foundation as the Front End developer for fundraising. Ryan joins us from MTV Networks: Country Music Television, where he worked as a web developer responsible for several integration and architecture projects. Previous to that he helped develop Sitemason, an enterprise content management system used by numerous businesses, organizations, and colleges.
He's a long time Wikimedian who's been editing Wikipedia since 2004 and has been an admin since 2005. Some of you may have met him at the Paris Multimedia conference.
You can find what's kept him busy at http://en.wikipedia.org/wiki/User:Kaldari
He'll be starting June 1st and will work in the San Francisco office.
Ryan will bring in some much needed skills and experience to our fundraising software developments. He'll help us catch up on a lot of our pending fundraising software development projects, develop new tools and improve general infrastructure and will bring more general awesomeness to the team. He'll also work extensivelyto support and improve CiviCRM as our fundraising database platform.
Please join me in welcoming Ryan to the Wikimedia team! We'll be setting up his email as his start day gets closer but until then, you can reach him at <kaldari(a)gmail.com>.
Engineering Program Manger - Fundraising, Mobile, & Offline
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:
WikimediaAnnounce-l mailing list
> If Mediawiki had been named Mediawiki Engine, and Wikimedia had been named
> Wikimedia Organization, part of the current confusion for outsiders would
> already have gone.
> They may not understand from the name what kind of engine, of what kind of
> organization, but they will have less trouble to tell these terms apart.
Eh I realize that example was not well chosen. I take it back ;-)
People would of course confuse Wikimedia Organization (the movement)
with Wikimedia Foundation (the organization).