Wikipedia talk:Stable versions now/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 Archive 2 Archive 3 Archive 4

But whyyyyyyyyyyy?

I'm afraid I don't grok the rationale. This just seems like more instruction creep, more cumbersome stuff to juggle around manually, etc. The inert articles that go for months without editing have probably only been touched by a few people in their lifetime, and are likely in need of lots of improvement, so inertness is as bad as instability. The rapidly changing articles tend to have disputes going on (even minor ones) that would prevent stabilization, and these are the articles that get the most attention, so stabilization of slower moving articles won't make WP look any better.

Can someone give a few specific examples of articles which stabilization can help? Phr (talk) 10:36, 10 July 2006 (UTC)

I'd prefer to see other folks set out examples (See the section above). There are a couple of classes of article which would clearly benefit... One example is articles which get a steady flow of silly vandalism, for example Cheese. In three months 500 edits were made to Cheese. Yet the only changes [1]. It's important to note that changes *were* made, and some of them were made by anons. Semi-protection would have completely prevented new people from contributing, and wouldn't have even prevented all of the bad edits from reaching our readers [2][3]. I think it's important to not consider this an anti-vandalism proposal because it's benefits are not limited to reducing the harm of vandalism, that is just one example.
Beyond vandalism there are plenty of places where some good editor makes a change, only to have it pointed out as an error a few days later by another active editor... With stable versions we would give the contributors to an article a chance to check changes before we hand them to the general public, minimizing the harm from simple errors that can be easily caught.
Stable versions will also create regular milestones in an article's life. Today the few milestones that we have (WP:GA and WP:FAC for example) act as tremendous catalysts for improving the overall quality of an article. I think we can expect to see proposals to establish a new stable versions act as similar but smaller scale catalysts to cause people to read through an article, check it, and improve it. Milestones also provide a point for comparison: There are many articles that I'm not a primary contributor on, but I'd like to passively follow and help keep accurate... but trying to check every single diff is simply too much work. With stabilization I could simply wait for discussion to begin on a new stable version and then compare the development version with the current stable version then provide my input. I'd get the gratification of knowing my work helped keep the most public version accurate for all our readers, without having to dedicate my life to micromanaging the article.
I, and others, also expect to see a number of positive social effects, such as a reduced incentive to begin an edit war... but that is really getting off into the realm of speculation. I think that the places where we're sure it would help (vandalism), and where it seems very likely to help (improved ability to get a second opinion before a change goes live) justify trying it out, without getting into the more speculative gains. --Gmaxwell 16:53, 10 July 2006 (UTC)

As the main editor (if not the main vandalism reverter) of Cheese as it stands today, I'd love to see this system at least given a trial there. —Bunchofgrapes (talk) 03:31, 11 July 2006 (UTC)

"The inert articles that go for months without editing have probably only been touched by a few people in their lifetime, and are likely in need of lots of improvement, so inertness is as bad as instability." I beg to differ! Stubs or badly written articles which have been relatively untouched since creation will presumably not be candidates for stabiilization! Rather, as I read it, the proposal is to discourage ill-considered changes to mature articles on a fairly stable topic, while continuing to encourage rapid improvement of stubs and suchlike. ---CH 06:52, 16 July 2006 (UTC)
"trying to check every single diff is simply too much work." This is a very important point. In my user pages I have discussed a phenomenon I call edit creep, in which well-intentioned but inexperienced or careless writers introduce new material into a mature article which seriously disturbs the existing structure. This is particularly frustrating to those who have helped to raise up a mature article because it can quickly render a recent excellently written article semi-incoherent. To name just one type of example, I have all to often seen careless writers insert an otherwise acceptable paragraph after previous paragraph N which destroys the previous seque into paragraph N+1, so that when the reader reaches the paragraph N+2 (formerly N+1) he is disoriented. Trying to clean up even a weeks worth of such edits at an article like Albert Einstein is such a nightmarish task that few dare attempt it. (Indeed, one would have to be a glutton for punishement, since that article is in a vandalized state, by my estimate from hard data, something like 2-10% of the time, which is appalling in such a visible article. This was my estimate from actually computing times between vandalizations and reversions in minutes over several days in this article.) ---CH 07:03, 16 July 2006 (UTC)

Differing goals?

Reading through the above, I think some of the disagreement might be a result of folks having different goals in mind. I think clarifying the goals might help. I see two similar, but not identical, goals:

1) Some folks want stable/static versions so that the general public does not see Wikipedia articles containing the ravings of any random lunatic with a web browser.

2) Some folks want stable/static versions so that a subset of Wikipedia articles can be advanced to a pristine state, subject to neither casual vandalism nor degradation of their brilliant prose.

Completely ignoring implementation for the moment, let's imagine there's a Wikipedia that satisfies #1 and think about how different it is from the current Wikipedia. Similarly, a Wikipedia satisfying #2.

I think the crux of #1 is "edits from random lunatics should not be immediately visible". But that's what a wiki is, you say. However, the point is not to make articles uneditable — just to have some mechanism to distinguish a "working" version from a generally "visible" version and have casual viewers directed to the generally "visible" version. Forking a "stable" version is one way to do this, but I don't think it's necessary. The "visible" version could just be a version picked from the history. There could still be an "edit this page" link on the generally visible version. What exactly happens if you click this link can be worked out (if the working version is different, perhaps you're first shown the current working version with or without diffs relative to the "visible" version). It doesn't seem to me that a Wikipedia that works like this would need to be tremendously different from the current one (for example, see my proposal for how I think this could work at Wikipedia talk:Stable versions/archive2#forking considered harmful). However it's implemented, I think one of the primary benefits of this kind of mechanism is that we reduce the incentive to vandalize.

I think the premise behind #2 is that "stable versions should be the result of a strict review/editing process and should therefore not be directly editable". Fundamentally, I think this means either the stable version is permanently static (essentially protected) or must be a fork with further changes directed to a separate "working" version which might at some future time go through the same review/editing process to become a new "stable" version. However its done, I think this sort of review/edit process has to be labor intensive and can only be applied to a small subset of Wikipedia articles. We could choose to implement this right now by simply protecting "stable" articles (with further changes discussed on the talk page).

If these really are two separate goals, I think we could consider splitting this discussion into two separate threads that might lead to two complementary solutions. -- Rick Block (talk) 19:00, 15 July 2006 (UTC)

