Since Jimbo has announced the "move to 1.0" some month ago, not much has happened. Meanwhile, the tone of the press concerning wikipedia seems to be slowly drifting from "interesting, lots of potential" to "source of unreliable information". There's the "single printed volume" deal waiting in the wings, and Mandrake Linux would be interested in a wikipedia-on-DVD.
Since there seems to be long-standing consensus that wikipedia needs some form of review (as an additional option, *not* as a replacement for the wiki way!), I would very much like the discussion about the "how" to start again, and to reach a clonclusion this time, for a change :-)
It seems to me that most of you would agree to a method similar to this: * A (logged-in) user can approve a single version of an article. * At least two approvals are needed for the "wikipedia seal of approval" :-)
Now, the rapid change of wikipedia articles unveils this problem: * Does the second approval need to be for the *same version* as the first, or can it be for a later one, which then gets the "seal of approval"?
Also, given the different goals of an approval system, should there be * one approval only * one approval for "web version", one for "CD-ROM version", one for "printed version (single volume)", one for "printed version (30 voulmes)", etc.
Also, should there be * yes/no approval(s) * or rather a rating (0-9 or something)
For the record, my opionion to these: * approvals need *not* to be on the same version, but a "disapproval" could invalidate any prior approvals * one approval (we can sort out bot articles/extremely long ones later) * no rating (either it is a good one or not).
Magnus
On 07/16/04 18:24, Magnus Manske wrote:
Since there seems to be long-standing consensus that wikipedia needs some form of review (as an additional option, *not* as a replacement for the wiki way!), I would very much like the discussion about the "how" to start again, and to reach a clonclusion this time, for a change :-)
[[Wikipedia:Featured article candidates]] has been getting busier and is turning out a little more than one article a day at present. These are articles that theoretically meet the standard of [[Wikipedia:What is a featured article]] (rather than, say, [[Wikipedia:The perfect article]] and are voted to being on [[Wikipedia:Featured articles]] over the course of a week's straw-polls, feedback and improvement. These are the pool of articles that Raul654 draws the Main Page feature from.
If you're looking for a checklist for reviewing an article, [[Wikipedia:What is a featured article]] gives the sort of standard that just about any article should aspire to. Could be useful?
- d.
Magnus Manske wrote:
Since Jimbo has announced the "move to 1.0" some month ago, not much has happened. Meanwhile, the tone of the press concerning wikipedia seems to be slowly drifting from "interesting, lots of potential" to "source of unreliable information". There's the "single printed volume" deal waiting in the wings, and Mandrake Linux would be interested in a wikipedia-on-DVD.
Since there seems to be long-standing consensus that wikipedia needs some form of review (as an additional option, *not* as a replacement for the wiki way!), I would very much like the discussion about the "how" to start again, and to reach a clonclusion this time, for a change :-)
Hmm! "Clonclusion" = "conclusion" or "clone-clusion". :-)
It seems to me that most of you would agree to a method similar to this:
- A (logged-in) user can approve a single version of an article.
- At least two approvals are needed for the "wikipedia seal of
approval" :-)
I really don't see approvals as being the serious bottleneck. The difficulty seems to be in transition between talking about something and doing something about it.
Now, the rapid change of wikipedia articles unveils this problem:
- Does the second approval need to be for the *same version* as the
first, or can it be for a later one, which then gets the "seal of approval"?
It should be essentially for the same one, except for corrections of minor spelling errors or typos.
Also, given the different goals of an approval system, should there be
- one approval only
- one approval for "web version", one for "CD-ROM version", one for
"printed version (single volume)", one for "printed version (30 voulmes)", etc.
The existing Wikipedia should be the "web version". The same approval should cover the CD-ROM and single volume versions. We should not be giving serious consideration to the 30 volume version until we have developed experience with the single volume version
Also, should there be
- yes/no approval(s)
- or rather a rating (0-9 or something)
The numerical rating has much merit. and an average rating can be generated as a composite of these.
Making the 1.0 "print ready" requires making some tough choices based on more than a higgledy-piggledy random assortment of approved articles. I start from the premise that a 1.0 will eventually be followed by a 2.0. That means that we don't need to expect perfection in 1.0, nor do we need to cover absolutely every subject in Wikipedia, even if we already have some excellent articles in a subject. We would put our best foot forward by starting with those subject areas that are our best.
We probably also need a timetable for getting 1.0 out, and deadlines that need to be met. Perhaps we need a production oriented 1.0 committee, that can be decisive in its actions. A subsequent 1.1 committee (perhaps with different members) will be there in the wings for the next step.
Ec
On 07/16/04 19:31, Ray Saintonge wrote:
We probably also need a timetable for getting 1.0 out, and deadlines that need to be met. Perhaps we need a production oriented 1.0 committee, that can be decisive in its actions. A subsequent 1.1 committee (perhaps with different members) will be there in the wings for the next step.
Before we get a committee, we need a plan. Then, instead of a committee, we can have a commando action group ;-)
What do we have so far?
* Jimbo's statement that he doesn't want a fork from the current content, except at the very last stage before preparing for print. * Various plans for rating articles or versions of articles. (For edit war hot spots, expect vote spamming.) * Various lists of what *should* be in a single-volume encyclopedia. Completing these lists would be a fine program for volunteer recruitment, by the way. * A lot of articles with images that are fair-use, permission-granted, non-profit or of other non-free status to be cleared and replaced where at all feasible. * An interested publisher, one who actually gets it, waiting in the wings. (Jimbo, you said their name in London - is it still under wraps?) We need to know what they require from us, so we know what to aim for.
Anything important I've missed? Add it and we'll have the broad form of our action plan. Then it's a Simple Matter Of Volunteer Motivation. And we have a lot of experience at that.
- d.
David Gerard wrote:
- Various lists of what *should* be in a single-volume encyclopedia. Completing these lists would be a fine program for volunteer recruitment, by the way.
Did someone start such a list? If so, please give me a link...
According to
http://www.amazon.com/exec/obidos/tg/detail/-/0852298323/002-7007605-8700056... the concise Britannica contains ~28000 articles, which could be a number to aim for. Selecting the topics could be eased by using the category system.
Magnus
Magnus Manske wrote:
David Gerard wrote:
- Various lists of what *should* be in a single-volume encyclopedia. Completing these lists would be a fine program for volunteer recruitment, by the way.
Did someone start such a list? If so, please give me a link...
According to
http://www.amazon.com/exec/obidos/tg/detail/-/0852298323/002-7007605-8700056...
the concise Britannica contains ~28000 articles, which could be a number to aim for. Selecting the topics could be eased by using the category system.
That makes me a little nervous - we already have a problem with people who agglomerate more and more text into longer and longer "articles" instead of using hyperlinks to make things more readable. Marking an article as one of the "chosen" will just incentivize to do even more of that. I think you'd need some kind of cutoff mark in articles (which has been discussed previously), plus some kind of daily query that budgets by words rather than article count. If for instance someone add a sentence to [[tuna]] and thereby exceeds the 100Kword limit for science topics, whip out the list of longest science articles and start fighting about what to cut. :-)
It also occurs to me that these would be categories that you would not want displayed by default...
Stan
On 07/16/04 20:44, David Gerard wrote:
- Jimbo's statement that he doesn't want a fork from the current content, except at the very last stage before preparing for print.
- Various plans for rating articles or versions of articles. (For edit war hot spots, expect vote spamming.)
- Various lists of what *should* be in a single-volume encyclopedia. Completing these lists would be a fine program for volunteer recruitment, by the way.
- A lot of articles with images that are fair-use, permission-granted, non-profit or of other non-free status to be cleared and replaced where at all feasible.
- An interested publisher, one who actually gets it, waiting in the wings. (Jimbo, you said their name in London - is it still under wraps?) We need to know what they require from us, so we know what to aim for.
* [[Wikipedia:News style]] article intros wherever reasonable. Considering that in a lot of cases, those are going to become the article.
- d.
I just wanted to point out that when users were asked what they think is the most important thing programmers should be working on, only 4 out of 36, or 11% said formal review and distribution. The results in detail were:
Quality: 17 Screening for vandalism, with better watchlists, more configurable contributions pages and RC, etc. Features for organised patrol, marking edits as checked.
Performance: 12 Full text search, regularly updated special pages, response time, avoiding error messages in peak times, scalability. Working on performance keeps hardware costs down.
Syntax and rendering: 2 Templates with parameters that actually work, new kinds of data e.g. chemical structural formulas, chess, music, etc., browser compatibility, WAP access.
Distribution: 4 Formal review, CDs, DVDs, print, static HTML dumps.
User rights: 1 Partial bans on users, e.g. from namespaces or given sets of articles, or number of edits per day. Alternative methods for sysopping and desysopping. Dangerous actions by quorum or consensus. Partial page protection, using file replacement or similar. Automated sock puppet checks. Trust metrics.
Note that the results were likely skewed towards quality, since the poll was advertised in a village pump discussion on quality features.
-- Tim Starling
On 07/17/04 02:25, Tim Starling wrote:
I just wanted to point out that when users were asked what they think is the most important thing programmers should be working on, only 4 out of 36, or 11% said formal review and distribution. The results in detail were: Quality: 17 Performance: 12 Syntax and rendering: 2 Distribution: 4 User rights: 1
Note that the results were likely skewed towards quality, since the poll was advertised in a village pump discussion on quality features.
Yep. And people want today's problems fixed, not new features for new problems ;-)
- d.
Please remember that we '''do not need developer effort''' to move towards Wikipedia 1.0.
I think that improving the quality of major articles (a big part of moving towards 1.0) is the most important task for our editing community. Yet I also agree with the majority of those poll responders that vandalism screening and features for organised patrol are the most-needed development items (and these /do/ have some relevance to validation and quality control).
sj<<
On Sat, 17 Jul 2004 12:25:34 +1000, Tim Starling ts4294967296@hotmail.com wrote:
I just wanted to point out that when users were asked what they think is the most important thing programmers should be working on, only 4 out of 36, or 11% said formal review and distribution. The results in detail were:
Quality: 17 Screening for vandalism, with better watchlists, more configurable contributions pages and RC, etc. Features for organised patrol, marking edits as checked.
Performance: 12
Sj wrote:
Please remember that we '''do not need developer effort''' to move towards Wikipedia 1.0.
Yeah I've heard that before. Coding features is vastly easier than organising Wikipedians. If someone puts some pretty buttons on Wikipedia saying things like "review this article" and "mark for concise version", then people will start clicking them. Policies will emerge out of the chaos that ensues, and everything will come together. If someone wrote the feature 6 months ago, we'd be ready to print by now.
-- Tim Starling
Tim Starling wrote:
Sj wrote:
Please remember that we '''do not need developer effort''' to move towards Wikipedia 1.0.
Yeah I've heard that before. Coding features is vastly easier than organising Wikipedians. If someone puts some pretty buttons on Wikipedia saying things like "review this article" and "mark for concise version", then people will start clicking them. Policies will emerge out of the chaos that ensues, and everything will come together. If someone wrote the feature 6 months ago, we'd be ready to print by now.
I'm on it, I'm on it! :-)
Magnus
On 07/19/04 14:22, Magnus Manske wrote:
Tim Starling wrote:
Sj wrote:
Please remember that we '''do not need developer effort''' to move towards Wikipedia 1.0.
Ohhh yes we do. I've been researching this 1.0 question. Mostly that there's been *over a year* of wibbling on the mailing list to no end. Hence my use of the present Subject: line.
I'm really extremely interested in pushing the 1.0 thing and making a workable plan the cats will herd to, letting the wiki do the work and harnessing the power of dilettantism as admirably as we do. The work needed for a 1.0 will be stuff that will only help the live wiki version as well.
Yeah I've heard that before. Coding features is vastly easier than organising Wikipedians. If someone puts some pretty buttons on Wikipedia saying things like "review this article" and "mark for concise version", then people will start clicking them. Policies will emerge out of the chaos that ensues, and everything will come together. If someone wrote the feature 6 months ago, we'd be ready to print by now.
I'm on it, I'm on it! :-)
w00t!
Do we have a consensus on what things we want people to rate (accuracy, coverage, good writing, grammar/spelling?) what scale (yes/no, 0-4, 0-10?) and whether it's per version?
(I think there should be a bit of discussion before adding the feature about possible ill effects of the per-version thing. It may make people reluctant to polish minor problems in an otherwise high-rating version. I may be completely wrong, of course. But I worry that this one, a feature for 1.0, may have ill effects upon the live wiki.)
- d.
David Gerard wrote:
Do we have a consensus on what things we want people to rate (accuracy, coverage, good writing, grammar/spelling?) what scale (yes/no, 0-4, 0-10?) and whether it's per version?
(I think there should be a bit of discussion before adding the feature about possible ill effects of the per-version thing. It may make people reluctant to polish minor problems in an otherwise high-rating version. I may be completely wrong, of course. But I worry that this one, a feature for 1.0, may have ill effects upon the live wiki.)
My implementation can use scales, for yes/no decisions, a scale of 1/2 will do :-)
Different "types" can have different scales, so we could have a "Spelling" 1-5, and a "Use in 1.0" yes/no at the same time.
Currently, I am using yet another special page, and while that will stay for statistics etc., I'd like to have the "pure" rating page as another tab in the current skin, like "edit" and "history". Any help in coding is welcome :-)
Magnus
On Tue, 20 Jul 2004 00:21:11 +1000, Tim Starling ts4294967296@hotmail.com wrote:
Sj wrote:
Please remember that we '''do not need developer effort''' to move towards Wikipedia 1.0.
Yeah I've heard that before. Coding features is vastly easier than organising Wikipedians. If someone puts some pretty buttons on Wikipedia saying things like "review this article" and "mark for concise version", then people will start clicking them. Policies will emerge out of the chaos that ensues, and everything will come together. If someone wrote the feature 6 months ago, we'd be ready to print by now.
I think we are in agreement -- except perhaps for your time estimate. I note only that non-developers have work they can do immediately to further this project. I had the sense that many eager people were waiting for the discussion of which interface to implement, before working out what topics to cover, in how much space, starting with a focus on which areas.
+sj+
At 12:31 PM 7/16/2004 -0700, Ray Saintonge wrote:
Magnus Manske wrote:
Now, the rapid change of wikipedia articles unveils this problem:
- Does the second approval need to be for the *same version* as the
first, or can it be for a later one, which then gets the "seal of approval"?
It should be essentially for the same one, except for corrections of minor spelling errors or typos.
Users who approve a version of an article would likely watchlist it, so it doesn't seem like a major imposition to require them to review newer edits and give approval to newer versions if need be. Perhaps even have the software create a sort of parallel specialized watchlist that shows articles you've approved in the past that have had edits performed on them since then, both to make sure one doesn't forget to watchlist them and to make sure one's regular watchlist doesn't become cluttered.
Also, should there be
- yes/no approval(s)
- or rather a rating (0-9 or something)
The numerical rating has much merit. and an average rating can be generated as a composite of these.
Users should only have the yes/no option, IMO, since including or excluding an article is an all-or-nothing proposition. Combining multiple users' ratings into a more fine-grained number could be handy, though, showing whether the approval is controversial at a glance. The details of this rating system will no doubt be the subject of endless bickering, which I look forward to seeing the end result of. :)
Bryan Derksen wrote:
At 12:31 PM 7/16/2004 -0700, Ray Saintonge wrote:
Magnus Manske wrote:
Now, the rapid change of wikipedia articles unveils this problem:
- Does the second approval need to be for the *same version* as the
first, or can it be for a later one, which then gets the "seal of approval"?
It should be essentially for the same one, except for corrections of minor spelling errors or typos.
Users who approve a version of an article would likely watchlist it, so it doesn't seem like a major imposition to require them to review newer edits and give approval to newer versions if need be. Perhaps even have the software create a sort of parallel specialized watchlist that shows articles you've approved in the past that have had edits performed on them since then, both to make sure one doesn't forget to watchlist them and to make sure one's regular watchlist doesn't become cluttered.
Also, should there be
- yes/no approval(s)
- or rather a rating (0-9 or something)
The numerical rating has much merit. and an average rating can be generated as a composite of these.
Users should only have the yes/no option, IMO, since including or excluding an article is an all-or-nothing proposition. Combining multiple users' ratings into a more fine-grained number could be handy, though, showing whether the approval is controversial at a glance. The details of this rating system will no doubt be the subject of endless bickering, which I look forward to seeing the end result of. :)
I disagree. I believe that most users would prefer the ability to express shades of opinion. A numerical rating allows more information to be gathered; users who want to assert an all-or-nothing opinion can still vote 0 or 10. I would then suggest feeding the results to a robust estimator (using the median would be a good first hack) to prodice a fine-grained estimate. It would also be useful to have a robust spread measure to detect contentious articles.
By having a wide range of fine-grained estimates, and perhaps adding in factors for linkage, we can then prune the encyclopedia to any desired size by adjusting the threshold for inclusion.
-- Neil
On Sat, Jul 17, 2004 at 01:48:09PM +0100, Neil Harris wrote:
I disagree. I believe that most users would prefer the ability to express shades of opinion. A numerical rating allows more information to be gathered; users who want to assert an all-or-nothing opinion can still vote 0 or 10. I would then suggest feeding the results to a robust estimator (using the median would be a good first hack) to prodice a fine-grained estimate. It would also be useful to have a robust spread measure to detect contentious articles.
By having a wide range of fine-grained estimates, and perhaps adding in factors for linkage, we can then prune the encyclopedia to any desired size by adjusting the threshold for inclusion.
1. There are serious problems with having more than 2 options, but on the other hand 2 options are not enough to express all opinions. What is the meaning of each number ? Everyone knows when to give worst and best available rating, but what kind of article deserves 4 or 7 ? It works quite well on IMDB, where people select ratings thinking "this movie was about as good as movie X, which got 7.8, so i'll rate it 8". Will the ratings of the articles get coherent enough to provide such guildlines ? Or are we going to attach descriptions to each rating, in which case we get to another problem ...
2. How to produce a single number from all the ratings. There's no natural linearity in ratings, and if we were to assign descriptions to each rating, what's the "average" of "bad", "bad", "great" and "needs minor improvements" ? Median is conceptually better than mean, as it only requires ratings to be comparable ("bad" < "needs minor improvements" < "good" < "great" etc.), but it's quite dissatisfying that it completely ignores the difference between possible ratings below the median (ratings "horrible" and "needs minor improvements" are equivalent if the average is "needs minor improvements" or better), and above it ("great" == "needs minor improvements", if median is "needs minor improvements" or worse).
3. If we were to implement rating scheme, I think it would be the best option to have different each user's rating options and summary ratings. The summary ratings could be based on median, variance of ratings, and the number of votes.
For example: Available rating options: {horrible, needs major improvements, needs minor improvements, good, outstanding} Possible summary ratings: { not rated (no votes, or few votes and high variance), controversial (many votes, too high variance) extremely controversial (many votes, ratings dominated by horrible and outstanding) horrible (many votes, median 'horrible', small variance), probably horrible (median 'horrible', few votes or moderate variance), needs major improvements, probably needs major improvement, ... }
Tomasz Wegrzanowski wrote:
On Sat, Jul 17, 2004 at 01:48:09PM +0100, Neil Harris wrote:
I disagree. I believe that most users would prefer the ability to express shades of opinion. A numerical rating allows more information to be gathered; users who want to assert an all-or-nothing opinion can still vote 0 or 10. I would then suggest feeding the results to a robust estimator (using the median would be a good first hack) to prodice a fine-grained estimate. It would also be useful to have a robust spread measure to detect contentious articles.
By having a wide range of fine-grained estimates, and perhaps adding in factors for linkage, we can then prune the encyclopedia to any desired size by adjusting the threshold for inclusion.
- There are serious problems with having more than 2 options,
but on the other hand 2 options are not enough to express all opinions. What is the meaning of each number ? Everyone knows when to give worst and best available rating, but what kind of article deserves 4 or 7 ? It works quite well on IMDB, where people select ratings thinking "this movie was about as good as movie X, which got 7.8, so i'll rate it 8". Will the ratings of the articles get coherent enough to provide such guildlines ? Or are we going to attach descriptions to each rating, in which case we get to another problem ...
- How to produce a single number from all the ratings.
There's no natural linearity in ratings, and if we were to assign descriptions to each rating, what's the "average" of "bad", "bad", "great" and "needs minor improvements" ? Median is conceptually better than mean, as it only requires ratings to be comparable ("bad" < "needs minor improvements" < "good" < "great" etc.), but it's quite dissatisfying that it completely ignores the difference between possible ratings below the median (ratings "horrible" and "needs minor improvements" are equivalent if the average is "needs minor improvements" or better), and above it ("great" == "needs minor improvements", if median is "needs minor improvements" or worse).
- If we were to implement rating scheme, I think it would be the best option
to have different each user's rating options and summary ratings. The summary ratings could be based on median, variance of ratings, and the number of votes.
For example: Available rating options: {horrible, needs major improvements, needs minor improvements, good, outstanding} Possible summary ratings: { not rated (no votes, or few votes and high variance), controversial (many votes, too high variance) extremely controversial (many votes, ratings dominated by horrible and outstanding) horrible (many votes, median 'horrible', small variance), probably horrible (median 'horrible', few votes or moderate variance), needs major improvements, probably needs major improvement, ...
I think the key thing is to keep as much raw data as possible, so we can work out the best selection criteria once we have the data in hand. Number of votes, and spread of vote values will be quite informative: again, another reason for having a multi-valued selection.
Perhaps we should register amiencyclopedicornot.com ?
-- Neil
On Sat, 17 Jul 2004 15:13:18 +0100, Neil Harris usenet@tonal.clara.co.uk wrote:
I think the key thing is to keep as much raw data as possible, so we can work out the best selection criteria once we have the data in hand. Number of votes, and spread of vote values will be quite informative: again, another reason for having a multi-valued selection.
If you get down to that level, you could adjust for individual user's voting prefrences. Normalize them somehow. ;)
I believe the KISS principle is applicable here - "keep it simple, stupid". Article versions should be endorsed by simply clicking a star beside the revision in the article history, in the same way as Gmail uses to "star" an email. If we make the selection process to complicated, we'll never get around to endorsing the tens of thousands of articles we aim to have in the finished product.
Anyway, the way I think could work is to have each permitted user able to select only one revision of an article. From that, the total numbers of users endorsing a particular revision could determine which revision is selected in the end. I have created a mock screenshot of how this could work, have a look at:
http://www.ecel.uwa.edu.au/~markryan/pagerank.png
Making the process much more complicated than this would be silly, in my opinion.
~Mark Ryan
Wow, lots of talk about an important subject. Wonderful. What TomK has said about this -- that it requires no technical support, but instead requires defining specific reachable subprojects, drumming up community interest in them, and providing regular updates and 'prereleases' with the status of the whole project -- is absolutely right for the short-term.
Those of you who are eager to work on this, let us pick a suitable subject -- I would vote for World History or Physics, despite the different topics of the currently-underway English Readers -- and start defining the scope of our first validation effort. Feel free to write me privately with other suggestions, if you don't want to spam the list...
For a longer-term scalable solution, I think a fairly simple solution which would improve not only this 1.0 validation but also many other aspects of WP maintenance, is the creation of a page for explicitly managing metadata flags for an article -- "stub", "copyvio", ahd "wrong language" flags as well as review flags for higher-order quality validation. See the metada section of the validation article:
http://meta.wikimedia.org/wiki/Article_validation#Validation_via_extra_metad...
Magnus writes:
For the record, my opionion to these:
- approvals need *not* to be on the same version, but a "disapproval"
could invalidate any prior approvals
- one approval (we can sort out bot articles/extremely long ones later)
- no rating (either it is a good one or not).
I'm not sure what you mean by 'one approval', but I agree with your first and third points -- approvals need not be on the same version (think of them as 'edits' to the article, which have to be actively removed by another editor before they are no longer part of it), and that there should be no rating scale.
Either you think it should be validated or you have a specific (hopefully fixable) set of objections. I'm not eager to create a spectrum of article-quality; certainly not along a single linear scale of Quality; it is unnatural, and as a result invites disappointment and disagreement from users, each of whom will be able to find a pair of articles that s/he considers grossly misordered.
On Sat, 17 Jul 2004 23:07:43 +0800, Mark Ryan ultrablue@gmail.com wrote:
Article versions should be endorsed by simply clicking a star beside the revision in the article history, in the same way as Gmail uses to "star" an email. If we make the selection process to complicated, we'll never get around to endorsing the tens of thousands of articles we aim to have in the finished product.
gmail users everywhere agree... the review process should be very simple. (that said, I think we should prompt reviewers to evaluate an article in certain lights, according to the different qualities we would like in validated articles
Anyway, the way I think could work is to have each permitted user able to select only one revision of an article. From that, the total
As Ant has noted elsewhere, the intent of validation is to get editors to improve articles, not to encourage them to waste time voting on the 'best' version; as such I think a simple objection/response system, where each objection should be responded to by some future editor (and where the articles steadily improve) is a good way to think about it.
http://meta.wikimedia.org/wiki/Article_validation#Validation_via_extra_metad...
sj<<
--- Sj 2.718281828@gmail.com wrote:
Wow, lots of talk about an important subject. Wonderful. What TomK has said about this -- that it requires no technical support, but instead requires defining specific reachable subprojects, drumming up community interest in them, and providing regular updates and 'prereleases' with the status of the whole project -- is absolutely right for the short-term.
Exactly. We should first concentrate on creating progressively longer WikiReaders before we tackle something as large as an entire general encyclopedia (even a full concise one would be daunting).
I would vote for World History or Physics, despite the different topics of the currently-underway English Readers -- and start defining the scope of our first validation effort. Feel free to write me privately with other suggestions, if you don't want to spam the list...
But do we have adequate coverage in that subject area? Also, wouldn't a smaller WikiReader be a better place to start?
For a longer-term scalable solution, I think a fairly simple solution which would improve not only this 1.0 validation but also many other aspects of WP maintenance, is the creation of a page for explicitly managing metadata flags for an article -- "stub", "copyvio", ahd "wrong language" flags as well as review flags for higher-order quality validation. See the metada section of the validation article:
Yes, I think a flag: meta tag would be good for this since that type of information is really not appropriate for category:.
As Ant has noted elsewhere, the intent of validation is to get editors to improve articles, not to encourage them to waste time voting on the 'best' version; as such I think a simple objection/response system, where each objection should be responded to by some future editor (and where the articles steadily improve) is a good way to think about it.
Why not readers then? Simply have a 'Rate this article' link in the toolbox of every article. They could give a 1 to 5 rating across a few different categories (completeness, readability, and accuracy) and be able to give an explanation in a text box. The rating would then be associated with the version that existed when the rating was created.
These data could be part of any validation system by feeding it articles that readers think are pretty good (a minimum number of unique votes would be needed to rate any article). Some other mechanism would then have to take place to finish the validation process.
Just an idea.
-- Daniel Mayer (aka mav)
__________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/
We would need the spell checker to be reactivated and modified so that articles can be checked on their own (rather than giving a huge list of all pages with particular errors in them). I don't fancy copying entire articles into MS Word to check for errors (and people checking articles for correct spelling would be likely to miss many errors). I know the spell checker was a huge resource drain on Wikipedia, but if it is restricted to those permitted to validate articles, it shouldn't be so bad.
~Mark Ryan
Le Sunday 18 July 2004 10:17, Mark Ryan a écrit :
We would need the spell checker to be reactivated and modified so that articles can be checked on their own (rather than giving a huge list of all pages with particular errors in them). I don't fancy copying entire articles into MS Word to check for errors (and people checking articles for correct spelling would be likely to miss many errors). I know the spell checker was a huge resource drain on Wikipedia, but if it is restricted to those permitted to validate articles, it shouldn't be so bad.
No, real paper publications are always ultimately checked by human eyes even for spelling. Automatic spelling is just a tool, but it can't detect every spelling mistakes.
~Mark Ryan
Yann
On Sun, 18 Jul 2004 13:01:50 +0200, Yann Forget yann@forget-me.net wrote:
Le Sunday 18 July 2004 10:17, Mark Ryan a écrit :
We would need the spell checker to be reactivated and modified so that articles can be checked on their own (rather than giving a huge list of all pages with particular errors in them). I don't fancy copying entire articles into MS Word to check for errors (and people checking articles for correct spelling would be likely to miss many errors). I know the spell checker was a huge resource drain on Wikipedia, but if it is restricted to those permitted to validate articles, it shouldn't be so bad.
No, real paper publications are always ultimately checked by human eyes even for spelling. Automatic spelling is just a tool, but it can't detect every spelling mistakes.
~Mark Ryan
Yann
-- http://www.non-violence.org/ | Site collaboratif sur la non-violence http://www.forget-me.net/ | Alternatives sur le Net http://fr.wikipedia.org/ | Encyclopédie libre http://www.forget-me.net/pro/ | Formations et services Linux
Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
I know automatic spell checking is just a tool. But we still have spelling errors being found now, years after they were first inserted into articles. Humans are prone to errors. I know I can proofread an essay of my own over ten times and not notice the most obvious spelling errors. An automatic spell checker would just draw our attention to possibly overlooked errors. How many spelling errors would you find on Britannica?
Le Sunday 18 July 2004 15:08, Mark Ryan a écrit :
I know automatic spell checking is just a tool. But we still have spelling errors being found now, years after they were first inserted into articles.
I am not convince that spell checking tools will improve that. A spelling error squashing party would be more efficient I think.
Humans are prone to errors. I know I can proofread an essay of my own over ten times and not notice the most obvious spelling errors.
That's why WP is a collaborative project.
An automatic spell checker would just draw our attention to possibly overlooked errors.
May be it also depends on the language. Every time I use a spell checking tool in French, I find it just useless, partly because it reports many spelling mistakes where there are none, and can't find others.
How many spelling errors would you find on Britannica?
I don't read Britannica. ;o) Yann
Mark Ryan wrote:
I know automatic spell checking is just a tool. But we still have spelling errors being found now, years after they were first inserted into articles. Humans are prone to errors. I know I can proofread an essay of my own over ten times and not notice the most obvious spelling errors. An automatic spell checker would just draw our attention to possibly overlooked errors. How many spelling errors would you find on Britannica?
Spell checkers didn't exist when the first edition of Britannica came out.
It's always more difficult to find these spelling errors on your own work, but those same errors tend to stand out when you check another person's work. Maybe you should be letting someone else spell check your work.
Ec
Spell checkers didn't exist when the first edition of Britannica came out.
If this is meant as "therefore we don't need spell-checkers" then I don't agree.
Spell-checkers are good not because they make possible something that was impossible before (i.e. given enough time, humans can do a very good job at spell-checking).
They are good because they improve the quality of spell-checking process, make it cheaper (in terms of human labour) and faster.
You can't replace a human spell-checker with computer spell-checker but a computer spell-check will help human spell-checker to do a better job. I'm pretty sure that Britannica editors do use computer spell-checkers those days.
Which is why it would be good to have one easily available for helping spell-check WikiPedia articles.
Krzysztof Kowalczyk | http://blog.kowalczyk.info
Krzysztof Kowalczyk wrote:
Which is why it would be good to have one easily available for helping spell-check WikiPedia articles.
Since this is a general text editing need, it's the job of the browser's text editor widget. In Safari, go to the 'Edit' menu and look under 'Spelling'; for others, see your browser's documentation.
If your browser doesn't include spell checking, see about fixing that.
-- brion vibber (brion @ pobox.com)
Okay, so no spell checker. It was worth a try! :-P
If we are meant to be only be using short stubbish articles for everything (I have heard some people saying using only the first paragraph of articles), then how will we keep this separate from the main articles? Go the same way as monobook.css and have it like [[Christianity/stub]]? There are little conceptual problems that need to be thought through before we jump in head-first into preparing for this.
~Mark Ryan
--- Mark Ryan ultrablue@gmail.com wrote:
Okay, so no spell checker. It was worth a try! :-P
If we are meant to be only be using short stubbish articles for everything (I have heard some people saying using only the first paragraph of articles), then how will we keep this separate from the main articles? Go the same way as monobook.css and have it like [[Christianity/stub]]? There are little conceptual problems that need to be thought through before we jump in head-first into preparing for this.
Section 0 of every article should ideally have a lead section in it that acts as a concise summary of the entire article. Each of those lead sections should then be usable as concise encyclopedia articles in a single volume desk reference (with maybe an overview also thrown in for some subjects). Selection of articles and validation of those sections would still be needed, of course. Thus nothing need be compromised on Wikipedia.
-- mav
__________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/
On 07/19/04 01:53, Daniel Mayer wrote:
--- Mark Ryan ultrablue@gmail.com wrote:
If we are meant to be only be using short stubbish articles for everything (I have heard some people saying using only the first paragraph of articles), then how will we keep this separate from the main articles? Go the same way as monobook.css and have it like [[Christianity/stub]]? There are little conceptual problems that need to be thought through before we jump in head-first into preparing for this.
Section 0 of every article should ideally have a lead section in it that acts as a concise summary of the entire article. Each of those lead sections should then be usable as concise encyclopedia articles in a single volume desk reference (with maybe an overview also thrown in for some subjects). Selection of articles and validation of those sections would still be needed, of course. Thus nothing need be compromised on Wikipedia.
Absolutely. That's why a strict [[news style]] [[inverted pyramid]] intro - first sentence, first paragraph, following paragraphs in order of droppability - is my very favourite article intro style.
Currently, [[Wikipedia:News style]] speaks of it as almost optional. I strongly suggest this status be upgraded, something like: "Although optional, a news style intro is strongly recommended if you want an article to be in Wikipedia 1.0 - many print articles are likely to be only the intro of the web article." Thoughts?
(Note that none of the 1.0 plans so far detract from the live wiki itself, and in fact would increase both its coverage and quality in useful ways.)
- d.
On 07/20/04 00:22, David Gerard wrote:
Currently, [[Wikipedia:News style]] speaks of it as almost optional. I strongly suggest this status be upgraded, something like: "Although optional, a news style intro is strongly recommended if you want an article to be in Wikipedia 1.0 - many print articles are likely to be only the intro of the web article." Thoughts?
I've been reading a huge pile of stuff on Wikipedia 1.0 from the past year. There have been several mentions of the idea, much support and little objection. So I've boldly edited [[Wikipedia:News style]] and [[Wikipedia:Summary style]] to call it a consensus recommendation, because it does seem to be one.
- d.
I definitely agree with making things inverted pyramid, many of my edits in have been exactly that - moving the most important facts into the first graf.
-Andrew (User:Fuzheado)
On Tue, 20 Jul 2004 01:04:22 +0000, David Gerard fun@thingy.apana.org.au wrote:
On 07/20/04 00:22, David Gerard wrote:
Currently, [[Wikipedia:News style]] speaks of it as almost optional. I strongly suggest this status be upgraded, something like: "Although optional, a news style intro is strongly recommended if you want an article to be in Wikipedia 1.0 - many print articles are likely to be only the intro of the web article." Thoughts?
I've been reading a huge pile of stuff on Wikipedia 1.0 from the past year. There have been several mentions of the idea, much support and little objection. So I've boldly edited [[Wikipedia:News style]] and [[Wikipedia:Summary style]] to call it a consensus recommendation, because it does seem to be one.
- d.
Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
David Gerard wrote:
On 07/19/04 01:53, Daniel Mayer wrote:
--- Mark Ryan ultrablue@gmail.com wrote:
If we are meant to be only be using short stubbish articles for everything (I have heard some people saying using only the first paragraph of articles), then how will we keep this separate from the main articles? Go the same way as monobook.css and have it like [[Christianity/stub]]? There are little conceptual problems that need to be thought through before we jump in head-first into preparing for this.
Section 0 of every article should ideally have a lead section in it that acts as a concise summary of the entire article. Each of those lead sections should then be usable as concise encyclopedia articles in a single volume desk reference (with maybe an overview also thrown in for some subjects). Selection of articles and validation of those sections would still be needed, of course. Thus nothing need be compromised on Wikipedia.
Absolutely. That's why a strict [[news style]] [[inverted pyramid]] intro - first sentence, first paragraph, following paragraphs in order of droppability
- is my very favourite article intro style.
Currently, [[Wikipedia:News style]] speaks of it as almost optional. I strongly suggest this status be upgraded, something like: "Although optional, a news style intro is strongly recommended if you want an article to be in Wikipedia 1.0 - many print articles are likely to be only the intro of the web article." Thoughts?
(Note that none of the 1.0 plans so far detract from the live wiki itself, and in fact would increase both its coverage and quality in useful ways.)
Although there is much merit to having the initial section of an article give a general overview of the topic. I don't think that the application of "news style should extend any further than that. Wikipedia is not a newspaper. Being able to drop paragraphs at the end of an article to fit the available space is fine for newspapers who have short daily deadlines to meet. The weeklies have more freedom on this and monthlies and quarterlies even more.
A biographical article needs to present the person's life in a chronological structure. Many famous people had some of their most significant events at the end of their lives. What would a biography of Lincoln or Kennedy be like if we had to cut the story of their assassination as a means of making those articles shorter?.
I can see that the desire to have a large number of articles is driving the move the have severable opening stubs.
The important question comes down to is it better to have a large number of short articles, or a much smaller number of comprehensive, well-written and thoughtful articles.
When it is finally published, the hype will have preceded the event, and created high expectations. Which would be a better review? 1. The new paper Wikipedia is a collection of short articles. The material appears very accurate, but any person who browses the net could have found all this very easily. Why did they bother?
or
2. The new paper Wikipedia is a series of interesting and very informative article. Interspersed are a number of shorter articles with a promise that these subjects will receive more thorough treatment in the future. We look forward to those future editions.
Ec
Ec, I think most will agree that strict adherence to inverted pyramid is not necessary. We don't need for graf (n) to always be less important than graf (n-1). However, hopefully this shows what we should try to strive for, from the [[Pat Tillman]] article:
http://en.wikipedia.org/w/wiki.phtml?title=Pat_Tillman&diff=3313964&...
Before the edit, the most important part of his life story was in the last paragraph.
-Andrew (User:Fuzheado)
On Tue, 20 Jul 2004 00:04:19 -0700, Ray Saintonge saintonge@telus.net wrote:
David Gerard wrote:
On 07/19/04 01:53, Daniel Mayer wrote:
--- Mark Ryan ultrablue@gmail.com wrote:
If we are meant to be only be using short stubbish articles for everything (I have heard some people saying using only the first paragraph of articles), then how will we keep this separate from the main articles? Go the same way as monobook.css and have it like [[Christianity/stub]]? There are little conceptual problems that need to be thought through before we jump in head-first into preparing for this.
Section 0 of every article should ideally have a lead section in it that acts as a concise summary of the entire article. Each of those lead sections should then be usable as concise encyclopedia articles in a single volume desk reference (with maybe an overview also thrown in for some subjects). Selection of articles and validation of those sections would still be needed, of course. Thus nothing need be compromised on Wikipedia.
Absolutely. That's why a strict [[news style]] [[inverted pyramid]] intro - first sentence, first paragraph, following paragraphs in order of droppability
- is my very favourite article intro style.
Currently, [[Wikipedia:News style]] speaks of it as almost optional. I strongly suggest this status be upgraded, something like: "Although optional, a news style intro is strongly recommended if you want an article to be in Wikipedia 1.0 - many print articles are likely to be only the intro of the web article." Thoughts?
(Note that none of the 1.0 plans so far detract from the live wiki itself, and in fact would increase both its coverage and quality in useful ways.)
Although there is much merit to having the initial section of an article give a general overview of the topic. I don't think that the application of "news style should extend any further than that. Wikipedia is not a newspaper. Being able to drop paragraphs at the end of an article to fit the available space is fine for newspapers who have short daily deadlines to meet. The weeklies have more freedom on this and monthlies and quarterlies even more.
A biographical article needs to present the person's life in a chronological structure. Many famous people had some of their most significant events at the end of their lives. What would a biography of Lincoln or Kennedy be like if we had to cut the story of their assassination as a means of making those articles shorter?.
I can see that the desire to have a large number of articles is driving the move the have severable opening stubs.
The important question comes down to is it better to have a large number of short articles, or a much smaller number of comprehensive, well-written and thoughtful articles.
When it is finally published, the hype will have preceded the event, and created high expectations. Which would be a better review? 1. The new paper Wikipedia is a collection of short articles. The material appears very accurate, but any person who browses the net could have found all this very easily. Why did they bother?
or
2. The new paper Wikipedia is a series of interesting and veryinformative article. Interspersed are a number of shorter articles with a promise that these subjects will receive more thorough treatment in the future. We look forward to those future editions.
Ec
Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
--- Ray Saintonge saintonge@telus.net wrote:
Although there is much merit to having the initial section of an article give a general overview of the topic. I don't think that the application of "news style should extend any further than that. Wikipedia is not a newspaper. Being able to drop paragraphs at the end of an article to fit the available space is fine for newspapers who have short daily deadlines to meet. The weeklies have more freedom on this and monthlies and quarterlies even more.
A biographical article needs to present the person's life in a chronological structure. Many famous people had some of their most significant events at the end of their lives. What would a biography of Lincoln or Kennedy be like if we had to cut the story of their assassination as a means of making those articles shorter?.
That is exactly why I support Summary Style instead of News Style. The "dropability" part does not apply to what we are doing and strictly speaking News Style only provides for lead sentences, not lead sections.
See http://en.wikipedia.org/wiki/Wikipedia:Summary_style
Summary Style is somewhat similar in spirit to News Style, except it tries to apply the concept to Wikipedia, which is most certainly not a newspaper. It aims to not overwhelm readers with too much info up front and tries to offer summaries under prominent "Main article"-type links in sections. That way we serve several different types of users; *those that want a quick summary of what the topic is about (lead section), *those that want a basic summary (a set of several paragraph long sections - subsectioning can increase the number of paras), *and those that want to go into more detail ('Main article' links to articles which cover a sub-topic summarized in a section).
But articles *should not* start out like this. Summary Style is more of a set of guidelines on how to split long articles (>40-50KB) into a set of daughters. Each of those daughters could eventually become large enough to bud out articles of its own. And so on - not unlike cellular division.
Also, most good lead sections should be usable as concise encyclopedia articles in their own right. Some more expansive topics, such as major wars, will also need to have overviews, however. Overviews should have important info not contained in or barely mentioned in the lead section. Together these lead sections and overviews could be used almost directly in a desk reference concise version of Wikipedia.
This division of content also makes it possible to create many different kinds of topic-based encyclopedias for print/DVD/CD; A general one would only have survey articles while a specific topic encyclopedia would have all the survey and daughter articles in its topic area. Creating a meta tagging system would help facilitate this by automating what goes where (this is a bit beyond the purpose of categories, IMO, but they *could* be used for this if needed).
The important question comes down to is it better to have a large number of short articles, or a much smaller number of comprehensive, well-written and thoughtful articles.
In terms of content, not really articles, we can and should have both. This can be done by splitting long articles and leaving a good-sized summary of that article in a section of a survey article on the topic.
-- Daniel Mayer (aka mav)
__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
Daniel Mayer (maveric149@yahoo.com) [040721 05:59]:
That is exactly why I support Summary Style instead of News Style. The "dropability" part does not apply to what we are doing and strictly speaking News Style only provides for lead sentences, not lead sections. See http://en.wikipedia.org/wiki/Wikipedia:Summary_style
You are of course correct. (Which is why both Wikipedia:News style and Wikipedia:summary syle now both say: "For the planned paper Wikipedia 1.0, one consensus recommendation is that the paper version of articles will be the lead section of the web version. A concise intro satisfying both summary style and news style that would work stand-alone is ideal." Reword as you wish.)
I suppose I'm really pushing for good standalone intros, and news or summary style is a way to get there.
- d.
Mark Ryan wrote:
We would need the spell checker to be reactivated and modified so that articles can be checked on their own (rather than giving a huge list of all pages with particular errors in them). I don't fancy copying entire articles into MS Word to check for errors (and people checking articles for correct spelling would be likely to miss many errors). I know the spell checker was a huge resource drain on Wikipedia, but if it is restricted to those permitted to validate articles, it shouldn't be so bad.
We would need to feel confident that the spell checker respected national variations such as labor/labour while maintaing consistent usage within an individual article.
Spell checkers also create false security. They would never catch the wrong use of there/their for example. Human checking will still be essential.
Ec
On Sat, 17 Jul 2004 21:35:15 -0700 (PDT), Daniel Mayer maveric149@yahoo.com wrote:
--- Sj 2.718281828@gmail.com wrote:
Wow, lots of talk about an important subject. Wonderful.
< > What TomK has said about this ... is just right for the short-term.
Exactly. We should first concentrate on creating progressively longer WikiReaders before we tackle something as large as an entire general encyclopedia (even a full concise one would be daunting).
I have to say, I don't like the name WikiReader, and hope we stop using it as a general term. (-: All of the wiki is meant to be read. I will just write "subpedia" and hope you know what I mean.
I would vote for World History or Physics, despite the different topics of
But do we have adequate coverage in that subject area?
Well, we certainly have decent coverage for some subsets of these subjects. I agree that we should start smaller; perhaps American History and Mechanics? I think we could manage either of those. (One of the skills we need to develop is the ability to cover a subject area or any size in 100 pages; the broader the subject area, the higher-level the produced content. WP right now has very few good overview articles, as is evidenced by the scattershot quality of top-level topics linked directly from the main page -- but we do have the editor expertise to fix that, as evidenced by our deep articles.)
For a longer-term scalable solution, I think a fairly simple solution which would improve not only this 1.0 validation but also many other aspects of WP maintenance, is the creation of a page for explicitly managing metadata flags for an article -- "stub", "copyvio", ahd "wrong language" flags as well as review flags for higher-order quality validation. See the metada section of the validation article:
Yes, I think a flag: meta tag would be good for this since that type of information is really not appropriate for category:.
Or a longer metadata section in the db (which might be more scalable).
As Ant has noted elsewhere, the intent of validation is to get editors to improve articles, not to encourage them to waste time voting on the 'best' version; as such I think a simple objection/response system, where
Why not readers then? Simply have a 'Rate this article' link in the toolbox of every article. They could give a 1 to 5 rating across a few different categories (completeness, readability, and accuracy) and be able to give an explanation in a text box. The rating would then be associated with the version
I could be convinced about this, if it were a loose and unbinding measure of reader responses. I do think that there should be a more detailed (one explanation-box per category/facet; more options) and less rated review function, which would be more closely bound to the validation process.
readers think are pretty good (a minimum number of unique votes would be needed to rate any article). Some other mechanism would then have to take place to finish the validation process.
Could certainly work as a low-barrier-to-input source of information. Expecially if the result of such votes were not made public save for articles with hundreds of them...
_sj_
Sj wrote:
I would vote for World History or Physics, despite the different topics of
But do we have adequate coverage in that subject area?
Well, we certainly have decent coverage for some subsets of these subjects. I agree that we should start smaller; perhaps American History and Mechanics? I think we could manage either of those. (One of the skills we need to develop is the ability to cover a subject area or any size in 100 pages; the broader the subject area, the higher-level the produced content. WP right now has very few good overview articles, as is evidenced by the scattershot quality of top-level topics linked directly from the main page -- but we do have the editor expertise to fix that, as evidenced by our deep articles.)
Interesting that you should raise this. I had already asked myself how could I go about choosing articles for 1.0, and the first thing that came to mind was the topic overview articles. Anything else would follow from there. If any group of articles should be priorized for being brought up to editorial standards it is these. They would be the lead articles for each section of a paper product. Nothing binds us to the strict alphabetical order of many traditional encyclopedias.
As Ant has noted elsewhere, the intent of validation is to get editors to improve articles, not to encourage them to waste time voting on the 'best' version; as such I think a simple objection/response system, where
Why not readers then? Simply have a 'Rate this article' link in the toolbox of every article. They could give a 1 to 5 rating across a few different categories (completeness, readability, and accuracy) and be able to give an explanation in a text box. The rating would then be associated with the version
I could be convinced about this, if it were a loose and unbinding measure of reader responses. I do think that there should be a more detailed (one explanation-box per category/facet; more options) and less rated review function, which would be more closely bound to the validation process.
Having these ratings kept loose is essential if we don't want a whole bureaucracy built up around them. (I do find a 10-pont rating scale more visually menaingful.) Security against a person casting multiple votes needs to be kept to a minimum. We certainly don't need to keep track of every vote that a person has cast. I would even go so far as to say that a person may cast a new vote after *every* edit, but I would attach more weight to votes cast since the last edit. An algorithm can certainly be devised to calculate a rating based on the available votes. When surveyed on many topics people do have a tendency to rate things higher than average. That can be normalized by looking at votes across all topics, and taking the raw average to be equivalent to 5.0 on a ten point scale.
The idea that validation is done to elicit improvement of articles is important. Many educators to-day are questioning the role of tests and examinations in schools. For them we should be "testing for learning" rather than "testing of learning"; this conforms well with this idea of article validation.
On Saturday, July 17, 2004, at 08:48 AM, Neil Harris wrote:
Users should only have the yes/no option, IMO, since including or excluding an article is an all-or-nothing proposition. Combining multiple users' ratings into a more fine-grained number could be handy, though, showing whether the approval is controversial at a glance. The details of this rating system will no doubt be the subject of endless bickering, which I look forward to seeing the end result of. :)
I disagree. I believe that most users would prefer the ability to express shades of opinion. A numerical rating allows more information to be gathered; users who want to assert an all-or-nothing opinion can still vote 0 or 10. I would then suggest feeding the results to a robust estimator (using the median would be a good first hack) to prodice a fine-grained estimate. It would also be useful to have a robust spread measure to detect contentious articles.
By having a wide range of fine-grained estimates, and perhaps adding in factors for linkage, we can then prune the encyclopedia to any desired size by adjusting the threshold for inclusion.
-- Neil
I support the yes/no only option. I think that some users will tend to be more generous or scathing in their ratings than others; not everyone will assign the same number to the same degree of approval or disapproval. I think we'll get truer results if individuals have to vote yes/no, and then those results are aggregated.
On the other hand, if we have to have numeric scaling, I would suggest a scale of 0 to 5 instead of 0 to 10 as a compromise. This would let people give more fine grained feedback while hopefully reducing the variation in scores based on the vagaries of individuals' emotions, namely how strongly they feel for or against an article.
-- Wesley
Hi Magnus
See also a discussion about that : http://meta.wikimedia.org/wiki/Article_validation
I would be very happy to see this topic being in discussion again ;-)
Magnus Manske wrote:
Since Jimbo has announced the "move to 1.0" some month ago, not much has happened. Meanwhile, the tone of the press concerning wikipedia seems to be slowly drifting from "interesting, lots of potential" to "source of unreliable information". There's the "single printed volume" deal waiting in the wings, and Mandrake Linux would be interested in a wikipedia-on-DVD.
Since there seems to be long-standing consensus that wikipedia needs some form of review (as an additional option, *not* as a replacement for the wiki way!), I would very much like the discussion about the "how" to start again, and to reach a clonclusion this time, for a change :-)
It seems to me that most of you would agree to a method similar to this:
- A (logged-in) user can approve a single version of an article.
- At least two approvals are needed for the "wikipedia seal of approval" :-)
Now, the rapid change of wikipedia articles unveils this problem:
- Does the second approval need to be for the *same version* as the
first, or can it be for a later one, which then gets the "seal of approval"?
Also, given the different goals of an approval system, should there be
- one approval only
- one approval for "web version", one for "CD-ROM version", one for
"printed version (single volume)", one for "printed version (30 voulmes)", etc.
Also, should there be
- yes/no approval(s)
- or rather a rating (0-9 or something)
For the record, my opionion to these:
- approvals need *not* to be on the same version, but a "disapproval"
could invalidate any prior approvals
- one approval (we can sort out bot articles/extremely long ones later)
- no rating (either it is a good one or not).
Magnus
I have saved this entire thread and intend to go through it post by post, with pen and paper beside me, taking extensive notes, in an effort to generate something like a consensus from what different people have said. In addition, for points that seem controversial or unsettled, I will try to generate a middle-of-the-road proposal of my own (in search of consensus), and then I'll post the whole thing here and on meta for feedback.
After that, I'll go through *that* discussion post by post and generate a final draft proposal, and then I propose that we hold an en-wide vote. (en-wide, but I think anyone should be able to vote, it's just that the process decisions that we make in this case will not necessarily be binding on future drives to 1.0 in other languages, nor on future drives to 2.0 in en or whatever.)
I feel that it's necessary here for me to provide some leadership and say "THIS is the exact proposal." Unless I do that and submit it to a ratification vote so that we can get general legitimacy and acceptance that this is what we should do, we will continue to not-quite move forward.
--Jimbo
On 07/21/04 21:34, Jimmy (Jimbo) Wales wrote:
I have saved this entire thread and intend to go through it post by post, with pen and paper beside me, taking extensive notes, in an effort to generate something like a consensus from what different people have said. In addition, for points that seem controversial or unsettled, I will try to generate a middle-of-the-road proposal of my own (in search of consensus), and then I'll post the whole thing here and on meta for feedback.
Please wait a few days! I've been thinking of little else for the past few days and want to discuss ideas more here first.
One important point that has been I think missed here - when we talk about 1.0 here, we're talking about the paper version, yes? I note that your page talks about a CD release as well. But the present push is because we have an actual paper publisher in the wings? I ask because I've been thinking in terms of a single-volume paper concise Wikipedia, not a CD-ROM, which could probably have all Adequate Prose on it.
I feel that it's necessary here for me to provide some leadership and say "THIS is the exact proposal." Unless I do that and submit it to a ratification vote so that we can get general legitimacy and acceptance that this is what we should do, we will continue to not-quite move forward.
Indeed ...
- d.
wikipedia-l@lists.wikimedia.org