Delirium wrote:
> We've discussed on and off that it'd be nice to vet specific revisions
> of Wikipedia articles so readers can either choose to read only
> quality articles, or at least have an indication of how good an
> article is. This is an obvious prerequisite for a Wikipedia 1.0 print
> edition, and would be nice on the website as well.
>
> There is a lengthy list of proposals here:
> http://meta.wikimedia.org/wiki/Article_validation_proposals
>
> I wanted to try to rekindle the process by summarizing some of the
> proposals, which I think can be grouped into three main types, and
> then suggest some ideas on where to go from there.
Thank you for taking the time to address this.
> Proposal #1: Fork or freeze, then bring up to our quality standards.
> ---
> Wikipedians would look around for articles that look reasonably good
> (perhaps starting with feature articles) and nominate them to be
> worked on. Then either freeze them (by placing a notice or some sort
> of technical measure), or else fork them off to a copy. The articles
> would then be checked for referencing, accuracy, grammar, and so on,
> possibly only by users who've met some bar for participation in the
> clean-up process, resulting in an article suitable for publication.
> Forking or freezing is to ensure the cleanup process actually
> terminates rather than trying to clean up a moving target; there are
> of course pros and cons to forking vs. freezing.
>
> Some pros: Fairly straightforward; follows successful methods of
> "stable release" management in the software-development world; allows
> a certain amount of editorial work not normally suitable for an
> in-progress encyclopedia (like cutting out an entire section because
> it's too far from being done to go in the print version); is easy to
> integrate "expert review" into as a last vetting step before it goes
> out the door.
>
> Some cons: Either disrupts normal editing through a freeze, or results
> in duplicated effort with a fork. Also is likely to result in a
> fairly slow process, so the reviewed version of each article may be
> replaced with an updated version quite infrequently; most articles
> will have no reviewed version, so doesn't do much for increasing the
> typical quality of presentation on the website.
This option would work well, I think, for two possible uses. One is for
offline distribution, since there's less point in creating a fork that
will just be another online variation on the same theme. The second
possibility I think we would benefit from is the "freeze" option of
presenting stable, reviewed versions by default to users who do not log in.
> Proposal #2: Institute a rating and trust-metric system
> ---
> Wikipedians rate revisions, perhaps on some scale from "complete crap"
> to "I'm an expert in this field and am confident of its accuracy and
> high quality". Then there is some way of coming up with a score for
> that revision, perhaps based on the trustworthiness of the raters
> themselves (determined through some method). Once that's done, the
> interface can do things like display the last version of an article
> over some score, if any, or a big warning that the article sucks
> otherwise (and so on).
>
> Some pros: Distributed; no duplicated effort; good revisions are
> marked good as soon as enough people have vetted them; humans review
> the articles, but the "process" itself is done automatically; most
> articles will have some information about their quality to present to
> a reader
>
> Some cons: Gameing-proof trust metric systems are notoriously hard to
> design.
Aside from the manipulation problem, with this kind of approach I
wonder, "To what end?" Simply attaching a number to things is not that
interesting in and of itself. It needs to be put to some kind of use,
and while that's certainly possible, I'm more excited about potential
uses to which the other approaches better lend themselves.
Another potential concern I would point to with these is the possibility
of what might be called grade inflation. People might well start
criticizing the use of low scores as "biting newcomers" or something
like that. This would be an unfortunate reversal of the current trend
for featured articles, for which candidates have been held to
progressively higher standards. It also would undermine our hopes that
generally speaking, the content tends to improve over time.
> Proposal #3: Extend a feature-article-like process
> ---
> Extend a feature-article type process to work on revisions rather than
> articles. For example, nominate revision X of an article as a
> featured article; improve it during the process until it gets to a
> revision Y that people agree is good. Then sometime later, nominate a
> new revision Z, explain what the differences are, and discuss whether
> this should supercede the old featured version. Can also have
> sub-featured statuses like "good" or "mediocre, but at least nothing
> is outright wrong". In principle can be done with no code changes,
> though there are some that could ease things along greatly.
>
> Some pros: Gets at the effect of proposal #2 but with a flexible
> human-run system instead of an automatic system, and therefore less
> likely to be brittle.
>
> Some cons: Will need carefully-designed software assistance to keep
> all the information and discussion manageable and avoid descending
> into a morass of thousands upon thousands of messy talk pages
One of the weaknesses of directly modeling the featured article system
is that it doesn't scale well. I suppose in a sense that's part of what
you're saying, but you seem to suggest that it could be made to scale.
That might be possible but right now I don't see how, could you perhaps
elaborate on how you would design this? The suggestions I extrapolate
from this outline would to my mind mostly add complexity to the system,
and I'd expect them if anything to scale worse and not better.
> These are not necessarily mutually exclusive.
That's certainly true, although personally I mostly prefer elements of
the first approach.
--Michael Snow
(Mainly concerning wikipedia, but cross-posting to foundation-l because
of some discussion of committees; see the end.)
We've discussed on and off that it'd be nice to vet specific revisions
of Wikipedia articles so readers can either choose to read only quality
articles, or at least have an indication of how good an article is.
This is an obvious prerequisite for a Wikipedia 1.0 print edition, and
would be nice on the website as well.
There is a lengthy list of proposals here:
http://meta.wikimedia.org/wiki/Article_validation_proposals
I wanted to try to rekindle the process by summarizing some of the
proposals, which I think can be grouped into three main types, and then
suggest some ideas on where to go from there.
Proposal #1: Fork or freeze, then bring up to our quality standards.
---
Wikipedians would look around for articles that look reasonably good
(perhaps starting with feature articles) and nominate them to be worked
on. Then either freeze them (by placing a notice or some sort of
technical measure), or else fork them off to a copy. The articles would
then be checked for referencing, accuracy, grammar, and so on, possibly
only by users who've met some bar for participation in the clean-up
process, resulting in an article suitable for publication. Forking or
freezing is to ensure the cleanup process actually terminates rather
than trying to clean up a moving target; there are of course pros and
cons to forking vs. freezing.
Some pros: Fairly straightforward; follows successful methods of "stable
release" management in the software-development world; allows a certain
amount of editorial work not normally suitable for an in-progress
encyclopedia (like cutting out an entire section because it's too far
from being done to go in the print version); is easy to integrate
"expert review" into as a last vetting step before it goes out the door.
Some cons: Either disrupts normal editing through a freeze, or results
in duplicated effort with a fork. Also is likely to result in a fairly
slow process, so the reviewed version of each article may be replaced
with an updated version quite infrequently; most articles will have no
reviewed version, so doesn't do much for increasing the typical quality
of presentation on the website.
Proposal #2: Institute a rating and trust-metric system
---
Wikipedians rate revisions, perhaps on some scale from "complete crap"
to "I'm an expert in this field and am confident of its accuracy and
high quality". Then there is some way of coming up with a score for
that revision, perhaps based on the trustworthiness of the raters
themselves (determined through some method). Once that's done, the
interface can do things like display the last version of an article over
some score, if any, or a big warning that the article sucks otherwise
(and so on).
Some pros: Distributed; no duplicated effort; good revisions are marked
good as soon as enough people have vetted them; humans review the
articles, but the "process" itself is done automatically; most articles
will have some information about their quality to present to a reader
Some cons: Gameing-proof trust metric systems are notoriously hard to
design.
Proposal #3: Extend a feature-article-like process
---
Extend a feature-article type process to work on revisions rather than
articles. For example, nominate revision X of an article as a featured
article; improve it during the process until it gets to a revision Y
that people agree is good. Then sometime later, nominate a new revision
Z, explain what the differences are, and discuss whether this should
supercede the old featured version. Can also have sub-featured statuses
like "good" or "mediocre, but at least nothing is outright wrong". In
principle can be done with no code changes, though there are some that
could ease things along greatly.
Some pros: Gets at the effect of proposal #2 but with a flexible
human-run system instead of an automatic system, and therefore less
likely to be brittle.
Some cons: Will need carefully-designed software assistance to keep all
the information and discussion manageable and avoid descending into a
morass of thousands upon thousands of messy talk pages
---
These are not necessarily mutually exclusive. In my opinion, something
like #3 would be best suited to marking quality of revisions on the
website, and then the best of these could feed into a process like #1
that would do final vetting and cleanup before a print publication (in
addition to print-specific things like editing for space, formatting,
image resolution, etc.).
In any case, obviously proposals can come and go forever. None are
implemented, but that's partly because nobody wants to sink a bunch of
time into implementing a system when there's no guarantee it will even
be used. My hope is to condense the discussion so we choose some
high-level ideas on how to proceed before moving on to the inevitable
details, and then move to implementation once we've agreed what we
actually want.
On an organizational level, it may be useful to have a working group
sorting this out to focus the process. It may be useful, in my opinion,
for the Foundation to make it an official committee of sorts and
indicate at least informally that it'll support getting its
recommendations enacted (e.g. paying another developer if development
resources are the bottleneck). I would be willing to devote a
significant amount of time to such a committee, since I think this is
the single biggest problem holding back Wikipedia's usefulness to the
general public, and I'm sure there are at least several other people
with ideas and expertise in this area who would be willing to do so as well.
Thoughts?
-Mark
The Native Cherokee Language Translation Project has posted its first
series of XML dumps against enwiki 05-18-2006 at
ftp.wikigadugi.org/wiki
Please feel free to download and review. The translation is readable,
but requires conjugation and verb stem analysis reconstruction
to remove the remaining English words. Translation runs are performed
every few days and the translations are posted in Sequoyah Syllabary
and text phonetics. MediaWiki Messages.php files have been reviewed
line by line by our linguists. The Machine translation is a work in
progress.
Jeff Merkey
In response to Anthony and other related posts:
> Someone is needed to bootstrap the
> organization ... I think it's important to make it
> clear that this isn't a permanent position, though. In part, because
> it's dangerous to assign such a position when you really have no clue
> what the position is
> One thing I think is important though is the interim CEO should be
> made aware that a big part of eir job is going to be explaining eir
> actions to the entire membership
So far the CEO / COO / Director *interim* position can be summarised as
follows:
"We need help real fast. We don't know what help we need and would like you
to tell us. Please don't ruffle any feathers. Don't do anything without
telling everyone in the community. We'll get back to you about what we
decide."
So, appointing an *interim* CEO / COO / Director will have a result
equivalent to not appointing an *interim* CEO / COO / Director. The core
problem: "We don't know what to do next and we need help deciding what to
do," won't have been solved and can't be solved until the board and
community decide.
> You've given your own suggestions above, but what is the board going
> to do, say "hey, Gavin Chait said this is how we should do it, so lets
> go with it"? I don't think it's going to happen.
Why not? I have 15 years experience in South Africa developing and running
non-profit organisations in fields as diverse as HIV / AIDS, education and
small business development. I've worked with student-run, university-based
organisations, corporate funded ones, and institutional versions. I have
fund-raised, written proposals, developed ideas and implemented them. Some
of my ideas even work.
I'm probably not the only person with this sort of experience on this list
but I do have some idea of what it takes to run a self-sustaining non-profit
social benefit organisation.
So why not listen to my suggestions? They are my opinions, based on my
experiences. They are freely and honestly given. I don't have all the
answers but I may be able to save you some bother.
Erik Moeller wrote:
> On 6/12/06, Jimmy Wales <jwales(a)wikia.com> wrote:
>
>> We intend to hire a fulltime Executive Director following a very careful
>> process of consulting with the community, building support globally,
>> defining what the foundation needs, and a comprehensive search for a
>> good candidate, both *within the existing community* and *outside the
>> community*.
>
> Is there a timetable for this? Failing that, is there a definite
> commitment from all sides that this is, indeed, an interim position?
> When can we expect the first report about the outcome of the search
> process?
I think Jimmy was pretty clear about the interim part in making his
announcement. Brad has also commented on another list emphasizing that
point. Executive director and legal counsel are two distinct roles, and
I don't think anybody would be able to fill both of them simultaneously
for any significant length of time without a sizable staff at his or her
disposal (which obviously is not the case here).
Brad hasn't even had his first day on the job yet, so I think it's a
little early to be asking where the timetables and reports are. This
isn't even as far along as the process for replacing Tim Shell on the
Board, and I think Jimmy's response on that issue applies just as well
here. Let's have less haste and more speed. If you want to speed things
along, I'm sure an outline of the strategy for conducting the search
would be welcomed.
To address other questions about the Executive Director position and
this announcement, I've posted a FAQ on Meta
(http://meta.wikimedia.org/wiki/Executive_Director_FAQ). If people have
more issues they would like to discuss or questions to ask, I recommend
posting to the talk page so we can continue the conversation on the wiki.
--Michael Snow
In a message dated 6/11/2006 9:35:53 AM Eastern Daylight Time,
wikilegal(a)inbox.org writes:
I'm having some trouble finding very much useful information on that
site. Lots of links to stuff I can buy, but I can't even find the
description of "what board membership entails" that you allude to.
Can you give a more specific link, or were you suggesting we sign up
for the seminar? The latter might be an excellent idea for those
board members that can attend, though it's important to check out a
few competing services first.
Start with the Q&A's and work your way through the site. This is not about
attending seminars. This is about the basic responsibilities of Board members.
Angela in
http://mail.wikipedia.org/pipermail/foundation-l/2006-May/007241.html
How? Previous public Wikimedia meetings have led nowhere and done nothing
other than highlight how few people in the communities are interested in
_doing_ anything - as opposed to debating on mailing lists.
[....]
Nice idea... how about you suggest how that might happen? There are
currently two community representatives on the Board, though it's
increasingly obvious that the community are not using either Anthere or
myself to get anything to happen. Anything that does happen comes through
private mailing lists and an increasing number of internal processes that
even Board members don't always have access to.
Anthere in
http://mail.wikipedia.org/pipermail/foundation-l/2006-May/007298.html
One of the hardest things is to identify the needs of "system Foundation",
talk about these needs, and read criticism from people belonging to "system
Wikipedia", who have no beginning of an idea of
where the need comes from, why it is critical... but who considers they have
a say nevertheless.
----------------------------------------------------------------------------
-------------------------------
I am still amazed at how quickly Wikimedia transforms, politically speaking.
Less than two years ago Angela and Anthere were voted into the first
Wikimedia board. They had to invent their own role, as people had forgotten
to discuss the mission of the board and decision making procedures in any
detail. I repeat this remark that I made earlier, because I think it is
important to not make this same mistake again when a CEO is hired or voted
for (not that I favour a CEO per se).
In the beginning both Angela and Anthere opposed vocal members of the
community who urged the board to take a stand in matters that were hardly or
not at all discussed on the mailing lists. Kudoos for that.
Later we got closed wikis and private board chats as a side affair. Recent
statements like the ones quoted above give the impression that both board
members find the Wikimedia community has become a pain in the neck at times,
better to be ignored, or kept in the dark. Fortunately they make these
remarks still in the open, so there is hope :)
I still believe in both Angela's and Anthere's good intentions, they did and
do generally a tremendous job, to be sure, and therefore I really think it
is the burden on their shoulders that has become too large. May I suggest a
wikibreak? After all Jimbo has returned to this mailing list after relative
absence for several months. He can step in for a while I would hope.
I agree the board is understaffed. Or rather they have too many self chosen
obligations. An attempt to introduce checks and balances in the form of a
wikicouncil (initiative by the board!) died a quick death, maybe partly
because it was hardly advertised, or maybe because it was launched too soon.
So now we have a self appointed government without a parliament to guide and
control them. http://meta.wikimedia.org/wiki/Wikicouncil Self appointed
because the original purpose of the board was to serve for external
representation, as a compromise towards an outer world that stil used the
outdated paradigm of official representatives, see
http://mail.wikipedia.org/pipermail/foundation-l/2004-May/000065.html and
what follows.
Let us assume a larger board would be the way to go. Anthere expressed her
wish to have one board member from each committee. As far as I know most or
all members on these committees were appointed by the board, without public
vote or even much prior public discussion. I'd rather be called critical
than cynical, so I'll resist the temptation to extrapolate where this
'representational model' might lead us in a year from now.
Erik Zachte
I presume this is public, despite me knowing it only from the CommComm
mailing list...
bradp.wmf(a)gmail.com
Nick/Zanimum
> Message: 6
> Date: Mon, 12 Jun 2006 22:47:46 -0500
> From: "Kelly Martin" <kelly.lynn.martin(a)gmail.com>
> Subject: Re: [Foundation-l] Hiring of Interim Executive Director and
> Legal Counsel
> To: "Wikimedia Foundation Mailing List" <foundation-l(a)wikimedia.org>
>
> Really dumb question, but one which needs answering: What's Brad's
> new email address? The only one I have for him is the fowlerwhite
> address, and I assume that that's not good, since he doesn't work for
> them anymore.
>
> Kelly
On 27/05/06, Angela <beesley(a)gmail.com> wrote:
> How? Previous public Wikimedia meetings have led nowhere and done
> nothing other than highlight how few people in the communities are
> interested in _doing_ anything - as opposed to debating on mailing
> lists.
I apologise if i came across preachy or whiney or anything and i
appreciate being on the board can't be easy what with constant howls
of cabals and whatnot by the tinfoil hat brigade. What i am perhaps
getting at here is asking if anyone knows/cares if the majority of
wikimedians agree (or even know about) the current direction being
taken by the foundation. That is making the foundation more than a
body who provides servers, bandwidth, developer support, and deals
with legal issues arising from writing the world's biggest and best
encyclopedia, dictionary, source of free books, news, and open content
repository (did i miss any?).
Tim Starling has said before (and i apologise if i am misquoting him)
that we basicly got lucky with the idea of a wiki encylopedia and that
we should really just stick to what we are good at. I have always
disagreed with this point of view but lately have been coming around
to it, because you know what what, the results of what the average
wikimedian does have been hugely successful but other things we've
tried or talked about trying just don't seem to live up to its
success. I just don't think it is our role to deal with the problems
of Africa and any of the other projects envisioned.
That is not to say that all the amazing idealism and good intentions
constantly shown are a bad thing TM. I am just throwing this out there
as an idea but perhaps we should have to separate but linked
organisations. One non-profit organisation whose only charge is to own
and buy servers/bandwidth, support devs and to provide the legal
backing for wikimedia this would be as small and lean as possible
(though would presumably hire at least one lawyer and accountant). The
other would be a more traditional charity and would be charged with
overseeing and sponsoring wikimania, getting grants for special
projects and trying to get wikipedia on to mobile phones and all the
other cool stuff people want to do. People would be able to choose to
which of the organisations they would like to donate. Perhaps two
organisations is too radical but perhaps some kind of internal
breakdown of the foundation into core functions and non-core
functions. I dunno. I'm just throwing this out there as an idea to
start a conversation because I appreciate that although the foundation
has worked hard to try to be inclusive, there are a large number of
people (or at least i get the feeling that there are anyway) who feel
like the foundation is going in a direction contrary to where they
would like it to go.
Then again maybe i'm misinterpreting the wikimedian community (i only
subsist in a very small bit of it) and everyone is quite happy with
what the foundation is doing and where it is heading. I dunno.
paz y amor,
-rjs.
> Nice idea... how about you suggest how that might happen? There are
> currently two community representatives on the Board, though it's
> increasingly obvious that the community are not using either Anthere
> or myself to get anything to happen. Anything that does happen comes
> through private mailing lists and an increasing number of internal
> processes that even Board members don't always have access to.
>
> Angela
--
DO NOT SEND ME WORD ATTACHMENTS - I *WILL* BITE!
<http://www.gnu.org/philosophy/sylvester-response.html>
Hit me: <http://robin.shannon.id.au> [broken]
Jab me: <robin.shannon(a)jabber.org.au>
Upgrade to kubuntu linux: <http://releases.ubuntu.com/kubuntu/breezy/>
Faith is under the left nipple. -- Martin Luther