Rick noticed a useful and important distinction which I missed. I second the motion. Good catch. ---CH 07:32, 16 July 2006 (UTC)
It would appear to me that what you've described in #1 would have all the negatives of this proposal, minus some UI issues... and it would require a non-completely-trivial amount of software alteration to add the UI features. The purpose of this proposal was to produce a solution which avoids the obvious risks and would allow us to learn the answers to questions like your "happens if you click this link" before someone sits down and writes code which we might find poorly matches our needs. If this proposal works out, I'm sure we would make the sort of UI enhancements you've described, as such features would snap right into this model.
As far as #2 goes, this proposal isn't trying to solve that... none of us know how to make a 'strict review' process work in our environment. As you recognize, it is a hard problem which may require forking (which has many downsides). I'm not sure that we're ready for #2. However, whatever form #2 takes such solutions will benefit from mildly reviewed versions (we'll call it class 1 stability, thats what this proposal provides).
Perhaps you're mistaking that fact that this proposal protects the selected stable version as evidence of this attempting to be something of a class two proposal... it's not, the protection is only really there to prevent people from editing the stable version and thus creating a fork. The proposal avoids becoming a class 2 stability system by requiring that it be turned off in the face of a content dispute and by avoiding complex editorial criteria.--Gmaxwell 04:58, 17 July 2006 (UTC)
I was actually trying to help the folks who have been commenting think about what they want to accomplish rather than making a comment on this proposal. Thinking about this specific proposal in light of these "classes", I think the mechanisms sound much more like a class 2 than class 1 system (consensus-based process to elect a stable version followed by a fork). In my opinion, the critical aspects of a class 1 system would be:
  • Default view is the stable view (necessary to be a vandalism inhibitor)
  • No forking
  • Massively scaleable (so can be applied to many, if not most, articles)
This proposal achieves the first (at the expense of forking the development version elsewhere) but not the second or third.
Another way to look at this whole problem is from the viewpoint of the software itself. Currently the "protection" options are (in increasingly protective order):
  1. No protection - anyone writes anything which immediately goes live. This is the default Wikipedia behavior in effect for nearly all of the 1.2M articles.
  2. Semi-protection - only logged in users can write, and what they write immediately goes live.
  3. Fully protected - only sysops can write, and what they write immediately goes live.
Note that none of these provide any sort of software assist for any kind of review mechanism. Creating a mechanism that separates the ability to edit from the ability to "post" (make the current version "go live") would be generally useful not just at Wikipedia but potentially anywhere any sort of editorial control might be required. If these two abilities were separable (by "user level") Wikipedia could institute a new level of "protection" (probably replacing the current semi-protection level) requiring edits to be OKd (in my proposal, by a new permission fairly freely available to logged in users). Other wikis might be set up differently - perhaps only bureaucrats can "approve" edits (this would be a "senior editor" sort of model). If the approval level can vary article by article, rather than globally, perhaps Wikipedia would change "full protection" to "editable by anyone, but with change approval by sysop required".
I completely understand the sentiment that we would like to try something that does not require software changes. On the other hand, this proposal doesn't actually sound much different from simply protecting articles (rather than "editable version here" the banner would say "propose changes on talk page" - both require an admin to effect any change). -- Rick Block (talk) 14:04, 17 July 2006 (UTC)
I think there is a big difference between 'discuss changes' and 'make changes to this page here'... The first inhibits "Be Bold". In any case, as soon as you start speculating about software changes you're back in the realm of 1,001 proposals, few of which have been implemented, and none activated. This is not a new matter. Over a year ago we all though we'd have some magic software "in a few weeks". I'm concerned that people who are proposing review processes which can only be achieved with software are making proposals that we can not adopt because we can't be confident if they are appropriate until the software is implemented, and no one wants to implement the software until we're confident that the solution is appropriate. Do you really think that it is realistic to achieve a final solution in a single step? Almost nothing else here was achieved by a single huge step, especially nothing with complex social implications.--Gmaxwell 15:36, 17 July 2006 (UTC)
Brion has recently said "it's being worked on", although hasn't said exactly what "it" is. I'm not sure how to interpret this, but taken at face value I think means some sort of software change really is reasonably imminent. I agree it's been "in a few weeks" for an awfully long time. Perhaps I'm overly confident, but I do think separating editing permission from "posting" permission would be essentially the right software change. Of course, I have no idea if that's actually what's "being worked on". I'm willing to wait a while longer, at least until Brion explains what change is in the works. -- Rick Block (talk) 18:54, 17 July 2006 (UTC)

Implimentation

I object to the implimentation of this proposal, as a number of people have raised serious issues with it which have been totally ignored. Raul654 01:05, 25 July 2006 (UTC)

At the least it should have been discussed with the 'cheese regulars' on the talk page first. Though I can't imagine it would have been popular given that the page is still undergoing active editing. --CBD 10:36, 25 July 2006 (UTC)

ITAG and ITAC

  • "Is This Article Good?"
  • "Is This Article Comprehensive?"

Those are the first two questions that should be asked whenever the stabilisation of an article is proposed. One of the biggest objections against stable versions is that they restrict the good edits along with the bad. Well, that's why an article should only be stabilised when there is a very low possibility that any large good edits could be made in the near future. That means two things: First, the article must already be very good. Second, the article must be comprehensive. Together, those two conditions ensure that we're dealing with an article that is bound to get mostly bad edits in the future. -- Nikodemos 14:09, 27 July 2006 (UTC)

Average End Quality Hypothesis (take 2)

Since there were no comments when this was posted as a link, I am going to copy the text here in its entirety. -- Nikodemos 14:19, 27 July 2006 (UTC)

One of the assumptions of Wikipedia is that continual editing by multiple users will result in a continual increase in the quality of an article. This has proven true as a general trend. However, I do not believe adequate attention has been given to important exceptions, and, most significantly, to the rate of improvement in article quality.

I have done a bit of research and reflection, and I have reached a conclusion that I call the Average End Quality (AEQ) Hypothesis. It is based on the following observation:

As the quality of an article improves, the rate of improvement declines.

In other words, if Q(t) is the quality of an article at time t, then Q'(t) is positive but downward sloping, or Q"(t)<0. The graph of quality over time looks something like this:

Notice that the quality function appears to level off. This is not accidental. It is a well known fact that not all edits improve the quality of an article; some, in fact, detract from quality. Not all of these are simple vandalism that gets reverted as a matter of course. Some are subtle insertions of uncited speculation, POV, reorganizations of material that disrupt the flow of an article, bad grammar, and so on. They are not enough to have a visible effect on the upward trend of quality for new and short articles, but once an article gets very lengthy and detailed it becomes increasingly difficult to copyedit and remove errors buried deep inside the long text. As a result, bad edits are able to balance out good work and article quality levels off at a value I have termed the Average End Quality (AEQ).

