On 9/8/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
A very important aspect that needs to be in stable versions, IMO, is the ability to ignore the system completely if one wants to. The first thing I plan to do when the feature is enabled is to set my preferences so that I always see the most recent version, not just the most recent stable version; I want to work at the raw coal face of Wikipedia, for me stable versions is just a fence around the worksite to get people to stop "helpfully" filling in the hole I'm trying to dig.
Just curious. If I made a patch that allowed any user with "markstable" (by default sysops) to mark a particular version of an article as "stable", and then showed that version to users who weren't logged in, and added $wgStableVersions to turn it on and off, would it be accepted?
No, an extension has been in the works for several months.
Anthony-73 wrote:
On 9/8/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
A very important aspect that needs to be in stable versions, IMO, is the ability to ignore the system completely if one wants to. The first thing I plan to do when the feature is enabled is to set my preferences so that I always see the most recent version, not just the most recent stable version; I want to work at the raw coal face of Wikipedia, for me stable versions is just a fence around the worksite to get people to stop "helpfully" filling in the hole I'm trying to dig.
Just curious. If I made a patch that allowed any user with "markstable" (by default sysops) to mark a particular version of an article as "stable", and then showed that version to users who weren't logged in, and added $wgStableVersions to turn it on and off, would it be accepted?
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
On 08/09/2007, Anthony wikimail@inbox.org wrote:
On 9/8/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
A very important aspect that needs to be in stable versions, IMO, is the ability to ignore the system completely if one wants to. The first thing I plan to do when the feature is enabled is to set my preferences so that I always see the most recent version, not just the most recent stable version; I want to work at the raw coal face of Wikipedia, for me stable versions is just a fence around the worksite to get people to stop "helpfully" filling in the hole I'm trying to dig.
Just curious. If I made a patch that allowed any user with "markstable" (by default sysops) to mark a particular version of an article as "stable", and then showed that version to users who weren't logged in, and added $wgStableVersions to turn it on and off, would it be accepted?
It's hard to get the MediaWiki developers to commit much of anything, it seems to me. Citizendium might be interested, perhaps you could talk them into hosting a MediaWiki fork with your modification.
On 9/8/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
On 08/09/2007, Anthony wikimail@inbox.org wrote:
On 9/8/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
A very important aspect that needs to be in stable versions, IMO, is the ability to ignore the system completely if one wants to. The first thing I plan to do when the feature is enabled is to set my preferences so that I always see the most recent version, not just the most recent stable version; I want to work at the raw coal face of Wikipedia, for me stable versions is just a fence around the worksite to get people to stop "helpfully" filling in the hole I'm trying to dig.
Just curious. If I made a patch that allowed any user with "markstable" (by default sysops) to mark a particular version of an article as "stable", and then showed that version to users who weren't logged in, and added $wgStableVersions to turn it on and off, would it be accepted?
It's hard to get the MediaWiki developers to commit much of anything, it seems to me. Citizendium might be interested, perhaps you could talk them into hosting a MediaWiki fork with your modification.
Well, to be completely clear, I don't have a modification. It was a totally hypothetical question. It'd probably be perfectly safe for developers to say "sure, we'll accept it, if it works *and* performs well". :)
On 08/09/2007, Anthony wikimail@inbox.org wrote:
On 9/8/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
It's hard to get the MediaWiki developers to commit much of anything, it seems to me. Citizendium might be interested, perhaps you could talk them into hosting a MediaWiki fork with your modification.
Well, to be completely clear, I don't have a modification. It was a totally hypothetical question. It'd probably be perfectly safe for developers to say "sure, we'll accept it, if it works *and* performs well". :)
I wouldn't expect the MediaWiki developers to commit anything without putting you through consensus-building hell first. Forking is probably much easier.
Best of luck. : )
On 9/8/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
On 08/09/2007, Anthony wikimail@inbox.org wrote:
On 9/8/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
It's hard to get the MediaWiki developers to commit much of anything, it seems to me. Citizendium might be interested, perhaps you could talk them into hosting a MediaWiki fork with your modification.
Well, to be completely clear, I don't have a modification. It was a totally hypothetical question. It'd probably be perfectly safe for developers to say "sure, we'll accept it, if it works *and* performs well". :)
I wouldn't expect the MediaWiki developers to commit anything without putting you through consensus-building hell first. Forking is probably much easier.
I would think the consensus-building would only be required to turn *on* the feature for a particular wiki, not to accept it into the codebase.
On 9/9/07, Grease Monkee welloiledmachine@gmail.com wrote:
Stable versions doesn't need a single new line of code - only the will of the community to implement it (and maybe some leadership).
On 9/8/07, Voice of All jschulz_4587@msn.com wrote:
No, an extension has been in the works for several months.
http://www.mediawiki.org/wiki/Extension:FlaggedRevs
Is that it?
On 09/09/2007, Anthony wikimail@inbox.org wrote:
On 9/8/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
I wouldn't expect the MediaWiki developers to commit anything without putting you through consensus-building hell first. Forking is probably much easier.
I would think the consensus-building would only be required to turn *on* the feature for a particular wiki, not to accept it into the codebase.
Nym: http://lunkwill.org/cv/nym.pdf http://archives.seul.org/or/talk/Oct-2005/msg00229.html http://bugzilla.wikimedia.org/show_bug.cgi?id=3729 http://archives.seul.org/or/talk/Dec-2005/msg00003.html http://lunkwill.org/src/nym/javascript/jsnymclient.html http://lunkwill.org/src/nym/
Blocking sets of IPs: http://www.imperialviolet.org/binary/mediawiki-1.4.4-tor-block.patch http://archives.seul.org/or/talk/May-2005/msg00128.html http://archives.seul.org/or/talk/Sep-2005/msg00312.html
On 9/9/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
On 09/09/2007, Anthony wikimail@inbox.org wrote:
On 9/8/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
I wouldn't expect the MediaWiki developers to commit anything without putting you through consensus-building hell first. Forking is probably much easier.
I would think the consensus-building would only be required to turn *on* the feature for a particular wiki, not to accept it into the codebase.
Nym: http://lunkwill.org/cv/nym.pdf http://archives.seul.org/or/talk/Oct-2005/msg00229.html http://bugzilla.wikimedia.org/show_bug.cgi?id=3729 http://archives.seul.org/or/talk/Dec-2005/msg00003.html http://lunkwill.org/src/nym/javascript/jsnymclient.html http://lunkwill.org/src/nym/
Blocking sets of IPs: http://www.imperialviolet.org/binary/mediawiki-1.4.4-tor-block.patch http://archives.seul.org/or/talk/May-2005/msg00128.html http://archives.seul.org/or/talk/Sep-2005/msg00312.html
I don't really see the usefulness of the nym patches, but mass-blocking sets of IPs for a short period of time seems like a clearly useful patch to me. However, from the second message, that patch "is almost but not completely finished". It would also probably be better implemented as an extension. If you can make it into an extension then it really doesn't matter if the devs accept.
Back to the topic of stable versions, I've found some more pages, but still have no idea what's official, what's obsolete, what's rejected, etc.
http://meta.wikimedia.org/wiki/Article_validation_feature http://meta.wikimedia.org/wiki/Reviewed_article_version http://meta.wikimedia.org/wiki/Article_validation http://meta.wikimedia.org/wiki/Article_endorsement http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2006-07-10/More_st... http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2006-08-07/Wikiman... http://en.wikipedia.org/wiki/Wikipedia:Stable_versions_now (rejected) http://www.mediawiki.org/wiki/Extension:FlaggedRevs http://www.mediawiki.org/wiki/Extension:Review
On 08/09/2007, Anthony wikimail@inbox.org wrote:
Just curious. If I made a patch that allowed any user with "markstable" (by default sysops) to mark a particular version of an article as "stable", and then showed that version to users who weren't logged in, and added $wgStableVersions to turn it on and off, would it be accepted?
For the record, although I have given up on the MediaWiki developers, I do believe this would be a good thing if someone used it. Also make sure Google caches the stable versions.
On 9/9/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
It's hard to get the MediaWiki developers to commit much
of anything, it seems to me.
...
I wouldn't expect the MediaWiki developers to
commit anything without putting you through consensus-building hell first.
...
For the record, although I have given up on the MediaWiki developers, I do believe this would
Three negative comments about the MediaWiki developers in a row. How about some nice comments, about anything, for a change?
Steve
Steve Bennett wrote:
Three negative comments about the MediaWiki developers in a row. How about some nice comments, about anything, for a change?
I'm sure they're well-groomed? :)
I don't have any negative comments to make about MediaWiki developers in general, indeed in general I think they've put out a remarkable piece of software. It's not every day that a piece of software is custom-designed for free and then proceeds to handle the sort of workload that Wikipedia puts on it.
But in this one particular instance of the stable version feature, I must admit that I have become tremendously frustrated by how long something like this been promised but not delivered. I don't expect it's any specific person's fault, perhaps just a systemic problem resulting from the crossover of the software development side and the editor side of decision-making processes, but from the outside it's not obvious what the holdup is.
On 9/9/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
But in this one particular instance of the stable version feature, I must admit that I have become tremendously frustrated by how long something like this been promised but not delivered. I don't expect it's any specific person's fault, perhaps just a systemic problem resulting from the crossover of the software development side and the editor side of decision-making processes, but from the outside it's not obvious what the holdup is.
The real problem is the lack of a product manager as such - that is, no one to communicate with the outside world, manage expectations etc. I've asked several times for the actual specification document for this feature, but haven't seen anything yet. It's one of the problems with OSS in general: people will implement what they feel like implementing, when they feel like it, and they don't take kindly to being pressured. Perfectly understandable for volunteers.
But it's a pain for us, because we've been publicly talking about this feature that's going to save Wikipedia, but we're in the dark about its actual progress.
(Of course, I don't actually believe that stable versions is a good idea, nor will it "save Wikipedia". But I'm interested in its progress nonetheless.)
Steve
On 09/09/2007, Steve Bennett stevagewp@gmail.com wrote:
The real problem is the lack of a product manager as such - that is, no one to communicate with the outside world, manage expectations etc. I've asked several times for the actual specification document for this feature, but haven't seen anything yet. It's one of the problems with OSS in general: people will implement what they feel like implementing, when they feel like it, and they don't take kindly to being pressured. Perfectly understandable for volunteers.
Actually, other open source projects tend to actually appreciate (almost) every contributor.
But it's a pain for us, because we've been publicly talking about this feature that's going to save Wikipedia, but we're in the dark about its actual progress.
And when volunteers spend months of personal time writing a patch for Wikipaedia, set up demonstrations, and it never even gets committed... then what?
(Of course, I don't actually believe that stable versions is a good idea, nor will it "save Wikipedia". But I'm interested in its progress nonetheless.)
Steve
On 9/9/07, Bryan Derksen bryan.derksen@shaw.ca wrote: [snip]
But in this one particular instance of the stable version feature, I must admit that I have become tremendously frustrated by how long something like this been promised but not delivered.
[snip]
Show me the promises.
Until fairly recently (i.e. when real development started) the only 'promises' of stable version that I've seen are speculation by non-developers and hand-waving arguments that some casual comment by a developer is really why the community shouldn't implement a half measure early.
i.e. http://en.wikipedia.org/wiki/Wikipedia:Stable_versions_now
It's your own darn fault for believing it. When someone says "oh that will be implemented.. don't do that yourself" your answer should be "Show me the code". If they don't have code it's not real.
Gregory Maxwell wrote:
It's your own darn fault for believing it. When someone says "oh that will be implemented.. don't do that yourself" your answer should be "Show me the code". If they don't have code it's not real.
I'm not a coder at all, I'm an editor. If I'm not supposed to believe anything I read on the mailing list without checking out SVN repositories and such to confirm it first-hand, what's the point in reading the mailing lists at all?
On 9/9/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
I'm not a coder at all, I'm an editor. If I'm not supposed to believe anything I read on the mailing list without checking out SVN repositories and such to confirm it first-hand, what's the point in reading the mailing lists at all?
You don't have to be a coder to ask critical questions like "Have you actually coded anything yet?".
As Grease Monkee points out.. We don't need software to have stable versions. We do need software to make stable versions work really well. Because the community of non-coders allowed a group of vocal opposers to stifle progress by claiming that there was mysterious software coming "any day now" we've had nothing all this time, and far more importantly we've lost a year of possible experience with stable version like features which could have helped to shape the functionality of the software.
The software that has been implemented has had input from a great number of people, including really extensive input from people in the German Wikipedia community.
There are some things I dislike about it. I would rather that we kept section edit links on the stable page, and simply made a diff appear at the top of the edit screen when you click an edit link from the stable version.
I'd also prefer that once a user has edited a page a cookie is set which will cause them to view the most recent version of that page, this way inattentive newbies will not really know that their change didn't really go live the moment they made it. Plus, once you've edited you really should be exposed to the whole sausage making process. :)
But overall I think it's pretty good, and I'm sure there will be lots of requested changes once it's live. I would have preferred that the features be more driven by experience than informed speculation, but we have what we have..
Gregory Maxwell wrote:
On 9/9/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
I'm not a coder at all, I'm an editor. If I'm not supposed to believe anything I read on the mailing list without checking out SVN repositories and such to confirm it first-hand, what's the point in reading the mailing lists at all?
You don't have to be a coder to ask critical questions like "Have you actually coded anything yet?".
As Grease Monkee points out.. We don't need software to have stable versions. We do need software to make stable versions work really well. Because the community of non-coders allowed a group of vocal opposers to stifle progress by claiming that there was mysterious software coming "any day now" we've had nothing all this time, and far more importantly we've lost a year of possible experience with stable version like features which could have helped to shape the functionality of the software.
The software that has been implemented has had input from a great number of people, including really extensive input from people in the German Wikipedia community.
There are some things I dislike about it. I would rather that we kept section edit links on the stable page, and simply made a diff appear at the top of the edit screen when you click an edit link from the stable version.
I'd also prefer that once a user has edited a page a cookie is set which will cause them to view the most recent version of that page, this way inattentive newbies will not really know that their change didn't really go live the moment they made it. Plus, once you've edited you really should be exposed to the whole sausage making process. :)
But overall I think it's pretty good, and I'm sure there will be lots of requested changes once it's live. I would have preferred that the features be more driven by experience than informed speculation, but we have what we have..
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
Another thing I would like to see is for an anonymous editor visiting the website, have the opportunity to very simply change the viewing system "view by default flagged versions when available" or "always see the latest version for all articles". Toggle type.
Otherwise, I mostly hope that there will be discussions, plain rejection of the tool or acceptance with improvment.
What I hope will NOT happen is a system where editors say
"we are happy to have this system only if there are improvementx X and Y". Then setting the system on with a promise that the improvements are coming in soon. Then see a situation such as the Single Login, where the so-called improvements take 5 years to be done. This would be very wrong.
Ant
On 9/9/07, Florence Devouard Anthere9@yahoo.com wrote:
Another thing I would like to see is for an anonymous editor visiting the website, have the opportunity to very simply change the viewing system "view by default flagged versions when available" or "always see the latest version for all articles". Toggle type.
Yeah, but hopefully worded a little more approachably: Wikipedia vs WikipediaHot! or something. Where are our marketing people? :)
Otherwise, I mostly hope that there will be discussions, plain rejection of the tool or acceptance with improvment.
What I hope will NOT happen is a system where editors say
"we are happy to have this system only if there are improvementx X and Y". Then setting the system on with a promise that the improvements are coming in soon. Then see a situation such as the Single Login, where the so-called improvements take 5 years to be done. This would be very wrong.
God I wish we had a specifications document somewhere so we could argue meaningfully over what we actually want or don't want. So far there seem to be a few different conceptions of what the community has asked for and what is actually going to be delivered.
Steve
On 9/11/07, Steve Bennett stevagewp@gmail.com wrote:
God I wish we had a specifications document somewhere so we could argue meaningfully over what we actually want or don't want. So far there seem to be a few different conceptions of what the community has asked for and what is actually going to be delivered.
At the same time enwp was allowing a few vocal voices to push back against anything like this proposal the powers that be in German Wikipedia were aggressively pushing it forward. It's due to their effort that we have anything coded at all at this point.
As such representatives from that community got to give a lot of the input that you wish to have had. Thems the breaks.
Fortunately, the Germans have solid judgement and certainly appear to have a more internally consistent vision than the EnWp community. So their greater influence on the design may turn out to be a win for English as well.
On 9/11/07, Gregory Maxwell gmaxwell@gmail.com wrote:
As such representatives from that community got to give a lot of the input that you wish to have had. Thems the breaks.
Fortunately, the Germans have solid judgement and certainly appear to have a more internally consistent vision than the EnWp community. So their greater influence on the design may turn out to be a win for English as well.
Yay for German engineering.
Steve
On 0, Steve Bennett stevagewp@gmail.com scribbled:
On 9/11/07, Gregory Maxwell gmaxwell@gmail.com wrote:
As such representatives from that community got to give a lot of the input that you wish to have had. Thems the breaks.
Fortunately, the Germans have solid judgement and certainly appear to have a more internally consistent vision than the EnWp community. So their greater influence on the design may turn out to be a win for English as well.
Yay for German engineering.
Steve
In the spirit of injecting some levity into this discussion, let us solemnly receive the wisdom of [[m:Bash]]:
<zocky> we should really do what germans did <zocky> delete all the non-free images, and most of the cruft <Rebent> ... <Darksun> I'm not saying that just because a show is notable, all it's episodes are. I'm saying that in some cases they are <zocky> it would help us get rid of people who think cruft is important <Rebent> zocky are you calling jews cruft? <kenlyric> nothing can end well that starts with "we should do what the germans did"
-- gwern RUOP RENS InfoSec "B-52G/H Chelsea ELF PLA W50 quiche 1984
On 9/10/07, Gregory Maxwell gmaxwell@gmail.com wrote:
At the same time enwp was allowing a few vocal voices to push back against anything like this proposal the powers that be in German Wikipedia were aggressively pushing it forward. It's due to their effort that we have anything coded at all at this point.
Bla bla bla. Don't blame a mob for bing a mob, Greg. Leadership comes from the top, not the other way around. How long have you been Chief Research Officer/Coordinator for the foundation?
As such representatives from that community got to give a lot of the
input that you wish to have had. Thems the breaks.
Fortunately, the Germans have solid judgement and certainly appear to have a more internally consistent vision than the EnWp community. So their greater influence on the design may turn out to be a win for English as well.
Show us the code.
On 9/10/07, Steve Bennett stevagewp@gmail.com wrote:
God I wish we had a specifications document somewhere so we could argue meaningfully over what we actually want or don't want. So far there seem to be a few different conceptions of what the community has asked for and what is actually going to be delivered.
Steve
*** so we could argue meaningfully *** = could go on forever
Three years ago I would have agreed with you. But if this feature is really as close as some people say it is, after so much delay, we should just turn it on somewhere and start working on it.
On 9/9/07, Florence Devouard Anthere9@yahoo.com wrote:
What I hope will NOT happen is a system where editors say
"we are happy to have this system only if there are improvementx X and Y". Then setting the system on with a promise that the improvements are coming in soon. Then see a situation such as the Single Login, where the so-called improvements take 5 years to be done. This would be very wrong.
Has the board considered doing anything to correct that problem and to stop it from happening again?
On 9/9/07, Florence Devouard Anthere9@yahoo.com wrote:
Another thing I would like to see is for an anonymous editor visiting the website, have the opportunity to very simply change the viewing system "view by default flagged versions when available" or "always see the latest version for all articles". Toggle type.
Disagree - let's observe the [[KISS]] principal to start with, just for the simple purpose of getting this project moving. Leave the whistles and bells for later. X100.
Otherwise, I mostly hope that there will be discussions, plain rejection
of the tool or acceptance with improvment.
What I hope will NOT happen is a system where editors say
"we are happy to have this system only if there are improvementx X and Y". Then setting the system on with a promise that the improvements are coming in soon. Then see a situation such as the Single Login, where the so-called improvements take 5 years to be done. This would be very wrong.
Ant
Good point - we will need to 'work the problem' until we get it right. Unless the feature happens to be so awful that we need to start over.
Just out of curiosity, Anthere, Is there documentation available to the community that describes what exactly this feature is? If I wanted to evaluate this feature, where could I find it at http://svn.wikimedia.org/?
Gregory Maxwell wrote:
On 9/9/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
I'm not a coder at all, I'm an editor. If I'm not supposed to believe anything I read on the mailing list without checking out SVN repositories and such to confirm it first-hand, what's the point in reading the mailing lists at all?
You don't have to be a coder to ask critical questions like "Have you actually coded anything yet?".
I have done so in the past, and have been told in the past that the code was in place, or just needed to be optimized, or was written but not put into the main repository, etc.
You were telling me that whenever anyone says something like that I shouldn't believe anything of the sort and should instead check out the source tree personally (presumably learning PHP if I don't already know it). So again, what's the point in asking? And since coding is only half the battle, how does this apply to the question of actually implementing the feature in the live Wikipedia?
On 09/09/2007, Bryan Derksen wrote:
You were telling me that whenever anyone says something like that I shouldn't believe anything of the sort and should instead check out the source tree personally (presumably learning PHP if I don't already know it). So again, what's the point in asking?
Are you asking for someone to go looking through the source tree for you?
If so, just say so directly.
--- Gregory Maxwell gmaxwell@gmail.com wrote:
Show me the promises.
Until fairly recently (i.e. when real development started) the only 'promises' of stable version that I've seen are speculation by non-developers and hand-waving arguments that some casual comment by a developer is really why the community shouldn't implement a half measure early.
Well, according to a Wikipedia Signpost article from last year, "MediaWiki developer Brion Vibber made a number of announcements at Wikimania [2006]; among the most notable were the announcement of plans to implement single-user login and stable versioning by the end of the year."
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2006-08-07/Wikiman...
-- Matt
___________________________________________________________ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html
On 9/8/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
But in this one particular instance of the stable version feature, I
must admit that I have become tremendously frustrated by how long something like this been promised but not delivered.
Stable versions doesn't need a single new line of code - only the will of the community to implement it (and maybe some leadership). Sure, software can help, but the community is hardly in a position to blame developers for not giving the community a spine.
some questions-
* Have our best featured article writers, photographers and content creators been involved in specifying what the stable version feature entails? If not, who has decided what a stable version should be?
* Where is the documentation of what, exactly, a stable version should be? If it doesn't exist, or hasn't been tested and widely evaluated, how can software for it be written?
* What's the wisdom of implementing a feature like this without running some simple trials (mind numbingly simple, actually) - like protecting a vetted article and sending new editing to a subpage - and then asking our best content creators to evaluate the process and write a procedure for revision rolls?
I don't expect it's
any specific person's fault, perhaps just a systemic problem resulting from the crossover of the software development side and the editor side of decision-making processes, but from the outside it's not obvious what the holdup is.
From my point of view, the holdup _should_ be to not kill the goose that
laid the golden egg (wide open editing) - lets be very very careful with what gets tinkered with.
see also - http://en.wikipedia.org/wiki/User:WellOiledMachine/Wikipedia_released
Grease Monkee wrote:
On 9/8/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
But in this one particular instance of the stable version feature, I
must admit that I have become tremendously frustrated by how long something like this been promised but not delivered.
Stable versions doesn't need a single new line of code - only the will of the community to implement it (and maybe some leadership). Sure, software can help, but the community is hardly in a position to blame developers for not giving the community a spine.
As I said, it's not specifically developers that I'm blaming here. It seems to be a system-wide thing.
From my point of view, the holdup _should_ be to not kill the goose that laid the golden egg (wide open editing) - lets be very very careful with what gets tinkered with.
If stable versions turns out to be a disaster for some reason it should be perfectly straightforward to just turn it off again.
Many previous dramatic new additions to Wikipedia's functionality were just dropped in our laps without extensive testing or demanding that every t be crossed in the policies relating to its use beforehand. Categories, templates, cite.php, semi-protection, the disabling of article creation by anons - as far as I can tell from my view from the trenches these things just dropped into our laps and we went on to figure out what the best way to handle them was largely through trial and error. Why not stable versions?
Bryan Derksen
As I said, it's not specifically developers that I'm blaming here. It seems to be a system-wide thing.
From my point of view, the holdup _should_ be to not kill the goose that laid the golden egg (wide open editing) - lets be very very careful with what gets tinkered with.
If stable versions turns out to be a disaster for some reason it should
be perfectly straightforward to just turn it off again.
from User:Jimbo Wales/Statement of principles: Any changes to the software must be gradual and reversible. Great minds think alike :)
There is abundant consensus to implement 'stable versions', but not much of a definition of what exactly a 'stable version' is. I think there is a real operatunity here for the leadership to run a few trials and try a few things. Hell, here is the perfect opperatunity to go begging on our hands and knees to User:Worldtraveller to return to the project for some consulting.
Grease Monkee wrote:
Bryan Derksen If stable versions turns out to be a disaster for some reason it should
be perfectly straightforward to just turn it off again.
from User:Jimbo Wales/Statement of principles: Any changes to the software must be gradual and reversible. Great minds think alike :)
Stable versions _is_ reversible. Much more reversible than something like categories, which were implemented without much thought being given to their ultimate usage. If categories had been turned off again it would have left a bajillion useless red [[category:]] links everywhere.
Stable versions doesn't have to do anything visible if the default is for people to see the most recent version rather than the one marked stable. Enable it, let people noodle around figuring out the procedures for what to mark, and if after a while the resulting version marking looks good maybe then make it the default anon view. IMO much better as a 'test' than page protection and editable subpages, which sounds rather awkward as far as usability and GFDL compliance go.
There is abundant consensus to implement 'stable versions', but not much of a definition of what exactly a 'stable version' is. I think there is a real opportunity here for the leadership to run a few trials and try a few things.
This might be part of the problem, then, since I haven't seen much in the way of leadership on this issue beyond some general statements of principle. Someone needs to actually throw the switch.
On 9/9/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
Grease Monkee wrote:
Bryan Derksen If stable versions turns out to be a disaster for some reason it should
be perfectly straightforward to just turn it off again.
from User:Jimbo Wales/Statement of principles: Any changes to the software must be gradual and reversible. Great minds think alike :)
Stable versions _is_ reversible. Much more reversible than something like categories, which were implemented without much thought being given to their ultimate usage. If categories had been turned off again it would have left a bajillion useless red [[category:]] links everywhere.
Stable versions doesn't have to do anything visible if the default is for people to see the most recent version rather than the one marked stable. Enable it, let people noodle around figuring out the procedures for what to mark, and if after a while the resulting version marking looks good maybe then make it the default anon view.
The thing is, if stable versions don't have to do anything visible, then the developers don't have to implement anything in the first place. People can just stick a note on the talk page for an article saying "I declare [http://en.wikipedia.org/w/index.php?title=Hey_Ya%21&oldid=156732871 version 156732871] to be stable" and other people can say "*I agree" or "*what are you high?" or whatever.
IMO much better as a 'test' than page protection and editable subpages, which sounds rather awkward as far as usability and GFDL compliance go.
I agree with you that that's an awkward hack. And I'm not sure there's much, if any, benefit. Would Seigenthaler have been less angry if that article had been at http://en.wikipedia.org/wiki/John_Seigenthaler%2C_Sr./unstable? I doubt it. But if it was at http://en.wikipedia.org/w/index.php?title=John_Seigenthaler%2C_Sr.&oldid..., on the other hand, I think it'd be more palatable.
Anthony
Anthony wrote:
On 9/9/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
Stable versions doesn't have to do anything visible if the default is for people to see the most recent version rather than the one marked stable. Enable it, let people noodle around figuring out the procedures for what to mark, and if after a while the resulting version marking looks good maybe then make it the default anon view.
The thing is, if stable versions don't have to do anything visible, then the developers don't have to implement anything in the first place. People can just stick a note on the talk page for an article saying "I declare [http://en.wikipedia.org/w/index.php?title=Hey_Ya%21&oldid=156732871 version 156732871] to be stable" and other people can say "*I agree" or "*what are you high?" or whatever.
But once this has been tried, assuming enough people actually follow this procedure to give meaningful results, what then? The software doesn't "understand" what those links in the talk pages mean so there's nowhere to go in terms of expanding Wikipedia's functionality based on it. You need software to be able to do things like have a "show stable version first" as a user preference, or to create a stable-version-only database dump.
And besides, the basic point of my complaint is that after years of people talking about stable versions absolutely _nothing_ has been implemented, not even a crude software-free hack to get things started. Not even the Featured Article talk page templates link to specific versions.
Bryan Derksen wrote:
And besides, the basic point of my complaint is that after years of people talking about stable versions absolutely _nothing_ has been implemented, not even a crude software-free hack to get things started. Not even the Featured Article talk page templates link to specific versions.
Wait, my bad. I see now that specific versions do get linked, the links are hidden behind a "[show]/[hide]" toggle.
So, we do have the barest bones of a stable versions hack in place, albeit with a rather cumbersome mechanism for updating which version is considered stable. How shall we go about evaluating and expanding it?
On 9/9/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
Anthony wrote:
On 9/9/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
Stable versions doesn't have to do anything visible if the default is for people to see the most recent version rather than the one marked stable. Enable it, let people noodle around figuring out the procedures for what to mark, and if after a while the resulting version marking looks good maybe then make it the default anon view.
The thing is, if stable versions don't have to do anything visible, then the developers don't have to implement anything in the first place. People can just stick a note on the talk page for an article saying "I declare [http://en.wikipedia.org/w/index.php?title=Hey_Ya%21&oldid=156732871 version 156732871] to be stable" and other people can say "*I agree" or "*what are you high?" or whatever.
But once this has been tried, assuming enough people actually follow this procedure to give meaningful results, what then?
Then convince the devs to accept a patch making stable versions the default non-logged-in page.
The software doesn't "understand" what those links in the talk pages mean so there's nowhere to go in terms of expanding Wikipedia's functionality based on it. You need software to be able to do things like have a "show stable version first" as a user preference, or to create a stable-version-only database dump.
If the information was at all organized (some sort of template system, for instance), it'd be quite easy to use it to create a stable-version-only database dump. "Enable it, let people noodle around figuring out the procedures for what to mark, and if after a while the resulting version marking looks good", then work on importing the information into the database. I imagine choosing a stable version is going to take some time. If 1000 stable versions can be chosen over the next month and it takes 10 seconds to import each result into the database, that's less than 3 hours of work importing the information into the db.
And besides, the basic point of my complaint is that after years of people talking about stable versions absolutely _nothing_ has been implemented
This doesn't seem accurate. See for instance this thread: http://www.nabble.com/Stable-article-versions-t3656072.html
"The developers working on this feature [stable versions] have it implemented on a test server right now."
At the same time, I can't figure out just what it is that they're talking about. Erik Möller and P.Birken are listed as the people to contact for more info.
http://www.mediawiki.org/wiki/Extension:Review
Maybe that?
And as you pointed out, Featured Articles get linked. And so do Good Articles. So combine the 1591 Featured Articles with the 2857 Good Articles, and we've got a good candidate for the stable version of 4448 articles.
On 08/09/2007, Steve Bennett stevagewp@gmail.com wrote:
Three negative comments about the MediaWiki developers in a row. How about some nice comments, about anything, for a change?
Steve
Well, let's see, the Tor developers are very very nice and will provide 1:1 end-user support to clueless Tor users on the Tor IRC channel and or-talk mailing list... highly ethical, worry about the ethical distinction between entrance block evasion and exit block evasion, feel bad they can't stop child porn.... : )
Tor is good too. It make me feel safer.... : )
So are balloons, especially black latex balloons. Latex is biodegradable, by the way.
And kittens! Especially kittens who climb Christmas trees.
Wikipaedia Review was rather nice to me... they removed things from their website upon request... or archived said things somewhere non-public... or something....
DeviantArt will even let a non DeviantArt member contact them representing someone else asking them to remove something from their website, and they will, no questions asked!
On 9/9/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
Tor is good too.
I guess I walked into that one.
Steve
On 9/9/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
On 08/09/2007, Steve Bennett stevagewp@gmail.com wrote:
Three negative comments about the MediaWiki developers in a row. How about some nice comments, about anything, for a change?
Steve
Well, let's see, the Tor developers are very very nice and will provide 1:1 end-user support to clueless Tor users on the Tor IRC channel and or-talk mailing list... highly ethical, worry about the ethical distinction between entrance block evasion and exit block evasion, feel bad they can't stop child porn.... : )
Tor is good too. It make me feel safer.... : )
So are balloons, especially black latex balloons. Latex is biodegradable, by the way.
And kittens! Especially kittens who climb Christmas trees.
Wikipaedia Review was rather nice to me... they removed things from their website upon request... or archived said things somewhere non-public... or something....
DeviantArt will even let a non DeviantArt member contact them representing someone else asking them to remove something from their website, and they will, no questions asked!
And most of the time (under normal circumstances), we do too, and we even give them a nice little e-mail back too. But of course... you would know nothing about this. I would ask you if you had ever e-mailed us, but I doubt I'd like the response I get. Rest assured, though, we work very hard on complaints, press inquires, and article problems (like BLP) that are e-mailed in to us.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
On 9/9/07, Casey Brown cbrown1023.ml@gmail.com wrote:
And most of the time (under normal circumstances), we do too, and we even give them a nice little e-mail back too. But of course... you would know nothing about this. I would ask you if you had ever e-mailed us, but I doubt I'd like the response I get. Rest assured, though, we work very hard on complaints, press inquires, and article problems (like BLP) that are e-mailed in to us.
Can you please blank the following pages:
[[Wikipedia:Requests for arbitration/Anthony DiPierro 2]] [[Wikipedia:Requests_for_comment/Anthony_DiPierro]] [[Wikipedia talk:Requests for arbitration/Anthony DiPierro]] [[Wikipedia:Requests for arbitration/Anthony DiPierro/Old evidence]] [[Wikipedia:Requests for adminship/Anthony DiPierro]] [[Wikipedia:Requests for arbitration/Anthony DiPierro/Evidence]] [[Wikipedia talk:Requests for arbitration/Anthony DiPierro 2]] [[Wikipedia:Requests for arbitration/Anthony DiPierro 2/Proposed decision]] [[Wikipedia:Requests for arbitration/Anthony DiPierro 2/Evidence]] [[User:Raul654/Anthony evidence]] [[Wikipedia:Requests for arbitration/Wik]] [[Wikipedia:Requests for arbitration/Standing orders/Anthony]] [[Wikipedia:Requests for mediation/Archive 7]] [[Wikipedia:Requests for arbitration/Wik/Proposed findings and remedies]] [[Wikipedia:Requests for arbitration/Dr Zen/Evidence]]
I'll probably find others, but that should be good for starters.
Shit...and can someone please blank that email, which I meant to send privately :)
On 9/9/07, Anthony wikimail@inbox.org wrote:
On 9/9/07, Casey Brown cbrown1023.ml@gmail.com wrote:
And most of the time (under normal circumstances), we do too, and we even give them a nice little e-mail back too. But of course... you would know nothing about this. I would ask you if you had ever e-mailed us, but I doubt I'd like the response I get. Rest assured, though, we work very hard on complaints, press inquires, and article problems (like BLP) that are e-mailed in to us.
Can you please blank the following pages:
On 9/9/07, Anthony wikimail@inbox.org wrote:
Shit...and can someone please blank that email, which I meant to send privately :)
On 9/9/07, Anthony wikimail@inbox.org wrote:
On 9/9/07, Casey Brown cbrown1023.ml@gmail.com wrote:
And most of the time (under normal circumstances), we do too, and we even give them a nice little e-mail back too. But of course... you would know nothing about this. I would ask you if you had ever e-mailed us, but I doubt I'd like the response I get. Rest assured, though, we work very hard on complaints, press inquires, and article problems (like BLP) that are e-mailed in to us.
Can you please blank the following pages:
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
Replied to privately, I'll work on it tomorrow (I'm currently travelling).
On 09/09/2007, Casey Brown cbrown1023.ml@gmail.com wrote:
On 9/9/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
Wikipaedia Review was rather nice to me... they removed things from their website upon request... or archived said things somewhere non-public... or something....
DeviantArt will even let a non DeviantArt member contact them representing someone else asking them to remove something from their website, and they will, no questions asked!
And most of the time (under normal circumstances), we do too, and we even give them a nice little e-mail back too. But of course... you would know nothing about this. I would ask you if you had ever e-mailed us, but I doubt I'd like the response I get. Rest assured, though, we work very hard on complaints, press inquires, and article problems (like BLP) that are e-mailed in to us.
'us' == OTRS???
Yes, I did e-mail a member of OTRS.
-- Casey Brown Cbrown1023
Note: This e-mail address is used for mailing lists. Personal emails sent to this address will probably get lost.