This is in response to the somewhat silly English-language press we've had lately. I'll be sending copies of this out to the sources of recent articles on the subject that got it precisely backwards.
The following is, I understand, technically accurate, based on text from Amgine, Phillipp Birkin (de:wp), Jimbo and Mathias Schindler (I think), and comcom discussions (press relations being part of that job). Corrections welcomed - you have about five minutes.
(and geni, I expect you to ask how this makes the new patrollers' jobs easier - by having what's effectively a feed of new-editor and anonymous edits, is what I was thinking of.)
- d.
"Approved" versions on Wikipedia FAQ
* What is changing?
We want to open up editing without damaging the reader's experience.
We want to be more wiki and let editors edit freely, which is where all the good things come from. At present a small percentage of articles (a few hundred out of 1.5 million on the English language Wikipedia, http://en.wikipedia.org/) are locked or partially locked from editing. We want to open these up. But Wikipedia is a top 20 website (Alexa ratings, no. 17 on 3 month average; no. 15 on 30 August 2006 - http://www.alexa.com/), so we must keep it good for the readers.
The new feature will mean that edits from new or anonymous editors will be delayed before being shown to readers - they will see a 'flagged OK' version by default, with a link to the live version. The idea is to enhance the *reading* experience, and free us to enhance the *editing* experience. If vandalism can't be seen by the general public, there will be less motivation to vandalise.
Anonymous or new-editor edits will need to be approved by a logged-in editor. Of the thousands of editors on the large Wikipedias, many concentrate on checking revisions and dealing with odd changes and vandalism - this will assist their work and we do not expect new delays.
We are also considering a related feature to flag particular versions of articles as being of high quality. This is to a different end: a high-quality finished product. This will likely be tested first on the German language Wikipedia (http://de.wikipedia.org/), which has already had three stable editions released on CD and DVD, which have sold quite well. If the feature works there, it may be used on other language Wikipedias.
These features are not finished, so we don't have a lot of fine detail as to how it will all work as yet. But we hope this change will allow us to do things such as open up the George W. Bush article or even the front page itself to full unrestricted editing.
* When was this proposed?
Jimmy Wales asked for a time-delay feature for casual readers in late 2004; after very fast editing on the Indian Ocean tsunami produced a very high-quality article (http://en.wikipedia.org/wiki/2004_Indian_Ocean_earthquake) very quickly, but with some highly visible vandalism; we've hotly discussed how to achieve stable high-quality editions of Wikipedia since almost the start of the project, in 2001.
On 30/08/06, David Gerard dgerard@gmail.com wrote:
The new feature will mean that edits from new or anonymous editors will be delayed before being shown to readers - they will see a 'flagged OK' version by default, with a link to the live version. The idea is to enhance the *reading* experience, and free us to enhance the *editing* experience. If vandalism can't be seen by the general public, there will be less motivation to vandalise.
You might want to clarify what "new and anonymous" means - is this going to be a time-lapse job like sprotection, or a manually enabled flag? Because people may well assume the latter, and SFAIK that isn't being considered...
(in en.wp normal parlance, "new and anonymous" means first-four-days, so I'm guessing it's intended to be something like that)
David Gerard schrieb am 30.08.2006 16:09:
At present a small percentage of articles (a few hundred out of 1.5 million on the English language Wikipedia, http://en.wikipedia.org/) are locked or partially locked from editing.
FYI: http://tools.wikimedia.de/~avatar/protected.php?wiki=en
The approved version feature won't help open up protected pages (but semi-protected).
These features are not finished, so we don't have a lot of fine detail as to how it will all work as yet. But we hope this change will allow us to do things such as open up the George W. Bush article or even the front page itself to full unrestricted editing.
Most german newspapers/newsmagazines don't get, that most of the german frontpage IS open (pictures and text via templates). This is a bit strange, because they also write about penises on it...
Bye, avatar.
David Gerard wrote:
Anonymous or new-editor edits will need to be approved by a logged-in editor.
I am sure that no matter what some percentage of the people reading this will misinterpret it, but it might be a bit clearer to _start_ with the word "edits" and explain what "approval" entails; "The edits of anonymous or newly-signed-up editors will need to be approved by an editor who's already been on Wikipedia for a while before they'll be shown to other readers."
Jimmy Wales asked for a time-delay feature for casual readers in late 2004; after very fast editing on the Indian Ocean tsunami produced a very high-quality article (http://en.wikipedia.org/wiki/2004_Indian_Ocean_earthquake) very quickly, but with some highly visible vandalism; we've hotly discussed how to achieve stable high-quality editions of Wikipedia since almost the start of the project, in 2001.
I like semicolons but there are too many in this paragraph. The first should be a comma, the second a period IMO. And the last comma shouldn't be there at all.
Does this make the 5 minute cut? :)
I think the premise of the FAQ is off in its current form. I am worried by the "we" part, meaning the mythical monolithic Wikipedia community. (ie. Why not make this an opportunity to show that Wikipedias have their distinct culture and are at different stages of development?)
I think the announcement should make clear: - There has always been a desire for a better reader experience - The larger Wikipedia communities have turned their attention from growth to quality - The German Wikipedia has initiated an experiment with a "nonvandalized" and "checked" versions (nb: terminology may need to be tweaked) - This "potentially" may allow for a mechanism other than blunt protection for preventing vandalism - The greater Wikipedia community hopes to learn from this pilot project - The English and other Wikipedias, with their own norms and cultures, may or may not adopt the German initiatives
PS: Would be nice to have a pointer to a meta page (if it exists) describing the German initiative. If I had not attended the Wikimania 2006 summit on the top floor of Pound Hall with Danny, Kurt, G. Maxwell, Jimmy, Raul654, Kelly Martin, et al, I would not have known these things. And I'm a bit concerned we're neglecting to use the wiki to share this knowledge.
-Andrew (User:Fuzheado)
On 8/30/06, David Gerard dgerard@gmail.com wrote:
This is in response to the somewhat silly English-language press we've had lately. I'll be sending copies of this out to the sources of recent articles on the subject that got it precisely backwards.
The following is, I understand, technically accurate, based on text from Amgine, Phillipp Birkin (de:wp), Jimbo and Mathias Schindler (I think), and comcom discussions (press relations being part of that job). Corrections welcomed - you have about five minutes.
(and geni, I expect you to ask how this makes the new patrollers' jobs easier - by having what's effectively a feed of new-editor and anonymous edits, is what I was thinking of.)
- d.
"Approved" versions on Wikipedia FAQ
- What is changing?
We want to open up editing without damaging the reader's experience.
We want to be more wiki and let editors edit freely, which is where all the good things come from. At present a small percentage of articles (a few hundred out of 1.5 million on the English language Wikipedia, http://en.wikipedia.org/) are locked or partially locked from editing. We want to open these up. But Wikipedia is a top 20 website (Alexa ratings, no. 17 on 3 month average; no. 15 on 30 August 2006 - http://www.alexa.com/), so we must keep it good for the readers.
The new feature will mean that edits from new or anonymous editors will be delayed before being shown to readers - they will see a 'flagged OK' version by default, with a link to the live version. The idea is to enhance the *reading* experience, and free us to enhance the *editing* experience. If vandalism can't be seen by the general public, there will be less motivation to vandalise.
Anonymous or new-editor edits will need to be approved by a logged-in editor. Of the thousands of editors on the large Wikipedias, many concentrate on checking revisions and dealing with odd changes and vandalism - this will assist their work and we do not expect new delays.
We are also considering a related feature to flag particular versions of articles as being of high quality. This is to a different end: a high-quality finished product. This will likely be tested first on the German language Wikipedia (http://de.wikipedia.org/), which has already had three stable editions released on CD and DVD, which have sold quite well. If the feature works there, it may be used on other language Wikipedias.
These features are not finished, so we don't have a lot of fine detail as to how it will all work as yet. But we hope this change will allow us to do things such as open up the George W. Bush article or even the front page itself to full unrestricted editing.
- When was this proposed?
Jimmy Wales asked for a time-delay feature for casual readers in late 2004; after very fast editing on the Indian Ocean tsunami produced a very high-quality article (http://en.wikipedia.org/wiki/2004_Indian_Ocean_earthquake) very quickly, but with some highly visible vandalism; we've hotly discussed how to achieve stable high-quality editions of Wikipedia since almost the start of the project, in 2001. _______________________________________________ Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
On 30/08/06, Andrew Lih andrew.lih@gmail.com wrote:
Does this make the 5 minute cut? :)
I sent it to a couple of places just now, including Bill Thompson (BBC) who sent a very nice reply. So not quite ;-)
I've put it on Meta. Please hack away at will, and move somewhere better if sensible:
http://meta.wikimedia.org/wiki/2006_proposed_approval_for_anonymous_edits
(that's a terrible article name. You can tell I've been writing on the work wiki too much. Even if it is MoinMoin.)
I think the premise of the FAQ is off in its current form. I am worried by the "we" part, meaning the mythical monolithic Wikipedia community. (ie. Why not make this an opportunity to show that Wikipedias have their distinct culture and are at different stages of development?)
In this case because it was an immediate response to the Bill Thompson and Platinax articles. I was trying very hard to keep it *really simple* and clear because journalists don't have time to read press releases closely - they have to be able to get your message by skimming.
There's huge piles of detail I left out ...
I think the announcement should make clear:
- There has always been a desire for a better reader experience
- The larger Wikipedia communities have turned their attention from
growth to quality
yep, these are important.
- The German Wikipedia has initiated an experiment with a
"nonvandalized" and "checked" versions (nb: terminology may need to be tweaked)
Yeah. I didn't give them names, but I hope I got this idea across.
- This "potentially" may allow for a mechanism other than blunt
protection for preventing vandalism
Jimbo wanted to emphasise "this is to make things wide-open" because the press coverage had been "OH NOEZ WIKI IS CLOSED", so this probably isn't as neutral as it might ideally be.
- The greater Wikipedia community hopes to learn from this pilot project
I think I've got that in. Platinax emailed me to clarify and I said that it's quite possible it might go badly and we cancel the idea - but we're giving it a go.
- The English and other Wikipedias, with their own norms and cultures,
may or may not adopt the German initiatives
I left out that bit, but I think I have in that we are trying.
PS: Would be nice to have a pointer to a meta page (if it exists) describing the German initiative. If I had not attended the Wikimania 2006 summit on the top floor of Pound Hall with Danny, Kurt, G. Maxwell, Jimmy, Raul654, Kelly Martin, et al, I would not have known these things. And I'm a bit concerned we're neglecting to use the wiki to share this knowledge.
It wasn't a matter of fuss until the press grabbed it and ran with it, conclusively describing the Wikipedia elephant to the public as a rope holding together walls in a fan shape at the top of several trees with a spear and thirty snakes sticking out the side [*]. The feature is probably still way too premature to warrant this attention ... but it's got it anyway.
- d.
[*] http://www.wordinfo.info/words/index/info/view_unit/1/?letter=B&spage=3
David, thanks for the thoughtful evaluation and creating the meta page. Glad to see comcom addressing these things with rapid speed in helping to flesh out the specifics of these initiatives.
-Andrew (User:Fuzheado)
On 8/30/06, David Gerard dgerard@gmail.com wrote:
On 30/08/06, Andrew Lih andrew.lih@gmail.com wrote:
Does this make the 5 minute cut? :)
I sent it to a couple of places just now, including Bill Thompson (BBC) who sent a very nice reply. So not quite ;-)
I've put it on Meta. Please hack away at will, and move somewhere better if sensible:
http://meta.wikimedia.org/wiki/2006_proposed_approval_for_anonymous_edits
(that's a terrible article name. You can tell I've been writing on the work wiki too much. Even if it is MoinMoin.)
I think the premise of the FAQ is off in its current form. I am worried by the "we" part, meaning the mythical monolithic Wikipedia community. (ie. Why not make this an opportunity to show that Wikipedias have their distinct culture and are at different stages of development?)
In this case because it was an immediate response to the Bill Thompson and Platinax articles. I was trying very hard to keep it *really simple* and clear because journalists don't have time to read press releases closely - they have to be able to get your message by skimming.
There's huge piles of detail I left out ...
I think the announcement should make clear:
- There has always been a desire for a better reader experience
- The larger Wikipedia communities have turned their attention from
growth to quality
yep, these are important.
- The German Wikipedia has initiated an experiment with a
"nonvandalized" and "checked" versions (nb: terminology may need to be tweaked)
Yeah. I didn't give them names, but I hope I got this idea across.
- This "potentially" may allow for a mechanism other than blunt
protection for preventing vandalism
Jimbo wanted to emphasise "this is to make things wide-open" because the press coverage had been "OH NOEZ WIKI IS CLOSED", so this probably isn't as neutral as it might ideally be.
- The greater Wikipedia community hopes to learn from this pilot project
I think I've got that in. Platinax emailed me to clarify and I said that it's quite possible it might go badly and we cancel the idea - but we're giving it a go.
- The English and other Wikipedias, with their own norms and cultures,
may or may not adopt the German initiatives
I left out that bit, but I think I have in that we are trying.
PS: Would be nice to have a pointer to a meta page (if it exists) describing the German initiative. If I had not attended the Wikimania 2006 summit on the top floor of Pound Hall with Danny, Kurt, G. Maxwell, Jimmy, Raul654, Kelly Martin, et al, I would not have known these things. And I'm a bit concerned we're neglecting to use the wiki to share this knowledge.
It wasn't a matter of fuss until the press grabbed it and ran with it, conclusively describing the Wikipedia elephant to the public as a rope holding together walls in a fan shape at the top of several trees with a spear and thirty snakes sticking out the side [*]. The feature is probably still way too premature to warrant this attention ... but it's got it anyway.
- d.
[*] http://www.wordinfo.info/words/index/info/view_unit/1/?letter=B&spage=3 _______________________________________________ Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
Yes, its certainly worth clarifying such an important issue. I'm personally looking forward to the feature; Wikipedia is blocked at various educational institutions in my area because of the unreliable information. However, four days seems a bit ineffective, although I suppose manual validation would be inefficent and tedious. Is it possible to extend this to, say, four days without vandalism warnings but with at least one edit?
On 8/31/06, Andrew Lih andrew.lih@gmail.com wrote:
David, thanks for the thoughtful evaluation and creating the meta page. Glad to see comcom addressing these things with rapid speed in helping to flesh out the specifics of these initiatives.
-Andrew (User:Fuzheado)
Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
I recently got into a minor squable that started with another example of what I refer to as "drive-by tagging". Basically someone comes by an article and inserts a whole bunch of tags without any comment. Some of these may be valid, others less so, but very often its impossible to know one way or the other without the original "tagger" pointing out the problems.
For instance, consider this example I came across recently: Mirror Fusion Test Facility. The "tagger" inserted a needs cats and needs wikification. The cats one was entirely valid and I added one, but I can't for the life of me even imagine what needs additional wikification. It seems to follow the style guide perfectly. I wrote to the tagger, but he responded saying "by following the link within the tag for all you need to know about wikifying an article", which is a non-answer.
I would like to hear any comments you all may have on this topic. Is it OK to simply remove vague tags if the article in question does not appear to have a problem related to the tag and there is no comment? I ask because, as I noted, the last time I removed tags the tagger then stamped the article with a PROD, their argument being that removing tags is PRODable.
Maury
On 30/08/06, Maury Markowitz maury_markowitz@hotmail.com wrote:
I would like to hear any comments you all may have on this topic. Is it OK to simply remove vague tags if the article in question does not appear to have a problem related to the tag and there is no comment? I ask because, as I noted, the last time I removed tags the tagger then stamped the article with a PROD, their argument being that removing tags is PRODable.
It's possible you're dealing with a procedure-bound idiot. Delete the tags saying "see talk page" and ask on the talk page why not. Procedure then says discuss it there.
- d.
Maury Markowitz wrote:
I recently got into a minor squable that started with another example of what I refer to as "drive-by tagging". Basically someone comes by an article and inserts a whole bunch of tags without any comment. Some of these may be valid, others less so, but very often its impossible to know one way or the other without the original "tagger" pointing out the problems.
For instance, consider this example I came across recently: Mirror Fusion Test Facility. The "tagger" inserted a needs cats and needs wikification. The cats one was entirely valid and I added one, but I can't for the life of me even imagine what needs additional wikification. It seems to follow the style guide perfectly. I wrote to the tagger, but he responded saying "by following the link within the tag for all you need to know about wikifying an article", which is a non-answer.
I would like to hear any comments you all may have on this topic. Is it OK to simply remove vague tags if the article in question does not appear to have a problem related to the tag and there is no comment? I ask because, as I noted, the last time I removed tags the tagger then stamped the article with a PROD, their argument being that removing tags is PRODable.
The response to that may simply be "So fix it!" The article says what it says with or without categories or Wikification. Neither are essential. Since the items that need additional Wikification are the ones that he doesn't understand he is in the best position to do it. ... but then it might not be practical to Wikify EVERY word. :-)
Ec
Maury Markowitz wrote:
I recently got into a minor squable that started with another example of what I refer to as "drive-by tagging". Basically someone comes by an article and inserts a whole bunch of tags without any comment. Some of these may be valid, others less so, but very often its impossible to know one way or the other without the original "tagger" pointing out the problems.
For instance, consider this example I came across recently: Mirror Fusion Test Facility. The "tagger" inserted a needs cats and needs wikification. The cats one was entirely valid and I added one, but I can't for the life of me even imagine what needs additional wikification. It seems to follow the style guide perfectly. I wrote to the tagger, but he responded saying "by following the link within the tag for all you need to know about wikifying an article", which is a non-answer.
I would like to hear any comments you all may have on this topic. Is it OK to simply remove vague tags if the article in question does not appear to have a problem related to the tag and there is no comment? I ask because, as I noted, the last time I removed tags the tagger then stamped the article with a PROD, their argument being that removing tags is PRODable.
Maury
I think procedure for most of these is tag the article AND leave a note on the talk page. This may not apply to {{wikify}} but then I don't there there is any "burden of prof" to removing {{wikify}}. If you remove it then and they put it back then you have a legatimate content dispute which policy says shoudl be discussed. Either way you get them on the talk page.
As for PROD is that not {{PROD}} which simply if I am not mistaken says that ANYONE can remove it with only the reason that they disagree? The template itself says "If this template is removed, it should not be replaced."
SKL
Anyone can {{prod}}, but prod is for uncontroversial deletions; which is why anyone can remove the tag. If you feel an article need not be wikified, remove the tag and mention why not in the edit summary. I regularly wikify as part of [[WP:WWF]] and we find a lot of articles tagged for wikification since april/may have been fixed long since, or have not needed wikification in the first place - there is a template you can use to tell people when wikification is not needed, see http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Wikify/wikified_wrongly (its for [[WP:WWF]] members, but that doesn't mean you can't use it). I'm wikifying the Mirror Fusion article anyway, it doesn't need much work, just some of the bolding is unneccessary.
Akash a.k.a Draicone
On 8/31/06, ScottL scott@mu.org wrote:
Maury Markowitz wrote:
I recently got into a minor squable that started with another example of what I refer to as "drive-by tagging". Basically someone comes by an article and inserts a whole bunch of tags without any comment. Some of these may be valid, others less so, but very often its impossible to know one way or the other without the original "tagger" pointing out the problems.
For instance, consider this example I came across recently: Mirror Fusion Test Facility. The "tagger" inserted a needs cats and needs wikification. The cats one was entirely valid and I added one, but I can't for the life of me even imagine what needs additional wikification. It seems to follow the style guide perfectly. I wrote to the tagger, but he responded saying "by following the link within the tag for all you need to know about wikifying an article", which is a non-answer.
I would like to hear any comments you all may have on this topic. Is it OK to simply remove vague tags if the article in question does not appear to have a problem related to the tag and there is no comment? I ask because, as I noted, the last time I removed tags the tagger then stamped the article with a PROD, their argument being that removing tags is PRODable.
Maury
I think procedure for most of these is tag the article AND leave a note on the talk page. This may not apply to {{wikify}} but then I don't there there is any "burden of prof" to removing {{wikify}}. If you remove it then and they put it back then you have a legatimate content dispute which policy says shoudl be discussed. Either way you get them on the talk page.
As for PROD is that not {{PROD}} which simply if I am not mistaken says that ANYONE can remove it with only the reason that they disagree? The template itself says "If this template is removed, it should not be replaced."
SKL _______________________________________________ Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
On 31/08/06, Akash Mehta draicone@gmail.com wrote:
there is a template you can use to tell people when wikification is not needed, see http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Wikify/wikified_wrongly (its for [[WP:WWF]] members, but that doesn't mean you can't use it).
That seems like extra procedure for no good reason. What on earth is wrong with just removing the {{wikify}} tag when it's not needed? It's a fairly subjective editorial judgement.
- d.
Generally the best option is to just remove the tag, but to conform to WP:BITE, if a clearly inexperienced user is trying to do their best by tagging all the articles in the world, we give them a nudge with that template. Of course, I've never seen anyone use it, its just there in case its ever needed.
On 8/31/06, David Gerard dgerard@gmail.com wrote:
On 31/08/06, Akash Mehta draicone@gmail.com wrote:
there is a template you can use to tell people when wikification is not needed, see http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Wikify/wikified_wrongly (its for [[WP:WWF]] members, but that doesn't mean you can't use it).
That seems like extra procedure for no good reason. What on earth is wrong with just removing the {{wikify}} tag when it's not needed? It's a fairly subjective editorial judgement.
- d.
Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
On 31/08/06, Akash Mehta draicone@gmail.com wrote:
Generally the best option is to just remove the tag, but to conform to WP:BITE, if a clearly inexperienced user is trying to do their best by tagging all the articles in the world, we give them a nudge with that template. Of course, I've never seen anyone use it, its just there in case its ever needed.
Yeah. Newbies who start being procedural obsessives are difficult to deal with in general. Put six tags on an article, obsessively check all PRODs you've ever placed and AFD *any* that someone just removes, etc., etc.
The interesting bits of life are the grey areas. Wikipedia is not a refuge from them. How to get this across to those who see the world entirely in black and white, and think of grey as a kind of defective stippling?
- d.
David Gerard wrote:
On 31/08/06, Akash Mehta draicone@gmail.com wrote:
Generally the best option is to just remove the tag, but to conform to WP:BITE, if a clearly inexperienced user is trying to do their best by tagging all the articles in the world, we give them a nudge with that template. Of course, I've never seen anyone use it, its just there in case its ever needed.
Yeah. Newbies who start being procedural obsessives are difficult to deal with in general. Put six tags on an article, obsessively check all PRODs you've ever placed and AFD *any* that someone just removes, etc., etc.
The interesting bits of life are the grey areas. Wikipedia is not a refuge from them. How to get this across to those who see the world entirely in black and white, and think of grey as a kind of defective stippling?
Wait until Mediawiki 2.0, which will /finally/ have 40kV through the chair.
On 31/08/06, Alphax (Wikipedia email) alphasigmax@gmail.com wrote:
David Gerard wrote:
The interesting bits of life are the grey areas. Wikipedia is not a refuge from them. How to get this across to those who see the world entirely in black and white, and think of grey as a kind of defective stippling?
Wait until Mediawiki 2.0, which will /finally/ have 40kV through the chair.
I thought that was set for the III Phase version of the software.
- d.
On 8/31/06, David Gerard dgerard@gmail.com wrote:
On 31/08/06, Alphax (Wikipedia email) alphasigmax@gmail.com wrote:
David Gerard wrote:
The interesting bits of life are the grey areas. Wikipedia is not a refuge from them. How to get this across to those who see the world entirely in black and white, and think of grey as a kind of defective stippling?
Wait until Mediawiki 2.0, which will /finally/ have 40kV through the
chair.
I thought that was set for the III Phase version of the software.
**Groan!**---------------------------^
-Rich Holton [[W:en:User:Rholton]]
I hope its in 2.0, but we must respect the roadmap (if any). Is there a mediawiki development mailing list I can join (slightly offtopic, sorry, but I couldn't find it anywhere)?
On 8/31/06, Richard Holton richholton@gmail.com wrote:
On 8/31/06, David Gerard dgerard@gmail.com wrote:
On 31/08/06, Alphax (Wikipedia email) alphasigmax@gmail.com wrote:
David Gerard wrote:
The interesting bits of life are the grey areas. Wikipedia is not a refuge from them. How to get this across to those who see the world entirely in black and white, and think of grey as a kind of defective stippling?
Wait until Mediawiki 2.0, which will /finally/ have 40kV through the
chair.
I thought that was set for the III Phase version of the software.
**Groan!**---------------------------^
-Rich Holton [[W:en:User:Rholton]] _______________________________________________ Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
On 31/08/06, Akash Mehta draicone@gmail.com wrote:
On 8/31/06, Richard Holton richholton@gmail.com wrote:
On 8/31/06, David Gerard dgerard@gmail.com wrote:
On 31/08/06, Alphax (Wikipedia email) alphasigmax@gmail.com wrote:
Wait until Mediawiki 2.0, which will /finally/ have 40kV through the
chair.
I thought that was set for the III Phase version of the software.
**Groan!**---------------------------^
I hope its in 2.0, but we must respect the roadmap (if any). Is there a mediawiki development mailing list I can join (slightly offtopic, sorry, but I couldn't find it anywhere)?
wikitech-l
Apparently there are some technical difficulties in implementing the 40kV through the chair.
- d.
Pardon my ignorance, but whats the 40kV through the chair?
On 8/31/06, David Gerard dgerard@gmail.com wrote:
On 31/08/06, Akash Mehta draicone@gmail.com wrote:
On 8/31/06, Richard Holton richholton@gmail.com wrote:
On 8/31/06, David Gerard dgerard@gmail.com wrote:
On 31/08/06, Alphax (Wikipedia email) alphasigmax@gmail.com wrote:
Wait until Mediawiki 2.0, which will /finally/ have 40kV through the
chair.
I thought that was set for the III Phase version of the software.
**Groan!**---------------------------^
I hope its in 2.0, but we must respect the roadmap (if any). Is there a mediawiki development mailing list I can join (slightly offtopic, sorry, but I couldn't find it anywhere)?
wikitech-l
Apparently there are some technical difficulties in implementing the 40kV through the chair.
- d.
Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
On 8/31/06, Akash Mehta draicone@gmail.com wrote:
Pardon my ignorance, but whats the 40kV through the chair?
"40kV" is a reference to electrical voltage. I believe Alphax was making a
non-serious suggestion that a future version of MediaWiki (the software behind WIkipedia) will allow for the discouragement of unwanted behavior by... ah... "stimulating" the offender.
-Rich Holton
[[W:en:User:Rholton]]
Yeah. Newbies who start being procedural obsessives are difficult to deal with in general. Put six tags on an article, obsessively check all PRODs you've ever placed and AFD *any* that someone just removes, etc., etc.
Well this is precisely what happened to me. Things got nasty with a newly-minted admin decided to take the newbie under his wing, and started reverting. *sigh* Well, water under the bridge really.
But David, I was wondering if you would consider starting an article on "procedural obsessives"? It seems that simply pointing people towards such an article would be a much more neutral way to deal with it than posting a personal message on their talk page. THAT can easily be misinterpreted as someone trying to protect "their" article.
Maury
On 31/08/06, Maury Markowitz maury_markowitz@hotmail.com wrote:
But David, I was wondering if you would consider starting an article on "procedural obsessives"? It seems that simply pointing people towards such an article would be a much more neutral way to deal with it than posting a personal message on their talk page. THAT can easily be misinterpreted as someone trying to protect "their" article.
*splutter* To say this is a contentious issue is an understatement.
See [[:en:Wikipedia:Ignore All Rules]] is one. Now, I'd like you to read the talk page and the history of that page. A lot of people HATED it passionately and did their best to kill it or at least neuter it. But Jimbo has stated it's obviously policy, because product beats process.
See [[:en:Wikipedia:Process is Important]]. Which, of course, it is.
See [[m:Instruction creep]]. And its history ... in which you can see how it was instruction-crept.
See [[m:Don't be a dick]] and the attempts to kill that, most notably by claiming it must be deleted because the translation would be unacceptably rude in Japanese.
- d.
On 8/31/06, David Gerard dgerard@gmail.com wrote:
On 31/08/06, Maury Markowitz maury_markowitz@hotmail.com wrote:
But David, I was wondering if you would consider starting an article on "procedural obsessives"? It seems that simply pointing people towards
such
an article would be a much more neutral way to deal with it than posting
a
personal message on their talk page. THAT can easily be misinterpreted
as
someone trying to protect "their" article.
*splutter* To say this is a contentious issue is an understatement.
See [[:en:Wikipedia:Ignore All Rules]] is one. Now, I'd like you to read the talk page and the history of that page. A lot of people HATED it passionately and did their best to kill it or at least neuter it. But Jimbo has stated it's obviously policy, because product beats process.
See [[:en:Wikipedia:Process is Important]]. Which, of course, it is.
See [[m:Instruction creep]]. And its history ... in which you can see how it was instruction-crept.
See [[m:Don't be a dick]] and the attempts to kill that, most notably by claiming it must be deleted because the translation would be unacceptably rude in Japanese.
And a bit related, [[en:Wikipedia:Wikilawyering]] which (quote) "clearly exploits and perpetrates a host of biased and derogatory stereotypes"
:)
Garion96
David Gerard wrote:
On 31/08/06, Maury Markowitz maury_markowitz@hotmail.com wrote:
But David, I was wondering if you would consider starting an article on "procedural obsessives"? It seems that simply pointing people towards such an article would be a much more neutral way to deal with it than posting a personal message on their talk page. THAT can easily be misinterpreted as someone trying to protect "their" article.
*splutter* To say this is a contentious issue is an understatement.
See [[:en:Wikipedia:Ignore All Rules]] is one. Now, I'd like you to read the talk page and the history of that page. A lot of people HATED it passionately and did their best to kill it or at least neuter it. But Jimbo has stated it's obviously policy, because product beats process.
See [[:en:Wikipedia:Process is Important]]. Which, of course, it is.
See [[m:Instruction creep]]. And its history ... in which you can see how it was instruction-crept.
See [[m:Don't be a dick]] and the attempts to kill that, most notably by claiming it must be deleted because the translation would be unacceptably rude in Japanese.
These seem like some of the most important policies ... or am I just showing my age? As for the last one, the Japanese will just have to read it in English. ;-)
Ec
Generally the best option is to just remove the tag, but to conform to WP:BITE, if a clearly inexperienced user is trying to do their best by tagging all the articles in the world, we give them a nudge with that template. Of course, I've never seen anyone use it, its just there in case its ever needed.
I think I could have avoided a lot of the fallout that occured had I used something like this. Well, maybe, hard to say.
But I do have a suggestion: could you make the template smaller? It's HUGE! I'd actually feel bad putting this on someone's talk page. Perhaps something that is much smaller and links to a page that has the content within?
Maury
Where do I post about bugs in the MediaWiki software?
The bug I have noticed is that when you click on "my contributions" it does not turn bold, unlike the other items in the "menu bar". Yes, piquane, I know.
Maury
Maury Markowitz wrote:
Where do I post about bugs in the MediaWiki software?
wikitech-l () wikimedia ! org
The bug I have noticed is that when you click on "my contributions" it does not turn bold, unlike the other items in the "menu bar". Yes, piquane, I know.
You could probably do it with javascript...
You can do it with Greasemonkey using Platypus and an if(document.location.href="http://en.wikipedia.org/wiki/Special:Contributions%22)%7B [platypus code] }
On 9/3/06, Alphax (Wikipedia email) alphasigmax@gmail.com wrote:
Maury Markowitz wrote:
The bug I have noticed is that when you click on "my contributions" it does not turn bold, unlike the other items in the "menu bar". Yes, piquane, I know.
You could probably do it with javascript...
On 03/09/06, Maury Markowitz maury_markowitz@hotmail.com wrote:
Where do I post about bugs in the MediaWiki software? The bug I have noticed is that when you click on "my contributions" it does not turn bold, unlike the other items in the "menu bar". Yes, piquane, I know.
http://bugzilla.wikimedia.org/ as well.
- d.
I'm trying to be the good wikipedian and adding lots of on-topic refs, but I find editing them to be extremely difficult and error prone. IMHO the actual "body" of the ref should definitely not be placed in the article body, where it is now, as this makes reading the source difficult, to say the least. Click edit on Zune some time...
Is there some alternate format? Can I use the <ref name=gizifa/> and then place the actual contents later in the article, like in the actual reference section? All of my attempts to date have failed.
If not, is there some sort of editor that makes this easier?
Maury
On 05/10/06, Maury Markowitz maury_markowitz@hotmail.com wrote:
I'm trying to be the good wikipedian and adding lots of on-topic refs, but I find editing them to be extremely difficult and error prone. IMHO the actual "body" of the ref should definitely not be placed in the article body, where it is now, as this makes reading the source difficult, to say the least. Click edit on Zune some time...
Is there some alternate format? Can I use the <ref name=gizifa/> and then place the actual contents later in the article, like in the actual reference section? All of my attempts to date have failed.
cite.php currently requires you to have the first <ref name="whatever"> tag contain the reference data, which can also pose a problem if you're moving sections of an article around and you suddenly find all your references break. It might be worth filing a bug request addressing this, which would go some way towards alleviating your problem...
--- Maury Markowitz maury_markowitz@hotmail.com wrote:
I'm trying to be the good wikipedian and adding lots of on-topic refs, but I find editing them to be extremely difficult and error prone. IMHO the actual "body" of the ref should definitely not be placed in the article body, where it is now, as this makes reading the source difficult, to say the least. Click edit on Zune some time...
Is there some alternate format? Can I use the <ref name=gizifa/> and then place the actual contents later in the article, like in the actual reference section? All of my attempts to date have failed.
If not, is there some sort of editor that makes this easier?
Here is what I do: Under ==References== I have two subsections, ===Works cited=== and ===Notes===. ===Works cited=== has the full reference info in standard reference order while ===Notes=== has <references/>. Then inline, I have stuff like <ref>Smith, John, p. 249</ref>. However, this does not work well for articles that use more than a dozen or so separate sources.
-- mav
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
2006/10/5, Maury Markowitz maury_markowitz@hotmail.com:
I'm trying to be the good wikipedian and adding lots of on-topic refs, but I find editing them to be extremely difficult and error prone. IMHO the actual "body" of the ref should definitely not be placed in the article body, where it is now, as this makes reading the source difficult, to say the least.
Agreed. At least it should be possible to put a line break before and after the reference tags, to help the eye distinguish between the text and the ref and make the source text more readable. I have tried that, but it puts a space between the text and the little superscript letter that tells which source supports the statements. I guess I will continue doing that when working on a text, then remove the line breaks.
Another problem, when editing a text with refs in them, is that it is not always clear exactly what is covered by the ref. A ref in the middle of a sentence is usually obvious, it supports just a small part of that sentence and usually one single fact. A ref in the end of a paragraph could however refer to the whole paragraph, the last sentence, or the last fact in the last sentence. This is seldom a problem when only reading a text with references in it. However, I have more than once refrained from shuffling the contents of a text about out of fear for introducing errors in the citations.
For the future, could we imagine a citation system where the pair of reference tags enclose the portion of the text that the source refers to? The text of the reference itself then needs to be put someplace else. A source text that in the current system looks something like this
The plant A growns in Spain. It needs much sun and water, and its leaves are sometimes used as herbal medicine. It belongs to the genus Spirk and is usually considered related to the plant B,<ref>Peter Plimp, The succulents of the Mediterranian, Scrottie Publishing House, 2003</ref>, although this is debated. There are many subspecies of A, of which some are edible. The subspecies X is bla bla, Y is bla bla and Z is bla bla. The notion that A actually belongs to the genus Scrubbicus, which is completely unrelated to B, is supported by a small numbers of researchers including Thomas Tipp. Recently (June 2006), Salomon Smith and coworkers discovered new facts that support this hypothesis although these data are controversial. <ref>[http://www.controversy.com Aron Assont on the Smith data, controversy.com]</ref>
could maybe look something like this
The plant A growns in Spain. It needs much sun and water, and its leaves are sometimes used as herbal medicine. It belongs to the genus Spirk and <ref=Plimp> is usually considered related to the plant B,</ref> although this is debated. There are many subspecies of A, of which some are edible. The subspecies X is bla bla, Y is bla bla and Z is bla bla. <ref=Assont>The notion that A actually belongs to the genus Scrubbicus, which is completely unrelated to B, is supported by a small numbers of researchers including Thomas Tipp. Recently (June 2006), Salomon Smith and coworkers discovered new facts that support this hypothesis although these data are controversial. </ref>
This version contains more precise information on how the text relates to the sources used. Academic texts are not this precise with their references, but those texts will not be shuffled about by several people after the original author published it. Also, the academic standard for annotation of sources within text was created for print not the internet - they don't have the possibility.
/habj
habj wrote:
2006/10/5, Maury Markowitz maury_markowitz@hotmail.com:
I'm trying to be the good wikipedian and adding lots of on-topic refs, but I find editing them to be extremely difficult and error prone. IMHO the actual "body" of the ref should definitely not be placed in the article body, where it is now, as this makes reading the source difficult, to say the least.
Agreed. At least it should be possible to put a line break before and after the reference tags, to help the eye distinguish between the text and the ref and make the source text more readable. I have tried that, but it puts a space between the text and the little superscript letter that tells which source supports the statements. I guess I will continue doing that when working on a text, then remove the line breaks.
You can put the line breaks right _after_ the ref tag without adding extra spaces.<ref> {{cite mailinglist| first=Bryan| last=Derksen| list=wikipedia-l| title=Any suggestions for editing refs?| date=2006-10-08}}</ref> And if the line break after the /ref tag adds a space it's no problem since that's usually intended anyway.
For the future, could we imagine a citation system where the pair of reference tags enclose the portion of the text that the source refers to? The text of the reference itself then needs to be put someplace else.
I don't like this idea much, it seems likely to make the references a lot more "fragile" than they currently are. If you've referenced a large block of text this way then one could easily wind up cutting and pasting chunks that might break the citations, and it goes back to the {{ref}} template's old problem of having to change two separate sections of the article when adding or removing a reference. I'm not sure it'd be worth the extra trouble.
I like the current system because it's so "atomic"; a reference's text lives in just one location, and that location is in the same place where the citation's link is supposed to go in the final result. The only problem I've seen with the current system is that occasionally when there are multiple tags for one reference and the first instance gets removed we wind up with blank references below, but at least that's easily noticeable.
And if the line break after the /ref tag adds a space it's no problem since that's usually intended anyway.
Uhhh, no. This is a very very very bad assumption. At least 80% of my refs do NOT appear in a place where a break is appropriate.
I don't like this idea much, it seems likely to make the references a lot more "fragile" than they currently are.
I can't imagine a LESS stable system than the one we have currently! One missplaced char in the tags and the rest of the article disappears!
There's a basic rule here that is best known in the computer industry: longer code contains more errors. By separating the ref "markers" from the ref "body" the main article text becomes smaller and easier to read. This will lead to LESS errors with refs. It will also mean that cutting and pasting will not lead to the sorts of errors we see today where someone moves a para containing a placeholder to an earlier ref and the entire ref system stops working again.
If you've referenced a large block of text this way then one could easily wind up cutting and pasting chunks that might break the citations, and it goes back to the {{ref}} template's old problem of having to change two separate sections of the article when adding or removing a reference.
This is a valid concern, but was the problem worse than the terrible mess we have now?
I like the current system because it's so "atomic"; a reference's text lives in just one location
I'm not sure this is any different. If I use one ref in a couple of places in my article (quite common) then you end up with one body text and several pointers to it. The only different here is that ALL body text would be pointers -- as an option, of course.
It seems to me the only reason this doesn't work now is because the original ref body must appear before all references to it. If this were changed one could do refs any way they want, as well as fixing the problem with editing.
Maury
Maury Markowitz wrote:
And if the line break after the /ref tag adds a space it's no problem since that's usually intended anyway.
Uhhh, no. This is a very very very bad assumption. At least 80% of my refs do NOT appear in a place where a break is appropriate.
The only situation I can think of where it's not appropriate to have a space _after_ the ref is when there's a string of multiple references grouped together. What situations are you thinking of?
I don't like this idea much, it seems likely to make the references a lot more "fragile" than they currently are.
I can't imagine a LESS stable system than the one we have currently! One missplaced char in the tags and the rest of the article disappears!
Actually, IMO it's much better to have errors like that than errors that "silently" break things. Having a big chunk of article disappear, or having it appear in a hashed-up form down in the references section (as often happens when I typo a </ref>) is obvious and indicates the location of the error quite easily. Under the old {{ref}} templates I would often find ref links with no note text, orphaned note text without references to it, and refs pointing to the wrong notes, all of which looked completely normal and could only be identified as problematic by clicking on the links and noticing that they didn't take you anywhere.
Under the current cite.php system the "quietest" way a ref can break is to not have any text associated with it, which results in a blank note down in the references section. This is still pretty obvious. Just the other day I went and fixed three of them in the [[2006 Israel-Lebanon conflict]] page. It was easy to spot them despite there being nearly 200 other references in that article.
There's a basic rule here that is best known in the computer industry: longer code contains more errors. By separating the ref "markers" from the ref "body" the main article text becomes smaller and easier to read. This will lead to LESS errors with refs. It will also mean that cutting and pasting will not lead to the sorts of errors we see today where someone moves a para containing a placeholder to an earlier ref and the entire ref system stops working again.
That's an exaggeration, only that _particular_ ref stops working in that case. And the failure results in a highly noticeable blank reference, making it obvious that it needs fixing.
If you've referenced a large block of text this way then one could easily wind up cutting and pasting chunks that might break the citations, and it goes back to the {{ref}} template's old problem of having to change two separate sections of the article when adding or removing a reference.
This is a valid concern, but was the problem worse than the terrible mess we have now?
I've converted a lot of {{ref}}/{{note}} articles over to the new ref system in the course of my travels through Wikipedia and I'd estimate something like a quarter of the articles with non-trivial numbers of references in them had missing or orphaned references. In the case of cite.php I can only recall two articles requiring major reference repair work (both of which had been split out of the article [[Hugo Chavez]]). Doesn't seem very terrible to me.
It seems to me the only reason this doesn't work now is because the original ref body must appear before all references to it. If this were changed one could do refs any way they want, as well as fixing the problem with editing.
It would make it harder to track down where the ref's actual text was, though.
I suppose making your proposal an optional variation to the existing system wouldn't be too bad, though there'd be some extra work cleaning up old orphaned references that had gone "invisible" through disuse but were still tucked away in the article's source code. Yet another tidy-bot, I suppose.
The only situation I can think of where it's not appropriate to have a space _after_ the ref is when there's a string of multiple references grouped together. What situations are you thinking of?
When the next character is a period or comma.
Maury
Maury Markowitz wrote:
The only situation I can think of where it's not appropriate to have a space _after_ the ref is when there's a string of multiple references grouped together. What situations are you thinking of?
When the next character is a period or comma.
Most style guides of which I'm aware say that superscripts should be placed after a period or comma, not before it. That looks better to me as well.
-Mark
Delirium wrote:
Maury Markowitz wrote:
The only situation I can think of where it's not appropriate to have a space _after_ the ref is when there's a string of multiple references grouped together. What situations are you thinking of?
When the next character is a period or comma.
Most style guides of which I'm aware say that superscripts should be placed after a period or comma, not before it. That looks better to me as well.
And Wikipedia's style guide is one such: http://en.wikipedia.org/wiki/Wikipedia:Footnotes#Where_to_place_ref_tags Apparently based on the Chicago Manual of Style.
I see now that there's one other situation where there's no space after the </ref> tag; when it has a dash following it. I expect that's a fairly rare occurrence.
David Gerard wrote:
On 31/08/06, Akash Mehta draicone@gmail.com wrote:
there is a template you can use to tell people when wikification is not needed, see http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Wikify/wikified_wrongly (its for [[WP:WWF]] members, but that doesn't mean you can't use it).
That seems like extra procedure for no good reason. What on earth is wrong with just removing the {{wikify}} tag when it's not needed? It's a fairly subjective editorial judgement.
Absolutely. The person who adds the tag should provide detailed information about what needs to be wikified. If he fails to do that it should be reason enough to remove the tag.
Ec
wikipedia-l@lists.wikimedia.org