Of course, editing never actually stops. The actual quality of a given article may spike above or dip below the AEQ for various periods of time. But whenever actual quality goes above the AEQ, bad editing gains an upper hand over good editing and drives it back down. Likewise, whenever actual quality goes below the AEQ, good editing gains an upper hand over bad editing and pushes it back up. In other words, if an article gets too good then most editors will declare "mission accomplished" and leave, allowing random bad edits to erode its quality; but if the article gets too bad, a large number of editors will be attracted in an attempt to fix it.

Thus, the quality of most detailed, lengthy articles oscillates around the Average End Quality:

Some might say that the AEQ is good enough, so there is really no problem. However, this property of Wikipedia results in a lot of wasted effort from editors who work hard to get the quality of an article above the AEQ, only to have it eroded down over the next few months. And, in some cases, articles that were once of a very high quality have been reduced to near incoherence. Given all this, I propose that the very best articles on Wikipedia be placed under permanent page protection. After all, the whole reason why people are free to edit articles on Wikipedia is because this policy results in an overall increase in article quality. But if we have good reason to believe that it will result in a decrease in quality for articles X, Y and Z, then it is only reasonable to place articles X, Y and Z under some sort of protection:

Such a protection policy should only apply to articles of exceptional quality, and it should not be a blanket ban on all edits; rather, there should be a requirement that any new edits must undergo some review process before being allowed. This could be the first step towards Wikipedia 1.0: At first, only a handful of articles would have the required quality to be protected, but more would accumulate over time.

I am sure this idea can spark endless controversy. Fortunately, however, it is not just a matter of opinion. There is, in fact, a very sure way to tell whether the Average End Quality Hypothesis is true or false. What articles are recognized as the very best on Wikipedia? Featured articles, of course. Let us do a survey of former featured articles and determine whether their quality has increased or decreased on average since the day they were featured. If it has decreased, then it is true that continual editing usually lowers the quality of our best articles, and therefore it is a good idea to implement some sort of protection policy on them. -- Nikodemos 14:22, 27 July 2006 (UTC)


You could extend this argument further... Article quality doesn't actually increase smoothly, it moves in bursts and sometimes suffers long term regressions. This can be easily substantiated by looking at edit timestamps and reverts which jump back months. What is often the case is that quality wanders upwards until it reaches a local maxima. The quality then wanders around that point looking like your average quality graph, it may regress and begin the process over again. Hopefully something will happen like a FA or a GA nomination to break it out of the local maxima and kick the article upwards towards another local maxima. I would hope that by keeping our best (by consensus) version highlighted (via it being the stable version) that we can avoid quality regressions and stay focused on making the leap towards the next quality level. --Gmaxwell 20:38, 27 July 2006 (UTC)


Your model is severely flawed, since even with protection, article quality declines over time as the article slowly becomes out of date. - Samsara (talk • contribs) 22:38, 30 July 2006 (UTC)
That's true in many cases, but often article content is unlikely to need updating—topics like the Battle of Gettysburg or A Tale of Two Cities aren't going to change much. And even general topics like welding or calculus or United States aren't going to need significant updating on a frequent basis. Obviously articles like George W. Bush and articles on events of the past several years are going to need frequent updating, but fortunately, this stable versions proposal allows the article to be unlocked when updates need to occur. --Spangineeres (háblame) 22:51, 30 July 2006 (UTC)
All science articles need updating, for instance. Taking the example of World War II articles, I wonder how much updating will afflict even these; take Bad Nenndorf as a recent example. There is still research going into historical documents; there are archives that have not been thoroughly studied yet. More seriously, there is no way of measuring the gradient of the curve you've drawn (what would the units even be?), or, equivalently, any way to know where you are on the curve. Are you going to make guesses? Especially the comprehensiveness of an article is difficult to assess. - Samsara (talk • contribs) 23:55, 30 July 2006 (UTC)
If we were going to be pedantic, we could also say that there is an ethical problem here, in that you're deciding that future generations aren't allowed to edit the article. Note that "generation" may mean something different on Wikipedia; some Wikipedians may be active for less than two years, for example. - Samsara (talk • contribs) 11:34, 31 July 2006 (UTC)

The whole idea of Average End Quality is based on an assumption (and I haven't analyzed the data, but I assume it's an assumption) that the asymptote is a line of slope 0. Couldn't the limit actually be more like a ln(x), or ln(ln(x)) - i.e. on average still increase over time but with a continuously decreasing rate? It's been my experience with the Monty Hall problem article (perhaps one of the most edited feature articles) that its quality does vary, but that it may overall still be improving.

I think rather than prevent changes what we actually need is some way to help ensure the individual changes are positive, not negative. We currently exert no control over changes, willingly accepting both positive and negative changes. The rapid rate of improvement at the beginning of the lifetime of most articles supports this as a reasonable mechanism. As articles improve, I think the issue is they reach a point where "random" changes aren't necessarily an improvement and accepting any change is no longer the right strategy. We haven't tried it, but I think the next "loosest" strategy is to accept only "reviewed" changes (which is what all this "stable version" stuff is really about). My question is what is the next most minimally "tighter" strategy? Most of these proposals go from "accept anything" all the way to "committee approves everything" which seems to me to be a way bigger step than is necessary. My thought is the next step should be "accept most". The only issue is that differentially accepting changes means we have to somehow split the notion of editing from the notion of accepting. I think this is the crux of all the stable version proposals, but I'd like to see a mechanism that supports varying degrees of control. The control aspect boils down to "who gets to accept"? Again, most of the current proposals go way overboard changing the current "anyone with a browser" to "only admins". If we explicitly create a new permission level for "edit accepter" we could allow "most" editors to be accepters slightly moving the paradigm from "accept all changes" to "accept most changes". Would this prevent most "negative" changes? I don't know. But I think it might.

IMO, the goal is not 0 changes (AEQ asymptote = 0), but continual improvement (AEQ asymptote > 0, implying monotonically increasing quality). -- Rick Block (talk) 14:26, 31 July 2006 (UTC)

Rick's ideas seem very much on the right track. Any article has potential for improvement and so there will always be the potential for good changes to be accepted. Most importantly, there do need to be stages of edit controls. Clearly undeveloped stubs and early articles should usually have no editing restrictions. When an article starts to shape up, how should the next stage of edit control work? I think it could be as simple as having the draft version "seconded" by a non-new user who hasn't edited the article since the last stable version.
Because it's so easy to get a userid, I like the idea of introducing an "acceptor" permission/capability. The next tighter stage of control might be requring "seconding" by such an acceptor rather than just any non-new user. At some point (featured article or later), requiring acceptance by multiple acceptors or admins may be needed. For already-high-quality articles, having multiple reliable people review it is a good idea because any one person is subject to blind spots, quirks, and biases. -R. S. Shaw 19:48, 31 July 2006 (UTC)

Comments from the peanut gallery

Way to be bold! I was on IRC and had a few questions and JesseW was great about explaining the goals and aims of the policy. Per his request, I'll list my questions and comments.

  • I think it's a good proposal in theory. In practise, however, I feel that the policy itself needs to be a bit more specific.
    • Who qualifies as an "active editor" that will be able to participate in the stabilisation process?
      • Will there be general (or stringent) criterion for number of edits, length of edits, time spent editing, etc?
        • If there are criterion, how does this stand up against the credo that "anyone can edit?"
        • If there are not, what prevents people with a POV from editing once and attempting to sway consensus?
    • Is the stablisation voting process based on the number of votes or is it based on the logical arguments presented? Are votes counted more from who've contributed more to the articlce?
      • Is it even a voting process?
        • If so, does consensus happen at 51% in favor or more?
        • Who determines consensus?
    • I'm just assuming, but I imagine stabilisation will be predominently proposed with controversial articles, even though that might not be the original intention.
    • How is reasonable quality determined? Will there be a rubric or criterion for accepting or rejecting a stabilisation proposal?
    • How is active editing determined? Is daily editing necessary or will there be a larger timeframe allotted?
    • I've a few questions about what happens once stabilisation is acheived
      • How much time will pass between revisions ofstabilised articles?
      • Who determines what edits are worthy to be inserted into the new revision?
        • How are the editors that make this determination selected?
      • Where do the edits go when they are made in between revisions?

Sorry about all the questions and don't feel at all pressured to answer them. Cheers! hoopydinkConas tá tú? 21:04, 9 July 2006 (UTC)


That's okay, questions are good.
  • I didn't for see *any* requirement for participation. An admin must perform the stabilization, but beyond that anyone can participate. There is a requirement that the article itself must be "actively edited". I've left that up to interpretation. If someone shows up and says that the article isn't active enough, then that's a sufficient reason not to stabilize. We can figure out more specific rules over time if they are needed.
  • It's not a voting process. I hope from the language of the text that it's clear that I'm proposing we look for something very close to complete consensus (100%). If someone objects we should probably not have a stable version, although if, for example, some user made it a practice to go around opposing all stable version proposals because he disagreed with the entire process then it would be appropriate to ignore his position. The same would be true for a new user with no edits who opposes without explanation. We should try to be as inclusive as possible but temper it with rationality.
  • Stabilization in this current proposal is expressly not intended for controversial articles. The requirement for a high degree of consensus coupled with an ease of destabilizing will make it unsuitable for controversial articles. Most wikipedia articles are not controversial (and I can back that up with data). Attempts to solve the problem for controversial articles have caused all the previous proposals to be far to complex to implement (i.e. proposals involving massive modifications to mediawiki to implement slashdot like 'karma'). In the future this system might be expanded to cover more articles, or a new system introduced. Please don't oppose a good solution because it isn't a cure-all. :)
  • The decision is made by interested Wikipedia editors and must include at least one 'outside' admin.
  • Daily editing is not required. I don't want stable versions to rot.. if an article isn't getting enough attention to get a couple of edits per month, and transition to a new stable version every three months at the most, then it should probably not be stabilized. I want good judgment to apply, as long as no one is objecting it's okay if the activity level is somewhat low... It will depend on the article and the community of editors around the article.
  • The time between stable version updates will depend on the editing community of the article, it is their discretion. When we have more experience with this system we could make more concrete recommendations. If I were to speculate, I would say that it should not average out any faster than once a week, nor slower than once every three months. We want the process to be as often as possible while still allowing interested persons to make important corrections before new content goes live.
  • No one person determines what edits are worthy. Editing continues on the development page like any other article and is subject to the normal editing practices on Wikipedia. Any wikipedia user can provide input on the talk page to help determine the next stable version (which most be a recent edition of the development version). If no agreement can be reached, the article is destabilized and becomes a normal article again.
  • Participants are self-selecting interested parties, with the exception of the admin required to perform the initial stabilization whom may have found the discussion through the template or may have been summoned by one of the interested editors.
  • Interm edits go to the development version, a separate page open to editing by all. A notice is placed on both versions informing viewers about the other's existence. You can see this on User:Gmaxwell. The templates will likely be adjusted to be more visually attractive before we start using this in earnest, the templates merely demonstrate the functionality (cross page diffs, for example).
Feel free to ask questions, I hope I've answered the ones you've posed. --Gmaxwell 21:43, 9 July 2006 (UTC)
You definitely answered my questions, especially when you mentioned that there would be a development page that could be edited at a whim. The proposal seems like a great stopgap for now hoopydinkConas tá tú? 22:42, 9 July 2006 (UTC)
Gmaxwell wrote "Most wikipedia articles are not controversial (and I can back that up with data)." Do tell! Please drop by my user talk page and leave a link; I'm trying to collect statistics by the sensible method of collecting data tabulated by others :-/ ---CH 08:24, 16 July 2006 (UTC)
"Stable" == "dead". Unless Wikipedia suddenly develops the ability to authoritatively fact-check and copyedit an article and therefore entomb it in stability, what purpose does this serve? Dead-tree articles annoy me now; every time I see a typo or an unfortunate phrasing I itch for the "edit" tab at the top of the screen. --Wtshymanski 01:22, 1 August 2006 (UTC)
I fail to see the difference between the above argument and the parallel argument "Anyone can edit" == "pure chaos". Have you no trust in our communities commitment? --Gmaxwell 07:34, 1 August 2006 (UTC)

Elephant a stable version?

Since when? Where's the support to roll this out? --badlydrawnjeff talk 02:17, 2 August 2006 (UTC)

Wholly unwiki

Its wholly unwiki to protect an article. (Yes, it means protecting the article). I might like to see something where there's a notice across the top pointing to a specific version of the article in history as being a 'good version' or something, but NOT ever to have the article itself protected from changes. It defeats the purpose of a wiki. If people are then concerned vandals will just delete/damage the message pointing to the stable version, well perhaps a software implimentation should be waited for rather than protecting articles like Cheese before this even has a consensus. Kevin_b_er 01:14, 25 July 2006 (UTC)

I am nto sure there is much point or even benifit to the "just point to a good version" approach, I think its clumsy probbly wouls make us look bad and does not achieve any of the goals of having stable versions. I think if we are going to do this there should be NO notion of "which version if the default one shown. The editable or stabe version appearing should be a configurable option. I suppose the pointer to the history and auto displying it for some users who would like that coudl be done with javascript without modifying mediawiki, but I think we should probbly just wait for a technical solution. Dalf | Talk 01:52, 25 July 2006 (UTC)
If its 'configurable' then you immediatly get to the question of what anonymous people, who are just passing through get? Do they get an uneditable page, and have to look around for the page they can edit (which then doesn't appear on the main one), or do they get a page which, unless there's recent heavy vandalism or a nasty edit war, is a page that anyone can edit. I'm very opposed to seeing anything where everyone just sees an uneditable page. I understand others have other reasons for opposing the idea, but I'm not decided on the other reasoning. What I am decided on is that the default state of an article on wikipedia should never be a protected page. Kevin_b_er 04:36, 25 July 2006 (UTC)

As I said above: The purpose of wikipedia is to provide good information. Nothing more, nothing less. How we do that is entirely up to us and always open to revision. I am sick and tired of fanatical ideological opposition to any restriction on the free editing of articles. If an article is already very good and further editing tends to make it worse, it's time to stop. Wikipedia is not dogma! (hey, that's a catchy slogan) -- Nikodemos 13:39, 27 July 2006 (UTC)

"How we do that is entirely up to us and always open to revision." <-- that is simply not true. Zocky | picture popups 13:56, 27 July 2006 (UTC)
Why not? Wikipedia is not open to all edits just for the sake of being open to all edits. The wiki is a means, not an end. The end purpose is to build a good encyclopedia. -- Nikodemos 14:01, 27 July 2006 (UTC)
"The ability of anyone to edit" is one of the foundation issues of the project. Zocky | picture popups 18:08, 27 July 2006 (UTC)
Stable versions doesn't deny anyone the ability to edit our articles. Although it may delay the time until their edits are distributed by default to the general public. Saying that stable versions denies people the ability to edit is like claiming that the fact that an article isn't transcluded into the main page is a restriction on anyone's ability to edit it. :) If you really want to go all wikipurist you should protest having seperate article and discussion pages or the fact that we permit images (which are functionally uneditable in many regards) both of which are a substantial break from historic Wikis. --Gmaxwell 20:30, 27 July 2006 (UTC)
I was merely pointing out that we are not totally unrestricted in how we go about writing the encyclopedia. Zocky | picture popups 20:40, 27 July 2006 (UTC)
Oh, and of course, pointing out that wiki is one of the foundation issues, so "The wiki is a means, not an end." is not entirely true either. I don't expect us to close down the site for editing, start selling ads, and hire hundreds of experts from the proceeds to finish the encyclopedia any time soon. Zocky | picture popups 20:44, 27 July 2006 (UTC)
If it could better serve the goals of the Foundation: free Knowledge to everyone on the planet in their language, then the board would be remiss in not considering that option. It all comes down to whether you think open editing or the actual free information is more important. Personally I think it should be blatantly obvious which should take precendence, but some people are so caught up in the social experiement bit that they lose sight of what's really important. Now that's just to get people's attention and establish the extremes. Instead, if there is a way to have both free editing and higher information quality, which proposals like this allow, then not pursuing that is damaging to the mission. - Taxman Talk 22:41, 27 July 2006 (UTC)
You may be entirely right, but wikipedia is where the encyclopedia is written with a wiki. Maybe another website should be used for that project, like nupedia, which is now unused? Zocky | picture popups 23:00, 27 July 2006 (UTC)
And you seem to be completely misunderstanding me. I'm in no way "caught in the social experiment". I have been following how Wikipedia works for a long time, and I think I have an informed opinion about what makes it better and what makes it worse. This sounds like it would make it slightly worse for a time, until it was abandoned as unworkable. We simply don't have the manpower to do anything like this on any significant number of pages, without either the promotion to a stable version becoming automatic (which would defeat only the most stupid of vandals, and provoke the rest into becoming more devious), or having greatly different stable and live versions (which would constitute a fork and make editing impractical for anybody who read the stable version first). Zocky | picture popups 23:10, 27 July 2006 (UTC)
That I will fully agree with. If stable versions lag the development version too far in too many cases, the extra work could more than cancel out the benefits. That would represent a failure in the system, and something reasonably easy to measure and demonstrate. I believe, and nothing but testing can bear out, that the savings from stable versions will so far outweigh the efforts to keep stable versions reasonably up to date that the results will be well worth it. Only time and testing will tell, but 'slightly worse for a time' is well worth trying for such strong advantages. Even moreso for small controlled testing. We didn't get where we are by trying only the same old thing. Wikipedia wasn't predicted to be slightly worse, it was predicted to be outright disaster. - Taxman Talk 23:38, 27 July 2006 (UTC)
'Welcome to Wikipedia, the free encyclopedia that anyone can edit'. Cynical 20:37, 30 July 2006 (UTC)
Try: 'Welcome to Wikipedia, the free encyclopedia that anyone can request a change to'. -- Kevin_b_er 02:17, 2 August 2006 (UTC)
I have to agree that this is a very bad idea, and I think it will have the immediate effect of reducing the amount of development that's done an articles simply because it will be more difficult. I can also simply envision the disputes arising about what constitutes the "proper" stable version of an article. Per Zocky and Kevin b er, this is unwiki, and is best put into practice by exercising the right to fork. siafu 05:21, 2 August 2006 (UTC)

Obsolete

Won't this make wikipedia obselete? After all this IS the internet. When news breaks, I won't be able to edit an article right away, I will have to wait until whenever the development version is made into the stable version (if ever). This is going to slow down wikipedia. There won't be anymore instant graftification. Used to be that if someone saw an error, they could fix it. Just like that and it was fixed for all to see. Now you submit a correction and have to wait a few weeks to see if it actually makes it into the article. Who likes to wait to see the fruit of their efforts? Wikipedia got past a million articles with the open model, why change now?--God Ω War 05:20, 2 August 2006 (UTC)

I agree. The effect is something like creating a de facto editorial committee on each article; no more being bold. siafu 05:22, 2 August 2006 (UTC)
Just learned of the proposal after noticing some odd changes to Yahoo! on my watchlist. I believe that the stable article proposal is good for well-developed, moderately vandalized articles concerning topics that do not change relatively rapidly, like Yahoo!. Most Yahoo!-related events are not big news and do not need to migrate into the stable version immediately. If something really traumatic were to happen to Yahoo! (for example, unexpected bankruptcy or the accidental death of a senior executive) then an admin should have discretion under the guideline to remove the article protection so that all users can update the article based on news as it develops in real time.
Obviously, I do not believe the stable articles proposal is appropriate for most articles, which are either in a continuing state of development, cover breaking news of various types, or are not vandalized often enough to justify such a high standard of protection. --Coolcaesar 05:27, 2 August 2006 (UTC)

Wikipedia:Stabilizing featured articles

Ladies and gentlemen, I've cranked out the first draft of my proposal. I'm about to get to a couple of the technical details, but the idea is there. I would appreciate feedback from all on the proposal's talk page. Thank you, JDoorjam Talk 05:34, 2 August 2006 (UTC)

Straw poll!

I'm wondering what people think about this so far, now that we've had a fair bit of discussion.

Support

  • strongly support: the WP community desparately needs to address the issue of the notorious instability of even formerly excellent articles, since this is one of the most un-nerving aspects of WP for newcomers and old-timers alike, and external critics are quick to list instability as one of their major reasons for doubting the utility of WP as a serious encyclopedia. Sigh... am I really the only remaining supporter of the notion of finally getting serious about and stop merely paying lip service to the stated mission of Wikipedia? ---CH 07:18, 16 July 2006 (UTC)
  • support ... the point of wikipedia is to produce an encyclopedia, wiki is the means not the end. While we will never be finished (at least until humanity is extinct), we should be striving for that. As most organizations find, what works well in the beginning is not the same as what works well in maturity. Some form of stable versions is required. The stable version should be the default precisely because most users of wikipedia are readers not editors. It would be nice to have a toggle switch for logged in users to set in their preference, but the general public should first see the vetted version rather than what Joe Bob Random Vandal decides as a practical joke should be the most recent version. It would also be nice for when a reader wants to "edit" the stable version, that they are taken to a working version, with a difference between the versions, but that also must wait for developers, for whom stable versions has clearly not been a priority. dml 13:27, 16 July 2006 (UTC)
  • support. I spend a lot of time reverting POV pushing edits to controversial articles and this would help a lot. --Ideogram 13:32, 16 July 2006 (UTC)
    Actually, controversial articles will never become stable under this proposal, as someone will always oppose its stabilization. --Conti|✉ 13:35, 16 July 2006 (UTC)
    Is unanimity required for stabilization? In the articles I'm dealing with it's usually one or two troublemakers fighting against the consensus of long-time editors. --Ideogram 13:37, 16 July 2006 (UTC)
    See #More questions, first question. --Conti|✉ 13:41, 16 July 2006 (UTC)
    Ok, this doesn't solve the problem I thought it was supposed to solve. I withdraw my support. --Ideogram 13:49, 16 July 2006 (UTC)
    Must something solve all problems in order to gain your support? :) What this would do is dampen the impact of drive by POV insertions... Perhaps that isn't a concern where you edit. ::shrugs::
  • Support. I support it, of course. Just today we see another example of substantial harm come from our lack of public-facing stable versions in the 'news' [4].--Gmaxwell 04:45, 17 July 2006 (UTC)
  • If you're not aware that I support, please read the discussion. --Spangineeres (háblame) 17:20, 17 July 2006 (UTC)
  • Support. I think it's important to keep the history readily available from the default (stable) version, and even more important to nowiki the categories, and if technical support can be implemented soon for a separate namespace, all the better. But even without those things, we need to get some sort of process of this kind started, at least as a test.--ragesoss 02:50, 18 July 2006 (UTC)
  • Support per above.Voice-of-All 21:46, 23 July 2006 (UTC)
  • Support with the comment that I applaud all of the contributors, both for and against this precise proposal, because it has engendered a very significant conversation about the trend of future editing. I would also like to point out that data-driven decisionmaking about this issue is much more valid than anecdotal evidence and assumptions. Let's keep working it out and talking it through.--Brad Patrick 22:56, 26 July 2006 (UTC)
  • Strongly support. The purpose of wikipedia is to provide good information. Nothing more, nothing less. How we do that is entirely up to us and always open to revision. I am sick and tired of fanatical ideological opposition to any restriction on the free editing of articles. If an article is already very good and further editing tends to make it worse, it's time to stop. -- Nikodemos 13:36, 27 July 2006 (UTC)
  • Support good proposal. Keeps version protected from edit wars, POV-pushing, vandalism, etc. Polonium 00:17, 29 July 2006 (UTC)
  • SUPPORT Makes WP a better place for visitors. No ugly vandalism to look at. GangstaEB help me improve! 11:10, 31 July 2006 (UTC)
  • 'Support Jaranda wat's sup 04:01, 2 August 2006 (UTC)

Oppose

  • It would be foolish to implement this as it's currently proposed. Not only are there technical problems ([[ArticleName/development]] is not a subpage), but the whole process needs to be thought out more carefully. I like JDoorjam's proposals much better. —Keenan Pepper 18:06, 14 July 2006 (UTC)
    • It's been a crazy week at work and I haven't had time to yet, but I'll write it up as a "real" proposal this weekend. I'll mention it here once she's up and running. JDoorjam Talk 21:19, 14 July 2006 (UTC)
  • I dislike this proposal greatly for a number of reasons that others have already stated. I had previously suggested a stable version system requiring only a modicum of technical changes (Jimbo's response: "I more or less like it."). Raul654 21:12, 14 July 2006 (UTC)
    • I'm sorry - I assume I'm misunderstanding, but as I read your suggestion (linked above) it looks identical to this proposal, except that this proposal kludges around the lack of even "a modicum" of technical changes yet to allow us to put your idea into place. Do you have objections to the proposal other than the kludges we use to avoid requiring MediaWiki changes? If you do, please state them, because I can't identify any from what you've said so far... JesseW, the juggling janitor 21:31, 14 July 2006 (UTC)
      • Technical kludges of this proposal aside, I object to the principle of moving article developement to a subpage, instead of doing it in place everyone expects (the main namespace) (in other words, without changing mediawiki, it would be smarter to put the stable version on a subpage and leave the development article in the main namespace instead of vice versa). My proposal would guarentee that the stable version cannot become a fork; despite lip-service to the contrary, this proposal almost guarentees that it will become a fork. This is not a minor technical issue - it's an issue of supreme importance. If the current version of the software cannot solve them without the horrible kludges this proposal requires, then stable versions will have to wait. It would be smarter to wait until the software can do it right than do it half-assed with kludges to get around hte lack of support. Raul654 21:35, 14 July 2006 (UTC)
        • I'm not sure what the point of a stable vers is if no one is ever going to see them. Lets face it no one (especially not users who don't knwo aobut sub pages) is likley to often click on the "go to stable version" link or whatever we give them. I think we should be thinkin not in terms of, which one is in the main name space, but in terms of some sort of configurable prefrence for which version you get. Dalf | Talk 07:56, 15 July 2006 (UTC)
  • I agree with Keenan Pepper and also prefer JDoorjam's proposal. — getcrunk what?! 22:51, 14 July 2006 (UTC)
  • Wikipedia's False Prophet holla at me, I like the idea of creating a subpage that has a stable version, but to make it the main version is destroying the basic idea of Wikipedia. The slogan is "the free encyclopedia that anyone can edit" and it would be very misleading to stand by that and keep this. I'm sure a lot of editors joined because they saw the edit button, tried it, and saw it worked and stayed. I know thats why I joined.Wikipedia's False Prophet holla at me 03:02, 15 July 2006 (UTC)
  • Oppose, although I will strongly consider changing to support if the proposal is changed so that the stable version is not the default displayed, or if the software allows users to set a preference for which is displayed. There are a couple of other kinks but nothing fatal, I do like the idea of stable versions in principle. --bainer (talk) 08:11, 15 July 2006 (UTC)
  • Oppose - Either JDoorjam's or Raul654's proposed systems would be better. We should use some method which continues to display the editable version by default and have stable copies which can be checked by those who think there might be something inaccurate in the primary or even chosen as an option to display by default instead of the editable version. I could only accept a methodology which 'locked down' the default page from editing if it were reserved for articles of the utmost quality (beyond even 'Featured articles') that were unlikely to require many changes in the future. --CBD 13:04, 15 July 2006 (UTC)
  • Oppose the proposal as currently defined but support JDoorjam idea. The main article must be editable in the spirit of Wiki, but having a link to some stable version for those who want to have a gurantee of security is nice. In the longer run, I would recommend some kind of preference tool available even to unregistered users allowing them to opt for seeing the stable version as default. This is an approach I was going to suggest myself after reading the Signpost story :) --Piotr Konieczny aka Prokonsul Piotrus Talk 16:49, 15 July 2006 (UTC)
    • I know it has been said before, but Wikipedia is, foremost, an encyclopedia. We accept the WikiWays because they are very useful, not because we are bound to them. That said, this proposal is more wiki than some of our alternatives in use today (such as semi-protection). --Gmaxwell 15:41, 17 July 2006 (UTC)
  • Strong Oppose. 'Welcome to Wikipedia, the free encyclopedia that anyone can edit'. Enough said. Making people edit a hidden-in-subpages, not-visible-to-the-public version is inconsistent with Wikipedia's goal. Were the 'stable' version to be the subpage (ie the editable version would be the actual article) then it would be fine, but it's not so it isn't. Cynical 20:01, 16 July 2006 (UTC)
    • Should we be shocked that something new has failed to gain the support of the cynical? ;) hehe More seriously, what about this proposal (which includes an edit notice more prominate than our current edit this page) makes the development version hidden?--Gmaxwell 15:41, 17 July 2006 (UTC)
      • I'm not against having a 'stable' version as such, but I think that the editable version of, say, the article on Paris, should ALWAYS be the one that is displayed when someone types 'Paris' into the sidebar. Yes, in theory it is still possible for anyone to edit the 'development' version, but the obstacles present both practical difficulties and emotional discouragement. If a person sees a sentence in an article that they could make better, at the moment they just click 'edit' and do it - if they have to jump through hoops follow this proposal then they probably won't bother, since they spend five times as long going through menus as they would actually making their edit. There is also the practical problem - only those familiar with the inner workings of Wikipedia will even be aware of this 'Stable versions' proposal, the ordinary reader will not necessarily know the ins and outs of 'Stable versions now', and will therefore not know that an editable version is available, and how to access the editable version. Both problems will result in many anonymous, one-time edits simply not being done, to the detriment of Wikipedia. Not to mention the conflict with our stated aims. Sure - have stable versions, but as a subpage (or some less hack-ish technical solution, which I will leave to the devs to think of :P), not an unneeded extension of page protection (which is supposed to be a temporary necessary evil). Cynical 21:50, 17 July 2006 (UTC)
  • Oppose "Edit this page" has made wikipedia what it is, and "Edit this page" link is useless if you can't edit that page. Zocky | picture popups 15:57, 19 July 2006 (UTC)
    • But is what it is what we want it to be? It seems to me that what it is is something which is generally regarded as interesting but not reliable. Worldtraveller 16:27, 19 July 2006 (UTC)
      • It is interesting but not reliable. And having a random admin pass a page as stable will not make it reliable, but it may appear as if we're suddenly claiming that it is. Zocky | picture popups 18:23, 19 July 2006 (UTC)
        • I trust a random admin much more than a random person from the whole user pool, not that admins will necessarily have much to do with stable versions. I certainly don't see how stable versions could make Wikipedia less reliable - having a set of versions which are free from vandalism surely can't fail to have the opposite effect. Worldtraveller 20:09, 19 July 2006 (UTC)
          • I'm not saying it will make it less reliable. It will make it insignificantly more reliable while making it significantly harder for visitors to edit. It's simply not worth it. Zocky | picture popups 23:41, 19 July 2006 (UTC)
  • Strong Oppose - I shouldn't even need to say why. --Avillia (Avillia me!) 16:51, 20 July 2006 (UTC)
  • I strongly oppose any "solution" that makes it impossible for a non-admin to fix an error in the main page that users see without finding an admin who cares, explaining the whole thing, and then hoping the admin still cares enough. --SPUI (T - C) 18:38, 20 July 2006 (UTC)
  • Oppose any proposal that makes the non-editable version the "front" one. Besides, I like JDoorjam's proposal better. BryanG(talk) 06:27, 21 July 2006 (UTC)
  • Oppose, no offence, but it's an absolutely horrible idea. The defining idea of Wikipedia is that anyone can edit it - if you take that away then you get just another Britannica. - ulayiti (talk) 16:52, 27 July 2006 (UTC)
  • Opppose Oh and yes I oppose this, in case someone doesn't happen to glance at my section below. Anything with advocates a mass full protection of articles is bullocks. That's what this proposal boils down to. It flies in the face of everything for the petty idea of "Vandalism and libel may hit this page any time! LETS PROTECT!". Kevin_b_er 01:08, 28 July 2006 (UTC)
  • Oppose In theory this could work and would stop vandels but i beleive it may also slow down real progress. --Sumgai 02:52, 2 August 2006 (UTC)
  • Oppose. I too am frustrated by the instability of articles, but I think that this proposed guideline tries to solve this problem only by taking away the greatest asset wikipedia has. For this problem, I don't see an easy solution being a good or workable solution, including this one. Since this is a rather large deviation from wikipedia methodology, I also think that it sounds very much like an incentive to fork. siafu 05:30, 2 August 2006 (UTC)
  • Strong oppose (I've never before written "strong" in this context.) Incremental editing is the core of WP's genius, and would be significantly damaged by this proposal. The process appears to be complicated and messy. I can see it become a chain around everyone's neck, particularly when the administration of the process is not performed regularly and promptly. Forget it. Tony 06:00, 2 August 2006 (UTC)

Abstain

  • I like the proposal, but I can't support it if the main view defaults to the stable version. The main view should default to the development version, with a prominent notice (large, and at the top of the page) that there's a stable version available. The most valuable aspect of stable versions is that it'll drive article improvement, but if the development version is hidden away, it'l stagnate: wikipedia should defualt to lowering barriers, not raising them. Tlogmer ( talk / contributions ) 22:21, 14 July 2006 (UTC)

What do we need a poll for? You can see what people think from the discussion - a vote won't achieve anything. Worldtraveller 18:16, 14 July 2006 (UTC)

Reading all that text requires more work. ;-) --Spangineeres (háblame) 19:33, 15 July 2006 (UTC)
I must say that after all my work to read the above, I am appalled that appparently I am the only living supporter. Hopefully it will soon be evident that I am simply sleepless... But seriously, I support default to stable version (since this is an encyclopedia) but would not object to an attractive, recognizable but not gaudy or intrusive banner saying "This article is a [[some_link|stable version]]; you can also see and contribute to a [[automatic_correct_link|test version]] which will eventually become the new stable version." Or do I overestimate familiarity of Joe Public with Debian?---CH 07:32, 16 July 2006 (UTC)
If you estimate any familiarity of Joe Public with Debian, then yes. I'd guess at least half the programmers in the world have never heard of Debian. -- Rick Block (talk) 15:51, 16 July 2006 (UTC)

Torn

After back and forth discussions with myself, I'm torn! There's so much positive...yet so much negative! — Deckiller 06:19, 2 August 2006 (UTC)

not happy

I'm most concerned about this proposal. If it were restricted to a temporary contingency measure for articles that are seriously unstable and important, I might feel better about it. But it's currently framed broadly. Tony 08:07, 2 August 2006 (UTC)

Already failed in a trial attempt within 10 minutes

Elephant has apparently been made a 'trial' to this. But if we look, the purpose of it has already been ruined, as the stable version has already been directly edited by an administrator:

Here's the history in case it disappears, for Elephant: 

# 02:10, 2 August 2006 Jaranda (Talk | contribs) m (→External links - -Rm spam link)
# 02:00, 2 August 2006 Cyde (Talk | contribs) m (Protected Elephant: Stable version [edit=sysop:move=sysop])
# 02:00, 2 August 2006 Cyde (Talk | contribs) (To view the complete history of this article and its list of editors see...

Doorjam's idea about administrators making little changes to the stable versions has already come to pass in the second attempted trial of this proposal. See Article stabilization separates administrators even more from other editors. under #Is_anyone_else_worried_about_a_mentality_change_here.3F . Kevin_b_er 02:33, 2 August 2006 (UTC)

Yep, this is changing the definition of "people we trust" from "everybody who's not blocked" to "everybody who has passed the pegeant". Some people seem to think that Assume Good Faith should be abandoned, but I have yet to read a coherent argument for that one. Maybe this should really be discussed on that page? Zocky | picture popups 02:57, 2 August 2006 (UTC)

Sorry, it's still a new process and not everyone is familiar with all of the rules yet. --Cyde↔Weys 02:40, 2 August 2006 (UTC)

Are you, Cyde? You didn't even bother discussing the implementation. --badlydrawnjeff talk 02:42, 2 August 2006 (UTC)
Except it's not a rule. Kevin_b_er 02:51, 2 August 2006 (UTC)
It's not a process for a start, and non-"familiarity" with its non-rules is misleading at best. -Splash - tk 03:20, 2 August 2006 (UTC)

I've reversed this thing. It's not finding anything like the necessary support either in practise or in discussion. -Splash - tk 03:28, 2 August 2006 (UTC)

Alright, could you guys please get together a few pages that you will "allow" us to run a test on? It'd be great to actually get some real tests in before this goes live in software in a few months. We have over a million articles ... the constant stalemating of these tests on even a single article is going to help no one in the end. --Cyde↔Weys 03:44, 2 August 2006 (UTC)

It wasn't a test of anything like the idea described on the project page. The use of truncation of edit histories and full protection to solve a passing vandalism problem isn't something that's likely to meet with a particularly warm response wherever it's done. -Splash - tk 03:48, 2 August 2006 (UTC)
As part of his reasoning for trying to convince me to support this proposal, Danny says that the developers will not be putting any effort into implimenting stable features. So, assuming his characterization of this is accurate, your fears are unfounded and a test (to prepare us for the coming in-software features) is not necessary. Raul654 04:21, 2 August 2006 (UTC)
I don't think that there's any consensus to even run a test on this at the moment. I'm not convinced that following through with "stable versions" is a good idea or in the best interests, and it appears that there are quite a few people who feel the same way. --badlydrawnjeff talk 12:28, 2 August 2006 (UTC)
You'll be pleased to learn that a brief test of it on 5 articles (without discussion or even following of the process as described on the project page) has just been terminated. -Splash - tk 12:34, 2 August 2006 (UTC)
I did catch that. I just hope that it's understood by other proponents that there's some work to do if it's going to be tested again. --badlydrawnjeff talk 12:41, 2 August 2006 (UTC)
I agree completely that this "test" has already failed the "well, admins will just edit the stable page anyway" test. Never mind that pages seem to be subject to this "test" without anyone even bothering to ask the general populace [5]. I'm sorry, but placing the ability to edit the articles that everyone sees (what new user of Wikipedia is going to even know to check the "development" version?) solely in the hands of the annointed admins is Very Bad Indeed. Part, heck MOST, of what makes editing Wikipedia fun is knowing the large and possibly immediate impact that will be had by even the most green of user on the base of knowledge here. This policy flies right in the face of that mentality. I strongly agree with the proposal to link to an article's FA page at the top of the article, as this strikes a good balance between "this version of the article is agreed by the community to be very good" and open editing. Wesmills 12:51, 2 August 2006 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Stable_versions_now/Archive_3&oldid=1137455343"