Wikipedia talk:Stable versions now

From Wikipedia, the free encyclopedia

Shortcut:
WT:SVN

Contents

[edit] Initial discussion

After discussing this with many editors over many months the only real objection I received was that some future software feature would make this obsolete. I'm not so confident that we'll ever see that future if we don't gain experience now. ... and there really is no reason to wait.

This process is intended to be as low risk as possible. When in doubt, don't use it. This is not a mechanisms to settle the great debates of our time... It is intended for the vast majority of articles that no one is fighting over, it is intended to help earn the trust readers already place in us, and it is intended to help keep our editors sane. Changes to the proposal which preserve the core intentions and basic mechanisms are welcome.

I've created the templates described in the process and they are fully functional and ready to use. However, they could use some look and feel enhancements.... I expect that the appearance of the stable version notice will likely be the most controversial thing about this policy. I think that it's important that we balance the need to prevent clutter with the need to inform readers about editing and history. I'm not sure what the best trade off is, so I've made the templates very simple, edit at will.

If this process becomes well established the stableversion notice could be replaced with simple UI changes, but I think we should avoid software changes until we are pretty sure about what we need. --Gmaxwell 09:17, 9 July 2006 (UTC)

I like the idea immensely. It would be quite useful for, for example, a DVD version. [ælfəks] 09:46, 9 July 2006 (UTC)
Great work Greg! I love it.--Brad Patrick 11:12, 9 July 2006 (UTC)
I see no reason not to use this. Kelly Martin (talk) 18:59, 9 July 2006 (UTC)

Yet another piece of the growing divide between admins and non-admins. --SPUI (T - C) 20:43, 9 July 2006 (UTC)

How so SPUI? The requirement for the participation from an admin exists because of the need to protect the stable version. We could skip protection of the stable version but it's almost certain that people would then edit it, creating a fork. Would non-protected stable versions satisfy your concern? If so, how would we avoid well meaning but unobservant editors from creating a fork? --Gmaxwell 21:43, 9 July 2006 (UTC)
Hmm, it wouldn't be a problem if 3 non-admins just ask an admin that he should finish the stabilization, I guess. Requiring an admin just because he has to protect the stable version isn't a good idea IMHO. Maybe a central page where non-admins can show that there's consensus for stabilization would be nice. Admins would check the page from time to time and do the stabilization stuff, including page protection. :) --Conti|✉ 22:27, 9 July 2006 (UTC)
Given that the stable version is protected, one needs to be an admin to update it. The concerns might only be satisfied by not using stable versions. One specific issue: categories. How do we keep the real version from showing up in categories? What if one wants to add a category to the stable version? We'd need to give CFD cleanup bots admin powers to change the stable versions. --SPUI (T - C) 08:00, 10 July 2006 (UTC)
It's not perfect, but in the absence of a proper stable version control mechanism, integrated with the MediaWiki software (which we will have, in time), it's as good as we can get. I'm hoping stable versions will improve the general public's perception of Wikipedia, it will be considered more reliable if people know there is a system like this in place. This alone is a good thing – on top of the immediate benefits such as protection from vandalism. Personally I favour having administrators involved in the actual decision, though I'm not sure we have enough admins, so it may have to work the way ContiE suggests out of necessity – Gurch 22:34, 9 July 2006 (UTC)
I want to avoid the risk of creating a system that allows random outsiders with a couple of socks to create little protected islands in Wikipedia. In order to do that we need to have a criteria about who is involved in the decision... at the same time, we can't go around defining new classes of user for every proposal. So since an admin is needed to make the change, and admins are the only form of trusted user we have.. I thought that was an acceptable compromise. The admin isn't asked to judge consensus, except in the most limited sense, because the bar for consensus here is intended to be very high. It is my hope that consensus would be achieved on the talk page, and then someone would go fetch an admin... if the admin had no objections, he could make the change... if he objects he can voice his objection like any other user, or if he is unsure he can leave the task to someone else. I would have no objection to creating a 'request for stabilization' page if people would find it useful, although they could just browse the category placed by {{stablenotice}}. --Gmaxwell 22:46, 9 July 2006 (UTC)


The MediaWiki developers have been telling us that article stabilization features would appear Very Soon for ages. Besides, intgrating the process of stabilization into the software will do little except make it easier. But a little monobook scripting should make it easy enough to do. -- Where 00:01, 11 July 2006 (UTC)
And if the feature ever does get added to the MediaWiki software, we could always use a bot to convert the "old style" of marking pages of stable to the new style of using the MediaWiki software itself to mark pages as stable. -- Where 00:05, 11 July 2006 (UTC)
Agreed, it's been just around the corner forever, we need to move forward. - Taxman Talk 15:23, 11 July 2006 (UTC)

[edit] 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)

[edit] "Only articles which are actively edited may become stabilised."

"Only articles which are actively edited may become stabilised. Articles which pass months without edits are not eligible."

Why this? To me it seems obvious that a well developed article is far less likely to be under current frequent editing, and these are the most obvious candidates for a "stable version". --Tony Sidaway 22:14, 9 July 2006 (UTC)

Only because we want to avoid a situation where some anon makes a couple of obviously good corrections to an otherwise intert article and no one bothers to resync the versions for nine months. If an article is being actively edited, that shouldn't happen. If you can come up with an alternative which doesn't increase complexity or create that risk, I'd support it. I'd rather take a low risk approach today, even if it substantially limits the number of articles we can make stable and then come back in three months and remove those words or replace them with a better metric. --Gmaxwell 22:34, 9 July 2006 (UTC)
I don't understand what the problem would be in the scenario you outline above. The article may or may not be resynched for ages, but so what? --Tony Sidaway 22:46, 9 July 2006 (UTC)
A lot of people see speed with which errors can be corrected as one of Wikipedia's primary advantages. Mostly forgotten articles which are made stable would break that. It was fully my intention, once this proposal was in use, to run a bot that would find pages which haven't been resynced in a while but have had changes to the development version.. and either ping people, or list them someplace... I just don't want to frontload the proposal with too much complexity. After a solution like that was in place and proven, I'd simply propose we remove that requirement. If you really think that it isn't needed from day one, then go ahead and amend the proposal. My first priority is to get this adopted, and we can refine it and expand its scope as we gain experience, but don't let my caution get in the way of having the best solution. --Gmaxwell 23:14, 9 July 2006 (UTC)
As I read this, non-active articles will remain unaffected, and as such will be "stable" by default, i.e. current version is the active one. From my understanding it's not that inactive articles won't be stablised, is that active articles will gain a developement branch which is periodically published by an admin to the main article page. Any article with a development branch, is then basically permanently protected, with all discussion on changes on a sub page (albeit in the form of a draft article + talk page instead of just a talk page) I can see the usefulness of having stable versions, but extending the protection policy to "actively edited" as well as "actively vandalised" articles, is also a concern. I can see several pros and cons to the approach, the main downsides that would worry me would be whether the development sub pages would seem as "important" as main pages - would RC patrollers revert vandalism on a non-main page as quickly? If the time between re-syncs is too large, would editors lose interest at having their contributions in a pending state? (On the plus side, would vandals not target development pages due to less visibility?) I think many of these issue can't be predicted until it's put into practice, which is why I'd suggest a trial run on a small set of articles prior to any potential acceptance as a guideline/process. Regards, MartinRe 11:19, 10 July 2006 (UTC)

[edit] More questions

  1. What should be done on articles where someone will object, no matter what. Should kinda controversial articles never get stable versions?
  2. "Only articles which are actively edited may become stabilised. Articles which pass months without edits are not eligible."
    • I kinda see the point here, but when I want such an article get promoted, I just do a minor edit and that's that.
  3. How do I get people to notice that I want to make an article stable? Will there be only a category, or a page where everyone can add new candidates? What stops someone from just inviting three of his buddies to support while not telling anyone else?
  4. "(...) no stabilised article should go more than three months without a synchronisation."
    • Why not? For example, Ryanggang explosion hasn't had any major edit in many months, simply because nothing new has come up and nothing has changed that could be written about. Forcing an update there seems not needed. An article that isn't edited in a while isn't automatically a bad one, either.
  5. "The new stable version should be selected by 'suggestion and lack of objection' or other similar lightweight consensus processes, but must include a single largely uninvolved administrator at a minimum."
    • Hmm, isn't the whole point of this to have stable versions that pretty much everyone agreed upon? The updating procedure looks like a perfect way to smuggle POV-content into stable versions, simply because it looks really easy to do, compared to getting an article stable in the first place.

--Conti|✉ 22:53, 9 July 2006 (UTC)

  1. Such articles would never get stable versions under this proposal. That is a hard problem that affects a minority of our articles. I believe it will take us years to get that right. I've avoided addressing those articles because I don't believe that we to make all our articles wait on a perfect solution which may not actually exist. Our experience with this solution may teach us things that help us produce a solution which works on more articles.
  2. Yes, and in fact .. some admin may just decide to WP:IAR and make a completely dead article stable. The policy is advisory and is intended to be applied by acting in good faith in the best interests of the project.
  3. If the development version hasn't changed at all, then the stable version is synchronized at all times. I'll make that more clear. The intention there is to prevent good changes being forgotten on a development page that no one looks at.
  4. If you think about it, 'lack of objection' is procedurally lightweight, but it is a much taller requirement that most 'consensus' processes on Wikipedia. If someone managed to get POV text inserted in the stable version, all it would take is a single explained objection and a single admin who found it reasonable to return the page to normal editing.
--Gmaxwell 23:14, 9 July 2006 (UTC)
So admins will be in charge of content. --SPUI (T - C) 10:44, 10 July 2006 (UTC)
Of course not, this proposal is intended to increase stability... not control. In terms of content control, admins are editors like all our other participants. If there is a dispute the correct action is to destabilize the article, as such I hope this proposal is nearly useless for controlling content. Not that I think control is without value, but I have no idea how you could create content control today on Wikipedia which wouldn't cause harm... I'm simply not that smart. --Gmaxwell 16:11, 10 July 2006 (UTC)
"this proposal is intended to increase stability... not control" I also see it in this light, and I think it is important to understand that the instability of Wikipedia has been a reccurent theme in outside criticism of Wikipedia policies. Please see User:Hillman/Media commentary on Wikipedia, where I tried to collect links to (and summarize the gist of) some of the most valuable outside criticism. ---CH 06:48, 16 July 2006 (UTC)

[edit] Naming format

Should the development version be in talk space, since the /development format doesn't create a subpage in main space? If the development version were Talk:ArticleName/Development, then discussion could go on in the normal place, and the development version would not come up on randompages.--ragesoss 03:44, 10 July 2006 (UTC)

I hadn't at all considered random page. The only problem I see is it causing some misleading results in our statistical toys (now edits to those pages will be talk edits) but I'm not too worried about that. This sounds like a fine modification, feel free to change the proposal and the templates. The templates should be adjusted to use {{SUBJECTPAGENAMEE}} and {{TALKPAGENAMEE}} rather than hardcoded namespaces, this will make sure the templates work in other NSes. If you or someone else doesn't make this change (or come up with a good objection) I'll swing by and do it a bit later. --Gmaxwell 07:19, 10 July 2006 (UTC)
I don't really like this idea. Many templates that link to the talk page would become kinda unuseable, it would be quite hard for newbies to find the actual talk page of the article, it would move almost all main-namespace edits to talk-namespace edits (assuming that most of our articles will get a stable version some day).. And, personally, it gives me the feeling that subpages in talk pages aren't that important, somehow. And what's so bad with non-stable articles showing up in randompages anyways? :) --Conti|✉ 15:31, 10 July 2006 (UTC)
Well, were we ever to get to the point where this was done on a huge number of articles the correct solution would likely be to create a new NS called 'draft' or 'development'.. the tabs could be fixed up correctly, etc. I am strongly opposed to making non-minimal changes until we know what we need, however. If this works we can make changes to help it scale later. As far as your points about the downsides of putting it in talk... I find them compelling as well. Personally, I don't care where we put it. So I'll just let people here discuss it. --Gmaxwell 15:40, 10 July 2006 (UTC)

See Wikipedia:Subpages#Disallowed_uses: if we are going to follow the subpages guideline, development versions are not allowed to be in article space. I see no compelling reason why this should be an exception, if we still support the guideline in general.--ragesoss 00:45, 11 July 2006 (UTC)

The only argument I see there is, again, that the article might come up in special:randompage. Again: What's so bad about this in this case? There'll be a box on top of the article that says that it has a stable version, people expect random stuff to come up when they click that link. On the other hand I see all the downsides of having the original articles in the talk-namespace I mentioned above. WP:SP is a guideline, and when there's a good reason not to follow it, we shouldn't. I really don't see the point in having the main article anyone can edit in the talk-namespace just because a guideline, written long before anyone thought about stable versions, says so. --Conti|✉ 14:06, 11 July 2006 (UTC)
I think having the history of the stable version readily available is more important than preserving the short histories between each sync. Obviously the ideal solution would be a development namespace, but I think development versions in talk space is the best short term solution. Another benefit is that protection is the only step an admin is needed for if development versions are in talk space.--ragesoss 19:32, 11 July 2006 (UTC)
I don't understand why any of the benefits you mention don't apply to leaving the articles in the main namespace. The history won't be touched in either case and an admin has to do the exact same work in either case. I'd also prefer a stable/static namespace in the long term. --Conti|✉ 19:43, 11 July 2006 (UTC)
According to the current procedure, pages are moved to the development location, not copied. Thus, no history is left at the stabilized location, only a message about the move, followed by single edit restoring the content (the summary for which directs users to the development version to find the history). I this issue is part of the proposed procedure and not actually dependent on the namespace issue. But still, I don't see any real advantage to keeping the development version in main space, since it doesn't actually create a subpage (whereas in talk space it does).--ragesoss 20:40, 11 July 2006 (UTC)
I don't see any specific advantages in keeping the articles in the main namespace, but as I pointed out above, there are several disadvantages in moving the articles to the talk namespace:
  1. The edit history is, as you pointed out, in the development version. Assuming that many, if not most of our articles will get stable versions, this, statistically, moves almost all of our edits to the talk namespace. This will be seriously misleading.
  2. Newbies will have a hard time finding the actual talk page of the article, as clicking on "discussion" will not yield the expected results.
  3. Templates like {{POV}} and many others who link to talk pages will link to an empty page.
  4. Stuff that is a subpage of a talk page doesn't look very important, like a draft for an article anyone can fool aroud with, nothing anyone takes seriously.
I'm sure that I can think of more stuff if I want to. And I see these disadvantages against virtually no disadvantages in keeping the articles in the main namespace. So I strongly suggest to keep the proposal as it is in this case. A whole new namespace for static articles would be ideal, IMHO. --Conti|✉ 21:08, 11 July 2006 (UTC)

Regarding your points:

1. The most important place for an edit history to be easily accessible is at the landing page; part of Wikipedia'a reputation comes from being able to easily look at the past history of an article. With frequent sync-ups, keeping the history with the stable version makes the history more useful, because the vandalism gets filtered out, but every time there is a new change, it represents a consensus improvement. Whichever namespace is used, I think the history should remain at the stabilized version.

2. In either case, the only likely way Newbies will find their way to the development version is from the template on the stable version. With talk space, there will be a standard subpage link at the top leading back to the main (only) discussion page, and the development template can be improved to fit whatever clarity and navitation issues we find.

3. Good point; I didn't think about templates. However, self-referential templates would probably be extremely rare in the articles that fit the stabilization criteria (which is explicitly not meant for controversial articles or article with lots of unverified or dubious information).

4. In my opinion, this is a very minor issue, overshadowed by the clutter it introduces to main space. --ragesoss 21:30, 11 July 2006 (UTC)

  1. We're talking about two different things here. You want the article history in the stable version, which would lead to several other problems, which have been mentioned here.
  2. Sure, we can help them finding it, my point is that we will make it harder for them to find the actual talk page.
  3. Hmm, obviously, these templates will not show up in any of the stable articles, because otherwise they wouldn't become stable articles. But the anyone-can-edit version of the article might get such tags from time to time.
  4. To be honest, this is the biggest issue for me here. Having an article in the talk page-namespace feels just very wrong. People will misinterpret the "Talk:" prefix when they see it in the title, and the article-drafts will just feel less important. But the last point is of course just my personal opinion.
--Conti|✉ 21:50, 11 July 2006 (UTC)

[edit] Good idea

I think the questions being asked are good... basically I am commenting to say that this is a good idea and running an experiment with a few articles to gain experience might be a great thing to do next. What I like about it is that it sidesteps the difficulty with more controversial articles. ++Lar: t/c 03:56, 10 July 2006 (UTC)

There is nothing stopping you, this doesn't really require doing anything that we forbid and the templates work. :) I would suggest that if you decide to try it that you choose carefully. A poorly chosen candate would, unfortunately, reflect poorly on the proposal. You might also want to wait a bit until we sort out the above suggestion that the development versions go into the talk NS. --Gmaxwell 07:24, 10 July 2006 (UTC)
Perhaps developing a list of candidates jointly might be a good approach to avoid poor candidates. I propose David B. Steinman... just as a discussion point. No rush in actually doing it! But I think it's a good candidate because it's a fairly complete article (for his relative importance), has references and pictures, and hasn't changed a lot lately... it had some edit churn a few months ago but hasn't had any controversial edits in a while. If it is useful to propose more, I will, when I get back on Wiki, perhaps late tonite. ++Lar: t/c 10:37, 10 July 2006 (UTC)
Just so you all know, I have nominated Warren Beatty already. Feel free to chime in. ;-) JesseW, the juggling janitor 18:18, 10 July 2006 (UTC)
I'm also willing to take biodiesel through as a test case. A decent article that gets a fair amount of vandalism, but also some decent edits and a lot of good suggestions on the talk page. - Taxman Talk 15:23, 11 July 2006 (UTC)

[edit] Fantastic

An idea whose time has been long in coming. A modest proposal that will achieve maximum results. Judgesurreal777 05:24, 10 July 2006 (UTC)

I agree; this is a great idea. Articles on pop culture icons would especially benefit from this, so perhaps Mariah Carey or Celine Dion would be good articles to start with. --Spangineer[es] (háblame) 17:45, 10 July 2006 (UTC)

[edit] 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)

[edit] Wikipedia Mantra in Jeopardy

I'm feeling a bit uneasy about this. It looks as though the proposal is advocating the protection of articles, for weeks or months at a time, because the article is just that good. Yes, it improves the reliability of the article, but whatever happened to the encyclopedia anyone can edit? I'm worried the articles anybody can edit will be hidden behind this perfect version (which remember does not exist) and it could take weeks or months for changes to actually be incorporated into the "perfect version". I fear this dystopian end to Wikipedia as we know it when, ten years down the line, only administrators can edit the articles and other users must request changes in development versions. So, I'm a bit torn; I would like Wikipedia to appear more reliable, but I'd also like to adhere to the anyone can edit principle. Perhaps keeping the anyone can edit version as the primary version and making the stable version secondary might work (i.e. mention that there is a stable version available in a header template). Or perhaps we could maintain a location for all of the stable versions. But, please, don't take the anyone can edit away; that's all we have left... for the people of the tomorrow... for the children. Think of the children... the children... joturner 19:34, 10 July 2006 (UTC)

Anyone can still edit, and there will not be any merging. The proposal doesn't permit forking. The stable version should track the development version, although you are correct that there will be some delay... If a stable version isn't synced to the development for months then the article should be destabilized, and the proposal says exactly that. The idea of making the stable version non-primary has, of course, been considered. But there are a couple of issues with that... People would fail to update it (because it doesn't matter to almost anyone, since readers wouldn't bother to check it, the same is not true the other way around because you are supposed to update the stable copy, and people care about the content the readers get being accurate), and making the stable non-primary would remove the primary advantages of this proposal (that content unseen by any editors other than it's author is being handed to readers with the full authority of Wikipedia behind it).  :) If I ever have children, I think I'd like it if the chances of Cheese being replaced with pages of Image:Penis.jpg were greatly reduced. :) ... When you think about dystopian futures, consider an alternative where all pages end up semi-protected. Would that really be better? Consider an alternative where people fork Wikipedia and the most popular version is a completely uneditable, but reviewed for accuracy version, would that be better? The ability to edit is critical, but we can't forget quality. I think we all need Wikipedia to *be* more reliable, not merely appear more reliable. We can't assure reliability in advance, because we don't control our contributors... Today we catch reliability after the fact, and we're pretty good about it... but that doesn't happen until wrong information has been distributed to potentially large numbers of people. --Gmaxwell 19:54, 10 July 2006 (UTC)
Something I like a great deal about Wikipedia is that it encourages people to ask questions and dig into the history and talk pages when they have a question...rather than rely upon notions of "arguments from authority". Plus I sell people on participation in the project by pointing out that even fixing a spelling error is helping. So as a matter of philosophy, I'd agree with joturner that—if anything—the existence of the stable version should be mentioned as an aside while displaying the "development" version. This would be similar to existing tags like "a recorded spoken version of this article exists from a prior snapshot". Metaeducation 21:18, 10 July 2006 (UTC)

I don't have a particuarly strong opinion on wheather the stable version is at a subpage, and the development version at the page title, or vis-versa. What I like about this proposal is that it allows us to distinguish versions with some consensus from whatever-the-most-recent-editor-put, which we can't easily do at present. The location question seems like a symptom of the constant tentsion between "Wikipedia is a project to write an encyclopedia" and "Wikipedia is an encyclopedia". I tend to lean more on the first, but I don't feel particuarly strong about it. In any case, it's important to remember that articles remain freely editable by anyone; there is just an alternate stable/released/consensus version available. (this was written somewhat earlier, I forgot to sign it at the time) JesseW, the juggling janitor 23:42, 10 July 2006 (UTC)

Joturner wrote "I fear this dystopian end to Wikipedia as we know it when, ten years down the line, only administrators can edit the articles and other users must request changes in development versions." But this is exactly what I think Wikipedia needs, and not ten years from now, but now, right now!
Well, not quite. I can see the advantages in both the classic anarchowiki model and a Britannica type centrally-organized development model for building an encyclopedia. What I'd like to see at Wikipedia is an intelligent and well thought out compromise between these two extremes of sociopolitical structure.
One crucial point which I think long-time Wikipedians (I have been here for 14 months, so not very long-time but rather active) seem to often overlook is that open-source web projects tend to evolve very rapidly, and any tendency to cling to outmoded ideology tends to put a project in danger of earning Darwin's award: extinction.
I have been talking (on my own user talk page) for some time about a (vaguely formulated) scheme in which both editors and articles would have grades. Higher grade editors could perform more actions, such as editing higher grade (more stable/reliable/reviewed) articles, but in general would only have elevated privileges in their areas of demonstrated interest/knowledge/ability.
Editors would increment their grade gradually by persuading some number of higher grade editors that they have demonstrated sufficient knowledge and writing ability. (For example, I feel that one of the biggest but least discussed problems with the traditional wiki model is that well-intentioned but inexperienced editors frequently insert new material without regard for previous organization, notation, terminology, spelling conventions, paragraph structure, verb tense, general style and balance, segues into the next paragraph, and so on, sometimes even turning nearby sentences into nonsense. Higher grade editors would, I hope, be sensitive to such issues and able to recognize similar awareness in an up-and-coming contributor. Similarly, I hope that higher grade editors would be able to wisely and competently assess the factual knowledge and library research abilities and tenacity of up-and-coming contributors.)
In my scheme, some number of editors of sufficient grade could decide to increment or decrement the grade of a specific article. All grade changes (both for editors and for articles) would be incremental and, I hope, would occur at a measured pace. This part of my thinking, at least, is close to Jimbo's insistence on slow and conservative changes, although as noted above, in a rapidly evolving collaborative and global web project like Wikipedia, I think that one should avoid clinging too long to elements of ideology which have outlived their relevance and may even have become detrimental to furthering the goals of the project. My scheme attempts to encourage the rapid improvement of stubs while preventing the rapid degradation of mature and high quality articles, such as "feature articles" and "good articles".
One thing such a system would address is the profound instability of Wikipedia-- a phenomenon which, as noted on one of my user pages, has been decribed by quite a few outside reviewers of the Wikipedia. Gmaxwell's proposal would also respond to such criticisms. I'm not really here to discuss my own proposal (but please hop over to my user talk page if you have any thoughts to share!), but to applaud the most notable feature of Gmaxwell's proposal: his templates could be used immediately. I am glad to see that everyone appreciates what an advantage this is, particularly at WP, where the pace of policy change often seems glacial to those of us who desire immediate and effective action to correct some of Wikipedia's most lamentable deficiencies.
I'd certainly like to see the WP community give it a tryout in the very near future, perhaps in some specific area or areas of subject interest with a dedicated WikiProject base, like WikiProject Mathematics, whose membership already includes a number of active admins.---CH 05:35, 16 July 2006 (UTC)

[edit] Premature and unacceptable

This is really about image management, and will take time away from the real task of improving Wikipedia. In my opinion it will be a few more years before the general level of quality is high enough to warrant thinking about this sort of thing. And even then, there are so many articles where regular updates are needed for new developments that it seems likely to me that on average, at any given time the fitness for purpose of the stable versions will be lower than that of the edited versions.

The other problem with this is that it gives yet another privilege to administrators. Saying that one of the three editors has to be an administrator is tantamont to saying that the opinion of any admin is better than the opinion of any non-admin, and if this process is valuable to wikipedia (not that I agree it is) it needs to be redesigned in such a way that it can be implemented without giving any privileges to admins, who have too many already. Merchbow 20:30, 10 July 2006 (UTC)

I wonder how much Wikipedia's image is hurting in a way that could be fixed by anything like this? One potential loss I've imagined is that there might be websites that would like to dump their content into the wikipedia and turn their own pages into HTML redirects to those articles, but don't do it because they fear the instability. Yet...given that Wikipedia hosts free content there should be no barrier to anyone going and creating their own snapshot of a page (or set of pages). Ideally these mirrors would run software that could easily allow the host to synchronize versions on a per-article basis. Encouraging a decentralized approach like that might help ease the administrative tension, as long as these sites didn't become forks (and were merely selective about when to sync). Plus maybe it would help more content authors be willing to hand over their material and become Wikipedia mirrors? Metaeducation 21:26, 10 July 2006 (UTC)
(edit conflict) The central point of this proposal is simply to allow us to distinguish between the-version-of-an-article-considered-correct-by-the-regular-editors-of-the-page-(and-at-least-one-user-more-or-less-trusted-by-most-Wikipedians-who-bothered-to-express-an-opinion) and the-version-of-an-article-considered-correct-by-the-most-recent-editor. Right now, we have no way to identify, or easily display, a version of an article that the regular editors of the page consider correct; we can only easily display whatever the most recent editor chose to put o n the page, even if no-one except that editor would consider it correct. This proposal allows us to distinguish these two versions. It doesn't matter how good the "general level of quality" of Wikipedia is - parts of Wikipedia are great, and parts are terrible; we would not apply this to the terrible parts, obviously. Furthermore, an encyclopedia, even Wikipedia, doesn't need to track minute-by-minute news - on quickly changinging topics, there is no reason why a stable version couldn't be synced with the freely editable development version every day, which is more than up-to-date enough for encyclopedic information.
As for the idea that an admin's opinion is better than any non-admin's opinion - that's nonsense, and if the proposal said that, that would be a problem. But it doesn't. It says that a decision reached without the opinion of any admin is not as good as a decision that does include, as one of the opinions, the opinion of an admin. As explained above, this is meant as a hedge to make sure that at least one editor who has been considered-sane by a group of other Wikipedians is involved in the discussion. Do you think a group of editors, who may all be entirely new to Wikipedia, entirely opposed to our goals, and entirely unknown to any other Wikipedians, is a sufficient group to make this decision? JesseW, the juggling janitor 21:38, 10 July 2006 (UTC)
I realize the bueracracy involved in this proposal requires an admin. I do not have a problem with that so long as all the rest works as advertised. However I just cannot let your above comments pass without commenting on them. RfA is not a process to certify an editor is considered sane. Oppostitions are often made because people do not see and editor doing X, not because they see anything they dislike that an editor actually did. I would disagree that the average admin is more likely to be "sane" than the average non-admin. An argument can be made that accepting an RfA nomination could itself be a sign of insanity ;) Although in all honesty I think admins are a pretty representative of regular editors and all ways except as regards their feelings about politicking. Your last question is setting up a straw man argument.--Birgitte§β ʈ Talk 15:05, 12 July 2006 (UTC)

[edit] Reduce editing

add in a concern that people will harp on the "stability" of an article to reduce editing, and you've pretty much voiced my concern. I don't like this at all, now or in the future. --badlydrawnjeff talk 23:21, 10 July 2006 (UTC)
I'm not sure what comment you wanted to add yours to, which is why I made a seperate section; please clarify. As for the objection you stated - I don't really understand. Editing of the development version would be strongly encouraged, not in any way reduced - and the "stability" of the "stable version" only means that it reflects consensus, rather than the current version, which only reflects the current editors view. Please expand on what you mean by "people harp[ing] on the "stability" of an article to reduce editing", because I don't see anything in the proposal that connects to that. JesseW, the juggling janitor 23:40, 10 July 2006 (UTC)
The idea that it is "strongly encourageD" is great in theory, until people invariably start complaining about how the stable version isn't stable anymore. --badlydrawnjeff talk 00:48, 11 July 2006 (UTC)
Please let go of the red herring, thank you. The "stable version" is simply one that does not include obvious vandalism - it is not intended never to change. You are mis-reading the proposal. JesseW, the juggling janitor 19:32, 12 July 2006 (UTC)

[edit] Categories

I realize this would make the process a smidgeon more complicated, but the categories and interwiki links on development version should probably be set off with nowiki tags; fortunately, this would not affect the appearance of the development version, and remove them during syncs would be trivial. See Wikipedia:Subpages#Disallowed_uses.--ragesoss 00:59, 11 July 2006 (UTC)

Agreed, good amendment. JesseW, the juggling janitor 19:32, 12 July 2006 (UTC)

[edit] Bad idea.

<brion> i'm working on stable versions. target is later this month/next month.
<avillia> Well, that's a bit troubling, considering the very shortcut way the policy wishes to implement things, and that it's gotten mentioned in the signpost.
<brion> don't trust software news in the signpost :)

Considering this, it's a horrible idea to start this quick hack. There is not a urgent need for stable versions; We've lived for years without them, we can wait another month under scrutiny. The effort is appreciated, but farrrr off. --Avillia (Avillia me!) 03:20, 11 July 2006 (UTC)

And why wouldn't this "quick hack":
  1. Let us test out the policy-type infrastructure we'll need once a software solution is deployed anyway? The software isn't going to solve the hard problems like deciding who gets to say when a version is stable.
  2. Be easy enough to dismantle and/or port to the software solution when need be? —Bunchofgrapes (talk) 03:28, 11 July 2006 (UTC)
Duke Nukem Forever, world peace, stable versions, Wikimedia unified login... I'm not blaming the developers, but this is long overdue. Stable versions is one of the things that have been, in one form or other, "only a few [weeks/months/...] away" for years now. Our reputation is suffering. There's no reason not to start this now, and we can move on to a better solution once it exists.
I agree with Duke Nukem: experiments like this proposal (SVN) are terribly overdue and WP urgently needs to try out those which are easiest to implement quickly on an experimental basis (SVN certainly qualifies for serious consideration on these grounds alone!). I hope SVN is given a good hard try over the next few months, and that if successful it will be widely adopted. Won't solve all the problems but it is urgently required to begin immediately to seriously address the most seriously problems. ---CH 05:41, 16 July 2006 (UTC)

[edit] Thoughts

We really really do need some sort of stable/static version, separate from the wiki versions of articles - without it, we can simply never be regarded as authoritative. The wiki is a means, not an end, and while it's perfect for collaboratively writing articles, it's no good at all for managing articles which have reached high quality. I like this proposal, as far as it goes, but have some ideas on how it could be better.

  1. It's beyond the scope of this proposal, but having stable articles at a visibly different web address would, I think, enormously increase the PR value of having them. Something like static.wikipedia.org/Article_title or en.wikipedia.org/Static/Article_title. Then the reader is more immediately aware of whether they are reading a 'finished' article or a development one.
  2. On the whole I think there's an argument to be made for using the word static instead of stable. Stable implies that the rest of the encyclopaedia is unstable - not really accurate as it's not about to collapse or change drastically, but more likely to be in the usual process of evolution and enhancement.
  3. This proposal would give editorial control to admins. That would make adminship a much bigger deal than it ever has been. Better, maybe, would be a new class of editor to adminstrate this side of things, selected on the basis of high quality contributions like writing FAs.
  4. See also a similar proposal at WP:STATIC. Worldtraveller 09:30, 11 July 2006 (UTC)

Interesting ideas. Point one I feel is pretty clear, but you're right, that's something that can't be done at the moment. No reason not to go through with this proposal in the meantime though. Using the word "static" makes sense to me; "stable" is just more ingrained right now.

I'm not sure about point three. At first, this "new class of editor" must be a subset of the admin class, because only admins can protect pages. That might not be necessary in the future, but it might be tough to build something more complicated into the software. While I've written several FAs myself, I'm not sure that we would want to limit it to people like me. How many people have written more than 2-3 FAs? Not more than a several dozen I believe. That doesn't leave too many people to be making all these decisions. Thus it might not make sense to restrict it to FA-writers, but rather to have some sort of voting/discussion process where a candidate gives several examples of his/her work and others judge his/her understanding of what makes a good article. This adds another level of process though.

What about responsibility? The point of these static versions is to prevent errors from appearing in the article, but what if one gets by? If it's just an admin judging consensus, it's not really anyone's fault. If it's someone with some level of "editorial authority", would that person be responsible for the mistake? What are the implications of that? --Spangineer[es] (háblame) 12:12, 11 July 2006 (UTC)

While I think many of us agree on some of those points, Worldtraveller, there is considerable value to a process that can work now. Rather brilliant in fact Gmaxwell, it's obvious in hindsight, but never got going before. Meets a good definition of smart innovation. After a little time to iron out kinks (ie does anyone have an answer for the subpages considered bad issue) we should go ahead with a few articles to test, then slowly build this out. I think the advantages will be obvious. Lets not let something that's not perfect keep us from moving forward. - Taxman Talk 15:23, 11 July 2006 (UTC)

Why is this so imperetive to roll out now? --badlydrawnjeff talk 15:39, 11 July 2006 (UTC)
We've been discussing the need for stable versions for a long time, and now someone has a decent idea to implement something that could work immediately. What better time to test it than the present? --Spangineeres (háblame) 15:43, 11 July 2006 (UTC)
Because this isn't a very good proposal? Because a lot of major issues - such as how this is actually going to encourage editing - haven't been dealt with? Because, judging by the stability fliers taken before, we're simply not ready for it? We can't even get featured articles right, why are we doing this? --badlydrawnjeff talk 18:13, 11 July 2006 (UTC)
I'm not saying "let's implement it permenantly, right now", I'm saying let's test it and see what happens. It's all speculation until we know what the problems are. I'm afraid I don't know what you're referring to when you say "stability fliers"—have processes like this been pushed hard in the past and then failed miserably? I haven't seen any of that. And what relevant problems do you see with the FA process? --Spangineeres (háblame) 18:50, 11 July 2006 (UTC)
WorldTraveller suggested a separate website. I think the seperate website should be called wikispeech.org and it should be like an international version of Campaign Wikia, only not-for-profit, and stressing securely anonymous discussion of possibly controversial views on sociopolitical and other conentitious issues. See my attempt on my user page to distinguish between two conflicting missions: building a better Britannica and building a better blog, where I argue that these are both laudable goals, but they are very different, require very different policies, ethos, and even differing software solutions, so it makes good sense to split up these missions which I feel tend to get confused in current "Wikipedia" culture. In contrast, I think SVN solidly belongs to the mission of building a better Britannica and therefore it should be experimented with at wikipedia.org. However, I do think it would be a good idea to write the templates so that the stable version gets a distinctive, recognizable, attractive, but unobtrusive background (light pastel?-- would have to test with many complicated articles to make sure it wouldn't conflict with very many figures or whatever) or banner. ---CH 05:48, 16 July 2006 (UTC)
This might be getting off-topic, and might also tend to conflict with the most attractive aspect of SVN, the "Now" in the title (Brion would know more!) but I tend to think that from a social aspect it might make sense to set up an "inventory" of "capabilities" for each registered user. My hope is that this concept would be immediately understandable to gamers and other initiates of the World Wide Web. The idea is that nonadmin users could be awarded by existing admins certain specific capabilities. For example, an admin who happens to be familiar with my own work could award me the capability to carry out SVN actions in my own area of expertise/interest, Math and Physics. Again at the risk of adding to the technical complexity, I tend to think that it might be good to at least consider the possibility to awarding stabilization/destabilization capabilities by the basic subject areas rather than "globally". ---CH 05:57, 16 July 2006 (UTC)

[edit] Average End Quality Hypothesis

read this. Herostratus 13:35, 11 July 2006 (UTC)

[edit] Where to keep article histories

User:Ragesoss changed the procedure, but I don't think his changes are beneficial, so I reverted and left a note on his talk. The page moves and such described originally are necessary to preserve the GFDL compliance and avoid splitting the page history. Copying and pasting the article into a development article and editing that will cause all sorts of problems when it comes time to re-stabilize, as far as I can tell. --Spangineeres (háblame) 15:38, 11 July 2006 (UTC)

How is GFDL compliance an issue? Rather than splitting the page history, think of the development version as a filter, and the changes the pass the filter and get incorporated during a sync are the only ones that become part of the actual article's history, everything else is equivalent to discussion; it can be found if you look for it, but it isn't technically part of the article's history. If syncing happens regularly, as it should, then all the significant aspects of the history are preserved, while the noise (which is a huge problem in browsing article histories) is greatly reduced.--ragesoss 23:05, 11 July 2006 (UTC)
Maybe I'm not understanding something. Seems to me that with your plan if an article has say 10 edits and gets stabilized, that article gets copy/pasted into the talk page, which requires one edit. Then people come along and edit the development version and make 10 edits. Then an admin comes and copy/pastes the newest development version into the article. End result: 11 edits in the article itself, 11 edits in the development version. The admin doing the updating to the main article isn't the person who wrote the text, so his/her name appearing in the article's history isn't accurate and thus the article doesn't comply with the GFDL (since all authors have to be credited). Perhaps a link to the development version history would be sufficient, but considering that admins do page moves/undeletions all the time, I think it's relatively easy to keep everything in the same place. --Spangineeres (háblame) 13:00, 12 July 2006 (UTC)

[edit] Trial run

It seems there is already a trial of this proposal being begun [4]. However this should be approached in a more methodical way, if we are to really gain information from it. First we need to identify which types of articles are believed to most benefit from this proposal. Someone suggested pop icons for examples. After compiling some similar groups with a similar amount of activity they need to be divided with one being a control group. If we just test this out without such a group we will not be able to learn if creating stable version makes it less likely for people to add contructive edits to the development version. Everyone seems to agree that edits of the development version should be "strongly encouraged." I would like to see that this encouragement actually works before proceeding with the proposal. If the first test does not do well we can continue to alter the wording of the templates until we have a sucessfull trial run. We should probaly agree on some sort of "weighting" of the contructive edits for measuring sucess. By that I mean we should take into account the vandalism edits being recieved as well as the contructive edits, but constructive edits should count for more. I like this idea in theroy, I want to see it work in practice.--Birgitte§β ʈ Talk 15:53, 11 July 2006 (UTC)

Pop icons might be a good place to start because A) we have a number of them at FA and GA status, and B) they are typically edited/vandalized frequently. Maybe get two groups of around 10 articles, with 2-3 FAs and 2-3 GAs per group. Then implement this on one group and see what happens. The problem is that the experiment won't be perfect, since the fact that this is a test run will make these articles get more attention than they otherwise would from people following this discussion. I don't think that "weighting" of vandalism/constuctive edits is necessary; trying to quantify the benefit in a way that everyone agrees upon will be tough. Let's just run the test and let people draw their own conclusions and discuss the result. --Spangineeres (háblame) 16:14, 11 July 2006 (UTC)
I agree we should do a run and disscuss the results. I guess I was overthinking it a bit on the weighting. I think it is also important to set the groups up by average activity they are currently recieving.--Birgitte§β ʈ Talk 16:33, 11 July 2006 (UTC)

[edit] Questions

I'm very skeptical of this proposal, but I'll hold off on the ranting for now.

  • The crucial question: Is this intended to be temporary or permanent?
  • In the current proposal, if I click a link from an ordinary article to a stabilized article, it will take me to the stable version. Will there be a way to change this, so I can browse the current versions as I have always done, without annoying extra clicks?
  • When the development of a piece of software is frozen in preparation for release, trivial bugfixes are still pushed through quickly. Will there be an easy way for anonymous editors to report urgent problems with an article? I'm not even talking about typos as much as things like broken ref tags that hide large portions of an article. Of course now you say that can't happen, the stabilized versions will be thoroughly checked, but trust me, bugs do sneak in. After all, wiki means "quick". If this proposal is implemented, we might as well change the name to Lohipedia (Hawaiian for "slow"). —Keenan Pepper 18:07, 11 July 2006 (UTC)
Re your crucial question, I believe the answer is that ideally, yes, once implemented some sort of stable versions would be in place forever. Articles would be periodically updated (matched against the "development version"), and wouldn't be destabilized unless something happened that made it impossible for consensus to form over one revision (POV issues, etc.). And of course, once the software is updated to make this whole process cleaner, we'd use that method and not this one. For your second question, a possible immediate solution would be updating the popups script to include a link to the development version. Once the software is updated, perhaps an option could be added to preferences that would allow users to select which they want to see by default. And finally, a page similar to WP:AIV could be created for the type of problems you describe. Anyone would be able to report a problem (like reporting vandals on AIV) and then an admin with the page on his/her watchlist could solve the problem. On AIV vandals are usually dealt with in minutes, and I don't see any reason why the same wouldn't be true here as well. --Spangineeres (háblame) 19:05, 11 July 2006 (UTC)
So the proposal on this page is for a temporary solution? Could someone clarify that on the page itself? Also, this leads to another question: why not simply wait for a permanent solution? —Keenan Pepper 22:38, 11 July 2006 (UTC)
Why not simply wait for a permanent solution?—the simple answer is that we've been waiting for a long, long time. Stable versions, as one user noted above, are Wikipedia's version of Duke Nukem Forever or World Peace—something that is always a short time away from implementation. However, things are beginning to look more promising, so maybe we will, after all, have a permenant solution before too long. In the meantime though, as I believe Bunchofgrapes pointed out, we should be getting ready for it. There are alot of kinks to work out, like determining when to stabilize articles and deciding who gets to stabilize them. Those types of issues can be debated and answered with a system like this, and would allow for seamless integration of the new, better system whenever it's completed. --Spangineeres (háblame) 13:09, 12 July 2006 (UTC)
At the same time, if we don't see them now, there's probably a good reason for it. If the community at large isn't looking for it, who are we to kind of force it along. It's not as if the programmers can release Duke Nukem Forever in its current state either. --badlydrawnjeff talk 13:14, 12 July 2006 (UTC)
Right, but for me who has never played any Duke Nukem games, I could start playing an older version now to prepare me to appreciate the new version and be more successful playing it when it does come out. There will be differences, of course, between the games, but I'll understand the plot better and have improved hand/eye coordination skills. I think that's a more appropriate analogy. --Spangineeres (háblame) 14:48, 12 July 2006 (UTC)
Which, to me, is more reason to not bother with a new, incomplete version until it is completed. Different strokes, of course, but yeah. --badlydrawnjeff talk 14:57, 12 July 2006 (UTC)

[edit] This is a KISS proposal; I like it.

With the proviso that there isn't further clarification about Brions software-side stable version schema, and when and/or if it will be put live (not merely coded - I presume there would be a testing period involved etc.), this suggestion by Greg Maxwell is great in that it can be implemented directly, and improved, developed along the way, as we see how it works.

Only comment I can offer at this stage is to insist strenuously that the history remain at the stable version. (It is too early to think about periodic reviews of the edit action at the developement version, though I imagine that if eventually such would be done, the histories would always be merged after the wheat was picked from the chaff. Just get the show on the road, and see what needs to be added to the chassis later.)

I really would like it if there were clarity whether this schema would actively make it *harder* for brions promised software solution to work. Unless I hear otherwise, I will assume not. Cannot see how this would clash with anything. -- Cimon avaro; on a pogostick. 18:08, 11 July 2006 (UTC)

Agh, just realized the logical problem with having the history at the stable version. Nevermind. As a substitute, maybe the stable version template could include a directly clickable link to the history of the developement version? -- Cimon avaro; on a pogostick. 18:15, 11 July 2006 (UTC)

That's one of the major problems I see with this. --badlydrawnjeff talk 18:20, 11 July 2006 (UTC)

[edit] Tie-in with senior editors?

This may be pie in the sky, but seeing this, I wrote an optional tie-in to User:Herostratus/Senior editor, which is just a private essay (at this point). I'm not really up on this proposal (Stable versions now) yet so make of the other what you will. Herostratus 18:20, 11 July 2006 (UTC)

[edit] Why not just use GA/FA status?

We have two formal, evaluative methods already employed. Why not simply have the live, dynamic version of articles, and then instead of the teensy little star in the upper right hand corner, or the "Early registration for Wikimania" banner that's currently up there, link to the "certified" version of the article?

This article certified as a Featured Article on July 11, 2006. View certified version here.

If the date seems to be getting particularly stale, or substantial edits have been made to a good/featured article, editors can apply for recertification. Much as articles that have been featured in the news or AfD'd have records of those incidents, there could even be a small log on the talk page with links to the other certified versions. That way, people concerned that they're reading "the good stuff" have a certified version, but the ongoing version stays wikiwiki (and so I don't need an official tribunal to correct an overlooked typo in the official version). It would still be the Encyclopedia Anyone Can Edit; we'd simply add to that, "and we guarantee you that this version right here is especially good." The important point to keep in mind here is that 95% of what I'm describing is already in place. All that needs to be done is to add one line of text linking to a particular version of the GA/FA articles which exists in the history and is thus stable. JDoorjam Talk 21:00, 11 July 2006 (UTC)

I really like this idea as well. It's even simplier than this (remarkably simple) proposal. Yes, please. JesseW, the juggling janitor 19:39, 12 July 2006 (UTC)

[edit] Strongly disagree

Only articles of a reasonable quality level, per the judgement of the involved Wikipedians, may become stabilised articles. It is not necessary that the article have featured article, or even good article level quality. However, the article must contain no obvious factual, grammatical, or typographical errors and must contain at least some level of referencing.

In my opinion (yes thats all this is) any article that is stabilised should be at least referenced to FA standard. I think stabilising FA's and Good articles would be a better start than trying this on just anything, but proper referencing is _highly_ important. - FrancisTyers · 22:27, 11 July 2006 (UTC)

Perhaps we could add "... and must conform to WP:CITE, WP:VERIFY, WP:NOR, etc." — this way we couldn't have stabilised articles with uncited/referenced statements. - FrancisTyers · 22:28, 11 July 2006 (UTC)
We already have stabilized (pardon my "z") good and featured articles. They're in the history, permanently and forever. All we need to do is link to the "certified good" and "certified featured" versions at the top of the current Wiki articles. This wouldn't even take a policy change, just a template with a link to the history. BAM! We have our "credible" version for those who need it, and the good ol' default dynamic version which has been more than good enough for most of the English-speaking world for the past 5 years. JDoorjam Talk 22:32, 11 July 2006 (UTC)
Sounds good to me. - FrancisTyers · 22:36, 11 July 2006 (UTC)
Me too, that seems like a much better proposal. —Keenan Pepper 22:41, 11 July 2006 (UTC)
And let's say someone makes a good change to one of these "stabilized" featured articles. What then? You have to resubmit to FAC to change the link? —Bunchofgrapes (talk) 22:52, 11 July 2006 (UTC)
Yes, but the process the second time would be much easier: evaluators need simply compare the proposed update with the original featured article, take a look at the red text, and say "yes, that looks fine to me." They could be listed as "FA Updates" as opposed to "FA Original nominations" so reviewers know that they only need compare the two. It's a slight increase in the bureaucracy, I know, but it's waaaay less than this proposal and we still get our "article certification" that seems to be the whole point of this experiment. JDoorjam Talk 22:55, 11 July 2006 (UTC)
Actually thats not a bad idea at all, have an FAC updates page, with criteria that are simply "updating", perhaps "spelling mistake", "adding a source", "grammatical change", "image resize" etc. Trivial stuff. If it is less than trivial it should go through FAC again. - FrancisTyers · 11:53, 12 July 2006 (UTC)

[edit] Is anyone else worried about a mentality change here?

Article stabilization causes major changes in Wiki mentality that seem detrimental to me:

  • The first is a micro-scale change: an article that has been stabilized seems "done". Why work to make even minor improvements in an article when you don't know when or even if they're ever going to get included? Will the article be restabilized in a week? A month? Besides, if the community has put the "Good Enough" stamp on it, why should I put more work into it? Stabilized articles will have a significant drop in the number of editors working on them.
  • Article stabilization separates administrators even more from other editors. In theory, administrators will go through the same process others would to make changes to a stabilized version. In practice, administrators would Be Bold and make minor changes that they deemed necessary -- missed spelling errors at first, then, hey, maybe a grammar change here or there. If news breaks on a story, if somebody is born or dies or is elected or impeached or wins an Oscar, admins will probably feel pretty comfortable going in and updating that information. Nothing to get de-sysopped over... except it will mean that, in order to really hold the keys to the castle, one needs to be an administrator. Sysoppery will no longer be "not a big deal." It will be a huge deal.
  • This is my biggest concern about stabilization, this process implies to the outside world that the vast, vast majority of our articles cannot be trusted. It is an admission that the Wiki process is so flawed that you cannot trust an article that has not been certified, stamped, signed off on. Do you know how long it would take to certify the articles we have now, ignoring the 1,800-some articles created every single day, especially considering that any significant content dispute would apparently cause the stabilized version of an article to be deleted? In the interim, we are saying, "we've created this other class of article because you simply cannot trust the rest of the work that we've done." This smacks of a retreat to Nupedia. If you think we're doing ourselves a PR favor by saying that 99% of our work -- that's assuming we can stabilize 10,000 articles -- cannot be trusted, you're mistaken.
  • Worse, this opens Wikipedia up to more criticism, not less. What happens when an egregious error gets "stabilized"? Or worse, a hoax? This week, we saw that Wikipedia misreporting the cause of Ken Lay's death for six minutes made it into news outlets around the world. What happens when, in a hurry to get over that 1% bar I've mentioned above, a well-meaning administrator "stabilizes" something libelous about a public figure? How many news articles will there be with the headline "Wikipedia's Attempt At Oversight Fails"?

If we want to put more of our weight on our "certified" articles, as I've already said above, we can simply make accessing "certified good" and "certified featured" versions more accessible without making Wikipedia even slightly less dynamic. We already have a process in place to say "we trust the content of this article." Let's keep the Wiki process the dominant, first-to-load feature of this project, and allow editors to see the "seal of approval" version if they're not as trustworthy of the "straight-off-the-wikiroom-floor" version. There is absolutely no reason why we should turn this project into Nupedia when we've come so far by having faith in building an encyclopedia anyone can edit. JDoorjam Talk 22:29, 11 July 2006 (UTC)

First point - may or may not be borne out. The more complete and finished an article, the less people need to work on it anyway, so I don't see this as a problem. A timescale over which new changes are integrated from development into stable versions ought to be established for clarity.
Second, I agree, it would make adminship a big deal. I don't have any problem at all with a class of trusted, capable users to maintain static versions, but agree maybe admins aren't automatically suited to the task. I don't think it would be too hard to establish a set of non-admin but trusted users.
Third, well the perception among our critics is that no article at all can be trusted because it might just have been vandalised - a perfectly valid criticism of a wiki, and one that can't be rebutted without static versions of articles. I think it's far more of a PR blunder to insist either that all articles can be trusted, or that we don't need to do anything to counter the belief that a wiki encyclopaedia is inherently unreliable.
Fourth point, well I just disagree here. Errors exist in all encyclopaediae. Static versions would still be easily editable and any error identified would probably be corrected within minutes, compared to the years our rivals often take. I cannot for the life of me see how identifying articles that are guaranteed to meet high standards and have not been recently trashed could open us up to criticism.
General comment - would you mind not bolding so much? It looks a bit shouty.
Further general comment - allowing anyone to edit is great for writing articles - perfect in fact. But keeping articles at a high level of quality in a wiki is like spinning plates. The more you have, the more difficult it becomes. Articles such as Sun, if not watched incredibly carefully, degrade substantially over short timescales because people add to them in well meaning but detrimental ways. Experts wrote it, and allowing continued unhindered access to anyone and everyone means that article will decline in quality without serious effort being expended on watching it. Why is that a good thing? Static versions could solve so many problems. My own essay on this is at WP:STATIC. Worldtraveller 00:30, 12 July 2006 (UTC)
We have static versions: the versions of good and featured articles that were certified "good" or "featured". We can link directly to these static, stored versions from good and featured articles. In fact, my proposal appears similar to a couple of the suggestions in WP:STATIC, except it uses the mechanisms we already have to decide on static versions. No new classes of user are needed. (No new designated space would be needed either, though per suggestions on your page it might be useful.) What is your opinion of linking to the static good and featured versions of pages, leaving the dynamic version as the default? JDoorjam Talk 00:42, 12 July 2006 (UTC)
It's a viable solution, but I'd far rather the static version was the default view for viewers who aren't logged in (preferences could be set to change this for people with accounts). Making the assessed version remote from the reader seems odd to me, although it's certainly a step in the right direction to at least have a link to it. Worldtraveller 00:51, 12 July 2006 (UTC)
I think now we might be on to something. Make the GA and FA versions of articles the default for logged-in users and for people with accounts; people with accounts can switch it so the default is the dynamic version. For G/FA articles, at the top of the page for IPs it would say,
"you are viewing the static version of this article, which has been reviewed and deemed a good article/featured article. Click here to view the dynamic version of this article."
This would mean keeping the GA/FA system we have now, and not creating any new user classes. There wouldn't even really effectively be different name spaces for each. It's more like we'd have two different modes, "Editor Mode" and "Reader Mode", with the default in the latter. While it would mean our poor developers would have their work more than cut out for them, the casual reader wouldn't even notice. Now, this still leaves the Increasingly Powerful Admin Dilemma, as, again, admins should probably be able to get under the hood to make minor changes to static pages. It would also mean that, for this small but growing set of articles, anon IPs new to the scene would have to get out of Reader Mode, view the Editor-Mode article, see whether the change they were considering is even relevant given the different state of the article, and then make the edit, rather than simply being able to click the tab and dig into the code. I suppose this could be [[cookie {computer|cookieable]] so that anons could at least stay in "editor" mode for the entire session. It's unfortunate that all of these scenarios seem to be adding layers of obstacles between the newest editors we have and the articles they're trying to edit; I'm also concerned about any move that give sysops even more relative power. But this move would protect our very best articles and put them on display without really removing any editing access from anyone (just making it slightly trickier).
.... or maybe you hate that idea. Thoughts? JDoorjam Talk 01:16, 12 July 2006 (UTC) On my way home from work I decided this is overly complicated and requires an overhaul of all the Wiki code... I decided to fall back in love with my original idea, and have links from the pages to the stable GA/FAs. We could do that right now, as it wouldn't take any system changes whatsoever (just minor tweaks to FA/GA guidelines and templates) and would probably be a good warm-up step to get people used to the idea of fixed articles. JDoorjam Talk 02:46, 12 July 2006 (UTC)
I have some comments of JDoorjam's four points:
  1. "The first is a micro-scale change: an article that has been stabilized seems 'done'." Not to me, in fact, if I might use my own expository activity as an example, I find that I have been most enthusiastic about further improving articles which I have already worked on extensively. Typically, I can see room for significant improvement after intense work, but some time must pass before I am ready to implement changes which previously were only a glimmer in my eye. Unfortunately, in several recent instances, I was frustrated by ill-thought radical changes to articles I wrote which I thought were both valuable and highly improveable. It can take quite a bit of time and effort, first to get something written down in an organized way comprehensible to experts, then to render it truly comprehensible to a general audience requires a new round of concerted effort, and a certain "latency period" must be observed. But other editors (who lacked the expertise to see the value in waiting for coming improvements) were too impatient and replaced all my hard word with mathematically incorrect and otherwise misleading claims.
  2. "Article stabilization separates administrators even more from other editors." I proposed above that admins could grant stabilization/destabilization privileges to nonadmin users they know well enough to entrust them with that specific power without futher direct admin intervention.
  3. "This process implies to the outside world that the vast, vast majority of our articles cannot be trusted." I don't agree, but if I did, I'd say: a damn good thing! Don't you realize how badly it looks to outside commentators that some Wikipedians, confronted with a conflict between widely accepted realities and classic arnarchowiki ideology, choose to insist on denying reality so that they can cling to a clearly counterfactual item of dogma? That is what makes Wikipedia look ridiculous to many, not the fact that the brave assertion that wiki articles are naturally attracted to perfection has been proven not be correspond to reality here at Wikipedia, N years into the project. "It is an admission that the Wiki process is so flawed that you cannot trust an article that has not been certified, stamped, signed off on." Yes, exactly: this is the true state of affairs, a fact which is very widely appreciated by the outside world. The first is why WP must change its ways or die; the second is why Wikipedia community is regarded as extremely foolish when it refuses to change its ways in order to adapt to a rapidly evolving world.
  4. "Worse, this opens Wikipedia up to more criticism, not less." I think you might have missed a key point about SVN: it slows down the pace of major changes to stable versions, which tends to prevent the kind of hasty error (or whatever it was) which briefly occurred in the Ken Lay article. Which is worse: the hypothetical possibility that someone who has granted stabilization privilege by some admin will accidently/foolishly/maliciously stabilize some character assassination, or the demonstrated possibility that currently inflammatory and false statements can appear at any moment in even the most visible WP articles, and even survive for months despite the alleged army of watchful eyes? ---CH 06:31, 16 July 2006 (UTC)

[edit] Btw, there's a technical flaw:

.... articles can't be moved to [[Articlename/development]]. That's not a sub-section; that's an article called "Articlename/development", just as and/or is about the logic term and is not a sub-page "or" of article and. the / thing works to make sub-pages in WP space and User: space, but doesn't work the same way in article space. JDoorjam Talk 01:34, 12 July 2006 (UTC)

/Illustration—The preceding unsigned comment was added by Ancheta Wis (talk • contribs).
I'm aware that it's technically not a 'subpage', but it's *highly* unlikely to conflict.. and thats all that really matters for this. --Gmaxwell 02:01, 12 July 2006 (UTC)
(edit conflict) Great -- but try it in article space. It doesn't work. JDoorjam Talk 02:02, 12 July 2006 (UTC)
See this --Ancheta Wis 02:09, 12 July 2006 (UTC) Reference: Wikipedia:Namespaces
This example is in Project space (Wikipedia:Stable versions now, rather than Stable versions now), not article space.--ragesoss 02:16, 12 July 2006 (UTC)

[edit] more freedom lost

This is nothing more than endorsing a version. WHat's next? Corperations paying to have their version of an article stabilized? This just another step closer to the end of an "anyone can edit" encyclopedia. American Patriot 1776 03:18, 12 July 2006 (UTC)

Ok, here's the not hot head version. Yes we need a somewhat stable version but it would have to go through a vigorous examination. More so then an FA or RFA. If we start slapping around stable carelessly, then thinga are going to get messy. Try it out for a bit. American Patriot 1776 03:21, 12 July 2006 (UTC)

Do you think reverting vandalism is bad, too? —Bunchofgrapes (talk) 03:22, 12 July 2006 (UTC)

I beg your pardon? American Patriot 1776 21:28, 12 July 2006 (UTC)

Reverting vandalism can be seen as a restriction of a vandal's ability to edit. Taking "the encyclopedia anybone can edit" too literally can lead to some odd conclusions. —Bunchofgrapes (talk) 21:33, 12 July 2006 (UTC)

Ok... restriction of people who add useful content. American Patriot 1776 21:37, 12 July 2006 (UTC)

I strongly support giving SVN a try, but FWIW, I too would be horrified at the very idea of corporations paying to slant articles in their favor. Actually, that is surely already happening due to shilling and guerilla marketing, and probably on a large scale, since manipulating the WP seems to be one of the few known ways of raising your Google page rank. I've been spending quite a bit of effort monitoring bad edits to the physics pages since last September and have uncovered quite a bit of malfeasance, but not much which looks like guerrilla marketing, but that is probably due to the nature of the subject matter. I have seen quite a bit of evidence that "inventors" of dubious "energy from the vacuum" schemes have tried to promote their "products" at WP, which tends toward attempted fraud, in my view. One point here is that the most determined attempts to slant a given WP article need not be paid; not at all. But they can sometimes me motivated by the lure of big payoff. ---CH 06:41, 16 July 2006 (UTC)

[edit] An example of linking to stable versions using FA protocols and the system we have now

Guys, I was talking above about using the article history of good and featured articles to link to permanent versions now, without having to juggle the main page. I've created an example using a randomly chosen featured article. As you can see, I've put a subtle banner across the top saying that there's a static version available, and linked to it; you can even see the difference between that article and the current one. This way, we have our static articles already, we have 1,000 Featured Articles and who even knows how many good articles that we can set this up on right away, and we have our "certified good" version that people can look at, while still editing the main page as always. Any and all feedback would be appreciated, here or on the talk page of the example I've set up. JDoorjam Talk 05:48, 12 July 2006 (UTC)

Personally I like the idea of having the editable version as the default, with a stable/static version for those requesting it, but the main problem with the above method is that there is nothing stopping a vandal changing the target of the stable version to a vandalised version (or editors edit warring over which is the "approved" version). Regards, MartinRe 07:54, 12 July 2006 (UTC)
I greatly prefer this proposal. The FA process would have the additional charge of applying the label explicitly to a single revision, but given that, I would not worry too much about the links to that version being vandalized. Unlike this page's proposal, JDoorjam's maintains our successful philosophy in full, does nothing to discourage editing, and does not add bureaucracy (which would be confusing to novice editors, and extremely time consuming for others). ×Meegs 08:18, 12 July 2006 (UTC)
I prefer this proposal too, but feel it would have difficulties in implementation. Until we have the option of "protected section" or similar, there will be the risk that the target would be changed, and also if someone followed the stable/featured version link, and spotted a mistake, it would be too easy for them to edit it, miss the "out of date warning" and wipe out the development version (as it's not protected). That said, the SVN proposal also has difficulties, my main concern is that it expands the protection policy to cover highly edited pages as well as highly vandalised pages. Also, I don't think the "de-stabilisation" aspect would work in practice, if a stabalised article turns controversial, the proposal says that it should be updated to the development version and unprotected, but in practice, I think it would be more likely for an admin to say "work out the issues on the draft/talk page, and in the mean time the article is remaining protected (at the stable version) to stop edit wars. Regards, MartinRe 12:31, 12 July 2006 (UTC)

I think that the banner is ugly, but I'm sure that can be changed :) Otherwise good idea. - FrancisTyers · 11:56, 12 July 2006 (UTC)

I much, much prefer this proposal. It's taken a while for me to work out why the original proposal made me unconfortable, and I think I now realise why. It's entirely to do with which version someone comes across when they go to an article. It is a huge change to the whole mentality of Wikipedia if, when someone goes to Linus Pauling (for example), they get an article which they cannot edit. Effectively, what we're saying is, "you can submit changes, but they won't really be part of Wikipedia until someone else has looked at them and reviewed them". That's not Wikipedia any more, as far as I'm concerned. The default setting should always be that you get an editable version - the stable version should be the one that takes an extra click. --OpenToppedBus - Talk to the driver 12:05, 12 July 2006 (UTC)
Ditto. This method would be acceptable... highly beneficial even. The changes suggested on the project page, most notably the editable version being on a sub-page rather than the default article displayed, are not remotely acceptable to me. Having links to a 'stable version' in the history for articles would be great. They could be reviewed and updated from time to time, could include a link to comparison against the current article, et cetera. --CBD 12:12, 12 July 2006 (UTC)

Doing so would not reduce any incentive to vandalize (in fact, it becomes a target for vandalism itself), it would not provide any incentive to editors to keep the stable version moving forward, and it would not be used by readers... a majority of whom miss the fact that they can edit, even though a typical article has a half dozen edit buttons. I don't have any objection to doing this, but I wouldn't expect to achieve any substantial gains from it. It's also simple enough that I don't think we need any discussion for it... if you think doing that would help something: just do it. --Gmaxwell 12:34, 12 July 2006 (UTC)

Of course it would help if FAs were factually verified, but pigs might fly :) - FrancisTyers · 12:38, 12 July 2006 (UTC)
Actually, we easily can protect the link to the protected article. All that needs to happen is to put the banner on the top in, say, template space, and protect it. So, for instance, this one would be Template:Featured article/Linus Pauling. The template gets locked, and while, yes, a vandal could remove the template, that'd be rather obvious, and anyone (or any bot) could notice and fix its removal. Again, I acknowledge, it's one more teensy layer of work, but it's a simple fix to what seems like the only objection I've heard so far. JDoorjam Talk 14:25, 12 July 2006 (UTC)
There's also the other issue that MartinRe raised above, that prominent links to a version in the history could lead to inexperienced editors unintentionally wiping-out later changes if they miss the "You are editing a prior version of this page" warning. I'm having trouble estimating that risk. ×Meegs 15:11, 12 July 2006 (UTC)
Ah, now that is a concern (though, of course, "wiping out" is easily unwiped out by a revert). I have a couple suggestions about mitigating that, too (though with the current software, you're right, it's not possible to wholly prevent). I'm going to put something together at Wikipedia:Stabilizing Featured Articles which will outline my proposals on the matter; I'll let y'all know when that goes blue. JDoorjam Talk 15:15, 12 July 2006 (UTC)

I much prefer this proposal, much along the same lines as OpenToppedBus. I think having the primary version be protected is counter to what Wikipedia has been up to this point, and having your changes shoved off into some corner where you don't know when it will be implemented (a day? two days? a week?) is an unsettling feeling, and I really think it would discourage editing. I also think that protecting the main versions of a large amount of articles would garner us quite a bit of bad press- I mean, we got bad press because of semi-protection for crying out loud. Anyway, I think the aim to have stable versions that readers can trust is a great one, and I think at this point in time JDoorjam's suggestion is the best way to do it. EWS23 (Leave me a message!) 03:47, 13 July 2006 (UTC)

I do not prefer this proposal; or, more specifically, I do not believe this proposal addresses the same problems the original proposal does. As far as I can tell, this proposal offers benefits only for republishers (mirrors, CDs, print versions). Very, very few interactive browsers of the encyclopedia -- you know, the readers? -- are going to bother to click on these little links to make sure they aren't looking at a vandalized version. I'm a lot more interested in benefitting the millions of Wikipedia readers and boosting the overall reputation of the encyclopdia than I am in making life a bit easier for the republishers. —Bunchofgrapes (talk) 04:01, 13 July 2006 (UTC)

The "readers" of wikipedia.org are not, and cannot be, our primary audience, no matter their numbers. Wikipedia.org is a website with one central purpose - "to write an encyclopedia". That's what we do here, that's what we are for, that's the purpose of all 150 servers the Wikimedia Foundation has scattered around the world. We write an encyclopedia here. We do it by means of volunteers, most of whom joined us because they came across the site looking for information. Information is our hook - it's what we use to get people interested enough to edit. Wikipedia.org is not here to provide information - Wikipedia.org is here to assist people in creating (well, really summarizing and organizing) information. In a very real way, the whole point of displaying articles at all is simply as bait to convince people to click the edit button - clicking the edit button is what we really want them to do. We only provide a public, web-based distribution of our content to entice people to edit. As one of the goals of the Wikimedia Foundation (and, presumably, of most of the members of the Wikipedia community) is to distribute knowledge to the world, it may be a good and important thing for Wikimedia and the community to set-up, pay for, and maintain a public, web-based distribution of all the knowlege we can (primarily the material we've created through wikipedia.org), but that project is distinct from the purpose of Wikipedia.org. As I said above, Wikipedia.org has one purpose, and that above all else - to write an encyclopedia. We should not sacrifice it for anything, even for distributing the results of that work. JesseW, the juggling janitor 01:39, 14 July 2006 (UTC)
Interesting perspective -- I somehow haven't run into or been made to think about the distinction before. Under that view, what is the point of any of these stabiliation or identification plans -- what's the value in tagging consensus version at all? —Bunchofgrapes (talk) 01:54, 14 July 2006 (UTC)
Oh, I can explain that! The benefits to editors of identifing a consenus or reviewed version include: 1) The ability to easily identify changes between the reviewed version and the current version; at this point, there's no easy way to group "all-the-changes-that-haven't -been-reviewed-yet", making identifing subtle vandalism or mere innocent mistakes harder. 2) The ability to feel more confident that they can work on an article, get it well arranged (good grammar, well-sectioned, fully verified, etc.), and have that good arrangement remain avialable and identified, even while work on expanding the article continues. Those are the top two that come to mind, but I'm sure there are others. Those reasons are why I'm interested in and supportive of this proposal, not for any puported benefits to readers, or decrease in vandalism. JesseW, the juggling janitor 02:17, 14 July 2006 (UTC)

Yes, this is an approach I was going to suggest myself after reading the Signpost story. Support JDoorjam idea, oppose the proposal as current. The main article must be editable in the spirit of Wiki.--Piotr Konieczny aka Prokonsul Piotrus Talk 16:47, 15 July 2006 (UTC)

Ditto Bunchofgrapes, that's a perspective (JesseW's) that I hadn't considered before. I'm not sure though. What's the point of a encyclopedia? I think we can agree that we want it to be read; otherwise we're wasting our time. And I think that regardless of what happens, our primary audience will always be online. Even though we are gaining more and more offline opportunities to spread our content, the internet continues to grow and reach to the corners of the world. Thus I'm skeptical; it seems counterproductive to not consider our online readers except when trying to lure them in. And it seems inherently backward to use the internet to create information and paper to distribute it, especially as newspaper profits are plummeting and they are scrambling to add online content. Or are you suggesting that mirrors like answers.com ought to be the primary distributors of our content? --Spangineeres (háblame) 19:32, 15 July 2006 (UTC)

[edit] Destabalisation in practice

While I applaud the concept of stable version, one of my concerns is that this policy would extend the protection policy from heavily vandalised pages to heavily edited pages, and requiring an admin to publish the stable version on the main article page, does change the motto somewhat from "anyone can edit" to "anyone can edit, but everything needs to be checked by an admin first before acceptance". Anyone can edit is one of wikipedia's greatest strength, but also one of its greatest weaknesses (vandalism, etc) and we should be careful not to throw the baby out with the bathwater.

In theory, this proposal may work, but I think it will work differently in practice, especially the "destabalisation" concept. If a heavily edited article with a stable version turns controversial, this proposal suggests that the response would be to change to the development version and unprotect (and possibly immediately re-protect in the development state due to edit wars). However, I think it might be end up more often for an admin to say "work out the differences on the draft/talk page, and until then the article stays protected (at the latest stable version). I think very few admins would choose to protect at a version in the middle of an edit war, if they had the option of leaving it protected at a previously agreed stable one.

The logistics of choosing a stable version also bear thinking about. If an example article gets say 10 good edits a day, how long will would it take to pick a suitable version? For every day the "voting" goes on, ten more good versions appear, which will proably attract later votes, as it'll be a rolling vote with no clear winner. Or will it be a rolling window with "best version on/before X day", and further stabalised every Y days, with another vote whether "versions on/before X+Y date" is better than current stable one. In either case, there will be a lot of discussion on the talk page over which version to pick, which will surely distract from actually improving the article?

As I said, I like the idea of stable version, but see too many problems in practial and logistic terms for it to be workable. However, I'll be watching with interest the results of the trials, to see if my concerns are borne out or not, as I've been pleasantly surprised before! Regards, MartinRe 13:03, 12 July 2006 (UTC)

[edit] Default to 'stable' or 'editable'

I think most people agree that some sort of 'stable version' system is a good thing. Whether it is located in a separate namespace, specially named article-space page, talk sub-page, history link, or where-ever and how the process is administered are details which need to be worked out but which should not present great difficulties to resolve.

However, I think there is strong disagreement about whether the 'stable' version or the 'editable' version should be the 'default' when someone types in a term and clicks 'Go'. I think the ideal would be for the user to be able to choose to either always get the 'editable' version or default to 'stable' and get the 'editable' only if there isn't a stable version available. Unfortunately, any such option will need to wait on code changes. In the meantime, if we are going to move forward with 'stable' versions we need to agree upon what page is displayed by default.

I am strongly opposed to 'stable' being the unalterable default because it completely changes the way Wikipedia is supposed to work. If a correction is needed or new information about a subject becomes available it should be possible to update the page and display it immediately... not wait to gather consensus that the edit (and all other edits over a span of a few months) is acceptable for display. Yes, the 'editable' version of the page updates immediately... if the user knows where to find it. If a casual user goes to fix an error and gets blocked because the page is protected they may not even know that an editable version exists. Likewise, you shouldn't have to guess whether to type 'Articlename' or 'Articlename/development' to get to an article you want to update. When you click a wiki-link you should get to a page you can correct rather than one which is static. Uneditable by default just isn't the way Wikipedia is supposed to work. Editable versions should be the default display with 'stable' versions as a 'clean backup'. --CBD 13:13, 12 July 2006 (UTC)

I agree that users should be able to choose. Hopefully the software upgrade allows people to pick in their preferences which they want to appear as default. For those wanting static versions, the development version would appear only if there isn't a static version available. In that case, I feel that anonymous editors should be pointed to static versions by default, and that those who have accounts would be able to switch the default to the editable version.
But as of right now we don't have a software upgrade. I think it's unnecessary to assume the worst case all the time (that it will always take several months for any changes to be made to stabilized versions), and there will be links at the top of every page describing how to make changes, but I agree, this issue of which version is the default is significant. An editable default doesn't do too much good at this point, so maybe we ought to test the other idea (static default) now and see what happens. Why don't we, as noted in a section above, do a test of 20 articles—implement this on 10 and leave 10 as a control group, and see what happens? --Spangineeres (háblame) 13:40, 12 July 2006 (UTC)
I can't honestly see the point in having static versions, if they're not going to be the default view for the casual visitor. It would be quite simple, I think, to set up preferences to allow logged-in users to choose which they display, but for readers, it seems to me to make perfect sense that they see the version which is guaranteed not to have been vandalised, and has been reviewed and deemed worthy of a static version. This way, we also provide a large incentive for editors to improve articles to the point where they can be made static. Worldtraveller 14:07, 12 July 2006 (UTC)
I'm curious as to what you expect to happen. How would we know whether the test had been a success or not? What will be the measurables? --OpenToppedBus - Talk to the driver 13:59, 12 July 2006 (UTC)
Vandalism is one thing, and lag time is another. I'd expect the amount of vandalism to drop significantly, since vandals wouldn't be able to edit the page that appears to all readers. Vandalism patrol would still have to whack vandalism to development versions, but it wouldn't be as critical. Lag time, as you and others have pointed out, is a potentially serious problem, however. I'm not sure how it would turn out—best case would be that insignificant improvements are added to the article within hours and that good, substantial edits are added to the article within days. Of course, there's the potential that such additions would be delayed (backlog, not enough admins, inability to get a group together for consensus). That lag time would then have to be compared to the bad edit lag time of the articles in the control group--how long it takes for vandalism and less than helpful edits to be reverted.
There is the potential for bias--there are alot of admins supporting and opposing this idea on this page, and thus it'd be pretty easy for all of them to add the articles being tested to their watchlists. We'd end up with restabilized articles every few hours if necessary, no problem. Similarly, the extra attention would make people revert vandalism of articles in the control group more quickly than they otherwise might. So perhaps to simulate real work conditions, pick one or two admins who are allowed to restabilize versions. Pick a category of articles that they aren't familiar with, so that they have to work to judge the value of contributions (just like they'd have to do if this were implemented on a wide scale). Pick some FAs, some GAs, and some B-class articles. Make a control group with a similar composition of articles, by both quality and subject, but don't tell more than a few people which articles are in that group until after the fact to prevent it from getting extra anti-vandalism attention during the test. Let the test run for a month, and see what we learn.
We wouldn't be able to judge the effect on our image ("what do you mean my edits won't appear instantly!"), but we already have that with existing protected and semi-protected articles, as well as no page creation for anons. But if we were able to, say, show that stable versions helped the Britney Spears article cut 90% of total vandalism edits while maintaining an average good edit lag time of 5 hours compared to a 3 hour bad edit lag time on the non-stabilized Mariah Carey article, we'd at least have something real to talk about rather than just saying "I do/don't think it will work". Shall I put together a proposal page/essay for something like this? --Spangineeres (háblame) 14:39, 12 July 2006 (UTC)
I have serious doubts as to whether you can effectively eliminate the bias issues you identify above - the very nature of Wikipedia makes blinded experiments difficult and double-blinded virtually impossible - but I'm open to being convinced. In the meantime, though, I much prefer the "stabilized featured article proposal" being discussed above. --OpenToppedBus - Talk to the driver 16:10, 12 July 2006 (UTC)
I think the main measurable I am interested in is whether stabilizing an article results in less contructive edits being made to the delvelopment version than would be made to a regular article. Mainly I think the proposal is good, but we need to be sure minimize the side effects. I imagine the exact wording of the templates will have a large effect on how "encouraged" people feel to find the delvelopment article and edit it. If people try to "game" the trial run it should be easy to tell. We can disreard those results, but I do not think it should be a problem. Surely everyone interested in the proposal (for or against) would be interested in seeing some examples of what would happen in practice.--Birgitte§β ʈ Talk 17:09, 12 July 2006 (UTC)
I'd have a problem with anons (let alone everyone) being forced to 'stable' versions unless we had some very specific / high standards for stabilization. For instance, articles on 'current subjects', should then IMO never be stabilized no matter what their quality... all articles on living world leaders should remain unstabilized because they could die or do something else noteworthy. Stabilization should be a counter to vandalism and deteoration... never an impediment to needed editing. Any page on which there is or may likely be more to say should never be protected from immediate edits over a long period of time. That'd be counter to the entire premise/foundation of how Wikipedia works. If stable = not immediately editable then it should have standards even higher than FA - basically requiring that the article be of professional caliber at least the equal of what could be found in a major printed encyclopedia covering the topic... and then only on subjects unlikely to require significant change/expansion. I'm talking about people going through and verifying that every reference is on point for the facts it is supporting, that the writing is professional quality, that all stable articles follow consistent style standards, et cetera... exacting review to verify that the version being made stable is something that could be released in a printed encyclopedia and still be an excellent article after sitting on someone's shelf for a decade. On the other hand, if the 'stable' version is more like a 'backup for reference', and not the default displayed, then I think any reasonably good version on any article could be 'stabilized'. The standards currently described fall more towards the 'reasonably good' end of the scale... and I cannot agree with permanently protecting every article which achieves a 'reasonably good' version or anything close to that. If 'stable' includes protection from immediate editing then it should only be applied to articles which we can reasonably expect not to need immediate edits. --CBD 11:14, 13 July 2006 (UTC)
One of the main benefits of stable versions is that they prevent slander from showing up in the articles on living people (and thus eliminate alot of legal headaches; hence the above support of the foundation leader/lawyer). There are articles with moderately high vandalism rates that aren't semi-protected, and as a result, there's some small percentage of time that the article says something ridiculous. Then of course there are the high quality articles that degrade—just look at any FA that doesn't have its author watching over it, and you'll see what I mean. People add sections of badly written prose, failing to realize that the same point is summarized two sections below. Or they'll happily insert unsourced and dubious information, and there it will sit.
If we say that an article has to be perfect to get a stable version, there's no point in having stable versions because they won't be used. We're not suggesting here that articles should be protected forever. As I said above, we could implement something like WP:AIV so that within minutes any article could be destabilized or restabilized in an emergency (like someone famous dying). It's obvious that more improvements can always be made to any article (even if it's at the "professional" level you're talking about), but that's OK. We create a system that allows them to be updated quickly but that doesn't permit vandalism or content degradation. Yes, a delay would exist, but people use answers.com all the time and they don't seem to mind that the information is a week old. Personally, I think the average reader would be willing to sacrifice a few minutes or hours of new information if they were able to have greater confidence in the accuracy of the information they did see. --Spangineeres (háblame) 12:49, 13 July 2006 (UTC)
I don't see the turnaround times you suggest as feasible. Any 'unlocking' of the page to receive new edits is going to require admin action and that will create a significant bottleneck. Take one of those 'living people biographies' as an example... assume it was stabilized and then the development copy received those standard edits where people "add sections of badly written prose", "insert unsourced and dubious information", et cetera... and then the person dies. How do these admins notice that the 'request to unlock', one amongst hundreds (thousands?), for that page has switched from one where 'Joe Editor' has added 'unsourced and dubious information' which he wants to see updated to the actual article and a request to add the fact that the person died? Once found, does the admin just 'unlock' the page with the 'bad' edits to that point intact? Are admins now empowered to police the content and unlock to the >stable< version rather than the development page or review the changes and decide which to keep?
This 'sacrifice of a few minutes or hours' was unrealistic, and one of the fatal problems, when such a structure of 'review for accuracy before approving' was used on Nupedia. The results here would be the same. Admins should not be in the role of deciding what to incorporate and what not... but even if they were it does not seem possible for a thousand admins (or whatever) to review the edits of hundreds of thousands of users to 'biographies of living persons' and other 'protected' pages in a timely fashion - and even more implausible to think that such decisions could be quickly made by consensus.
As to 'preventing slander from showing up'... this proposal wouldn't do that. The slander could still be added to the 'development version'. It could still be viewed, copied, and indexed by search engines. IMO that goal could only be achieved by policing all edits to every page before they were applied... which is clearly impossible and contrary to the fundamental nature of Wiki collaboration in any case. You aren't talking about just having 'stable versions' of pages available... that just requires a link to the history. Rather, you are talking about a vastly more restrictive form of 'page protection' which would require some sort of consensus or admin approval of further edits. --CBD 10:57, 14 July 2006 (UTC)
Re turn around times: perhaps a distinction like the one that exists between WP:AIV and the content dispute reporting system could reduce the issue. Only "emergency" reports would be added to the AIV equivalent, while consensus-backed changes would be listed somewhere else. People do a pretty good job of clearing content disputes off of AIV, so maybe the same would be possible for a parallel system for stable versions.
As for destabilizing to an inferior article, so what? We're no worse off than we were before stable versions existed. In fact, we're better off because the bad edits don't appear in the article immediadetly—they sit in the development version until destabilization occurs. Once the inferior version is the primary version, it will presumably get alot of attention (since the reason for destabilization was that it needs major edits) and the problems will get fixed just like they are currently (via the wiki).
Re Nupedia: Nupedia was different because all content, from start to finish, was created in a controlled environment. As others have pointed out, a Wiki is a valuable tool for developing articles but not for maintaining their quality. Thus, only articles that have already taken advantage of the wiki's strength and reached a certain level of quality (which would have to be determined) would be able to be stabilized. It is a significant change, and it is more like Nupedia, but think there's still a significant difference between the two.
You're right about the vandalism to the development version, but consider: how many vandals will stick around when they know that their work isn't going to appear on the actual article that people see? It becomes an exercise in futility (what fun is there in vandalizing the sandbox?), and I suspect that numbers would drop significantly. The time saved by vandalism patrol could then be applied to other activities, like, say, stabilizing articles =). Unfortunately, the only way to find out how much vandalism will go down is to implement the system. A controlled test run (or at least as controlled as Wikipedia can allow) might give us an idea though.
I don't want "stable versions" as links to the history, because that's useless. I want to be able to create a great article and not have to worry that it'll degrade into a mess of inaccurate and unsourced garbage if I go on vacation. I also want Wikipedia's reputation to improve. I don't think that these desires are incompatible with this being a free encyclopedia—I don't support locking down the wiki and monitoring all edits, and I don't want to protect pages indefinitely. I'm optimistic that we can set up a system that allows us to lock articles and yet be able to make consensus-backed updates frequently (on the order of hours or days, if necessary) and unlock them immediately (on the order of minutes). --Spangineeres (háblame) 13:28, 14 July 2006 (UTC)
To reword part of what you wrote just slightly (one word), "Consider: how many editors will stick around when they know that their work isn't going to appear on the actual article that people see?" The satisfaction of seeing their work included drives our contributors just as much as it drives the vandals. The idea of 'stable versions' can be implemented with anywhere from 0% impact on vandalism to near 100% reduction of vandalism 'tacked on' separately... but the greater the reduction in vandalism the greater the impediment to editing will be. Wikipedia exists and has been successful because it goes so far to not impede editing. When 'semi-protection' came out there were news stories about how Wikipedia is no longer 'allowing anyone to edit'... even though semi-protection is actually less restrictive than full protection. The system you describe would clearly be orders of magnitude more restrictive, and IMO is a bad idea both for "Wikipedia's reputation" and the actual viability of the project. I'm all for identifying 'stable versions' that have been reviewed for accuracy... but that isn't what this proposal is about. That can be done without the rest of this. The proposal here is really to sacrifice ease of editing in order to reduce vandalism (with 'stable versions' as a backdrop)... which has been consistently and soundly rejected every time it has come up in the past. --CBD 12:50, 15 July 2006 (UTC)

(de-indent) It's a question of balance and article maturity. A near complete article will almost always need something removed for each thing added, so a discussion or consensus process should happen before articles are changed on such articles anyway; meanwhile, the chances of any given edit being either vandalism or good faith but not worth keeping begin to overwhelm the improving edits. I think there are many articles that would currently benifit by stable version, both by reducing vandalism and making editors more thoughtful and less impulsive in their edits.--ragesoss 12:59, 15 July 2006 (UTC)

[edit] Forking

What's to stop people from saying, "I don't like what you're doing so I've made my own draft work page, here, everybody come over here and work on this one instead"? I know that I've worked on pages where users have made re-drafts of the whole page, built consensus, and then replaced the original article with their redesign. But when the main page to edit is itself just a draft, what's to stop competing drafts? Wouldn't they have about as much legitimacy? Is this a concern we should have? JDoorjam Talk 17:23, 12 July 2006 (UTC)

Forking is not the ned of the world provided the forks converge back to one version after trying out alternatives. Having one stable version encourages that. none of the forks should replace the stable version until there is consensus on one version.Filceolaire 16:35, 13 July 2006 (UTC)
I guess that's my question: how do we decide which fork "wins"? Conference committee? This wouldn't be an example of the article deteriorating, so destabilizing the stable version wouldn't solve the problem. In real life I'm sure some sort of compromise could be reached, and who knows whether this is a realistic scenario, but I'm wondering if there's not a uniform way to do it. JDoorjam Talk 18:05, 13 July 2006 (UTC)

[edit] People are discrediting this

If people will insist that this be jammed down people's throats whether they want it or not (like Special:Whatlinkshere/Template:Stablenotice and a few editors) then it will just become discredited. THe proposal is interesting, but still actively under much discussion, with a number of possible variants, is plainly not yet widely accepted, and also has some well-argued opposition (and support, too, of course). People, please just take a step back, and stop presuming that we should slap protection on articles left, right and centre just because someone proposes it. -Splash - tk 20:16, 12 July 2006 (UTC)

Who or what has insisted "that this be jammed down people's throats whether they want it or not"? I (the proposer on Warren Beatty) certainly had and have no intention of jamming anything down anyone's throat. I nominated the article as a test case, for purposes of discussion, in which it has, and continues to, serve quite well. I haven't read all the other nominations (about 6, when I last checked), but I don't really understand what you are going on about jamming anything anywhere. Of course we wouldn't slap protection on articles just because someone proposed it. JesseW, the juggling janitor 20:28, 12 July 2006 (UTC)
8, actually. usemod has an article that explains why starting discussions on nine different pages is actually most likely a bad idea. JDoorjam Talk 20:38, 12 July 2006 (UTC)
Heh. Touche. I was hoping the other discussions would be related to the specific articles, and this one would be more general, but, your point is certainly taken. JesseW, the juggling janitor 21:13, 12 July 2006 (UTC)

[edit] Simpler suggestion

Unfortunately, this comment may get lost in the long discussions above, but I really hope that people take the time to consider my thoughts.

I have thought about stable versions for some time now, and my thoughts have all been similar to this proposal. However, I see no need to split the pages up. A much simpler solution that achieves almost identical results is this: nominate a particular version of the article to be the 'stable version'. Once a version is agreed to be the stable version, a notice can be added to the talkpage that says This article's stable version may be found at [5]. Such a system halves the effort in the current proposal. We no longer need to move the pages around to set up the stable and development versions. We no longer need to delete the stable versions when their stable status is revoked. We no longer need admins to protect the stable version. All we need is a template on the talkpage. Ingoolemo talk 00:52, 13 July 2006 (UTC)

An easy template:
''A stable version of this article can be found [{{fullurl:{{SUBJECTPAGENAMEE|oldid={{{version|1}}}}} here].''
You could call it by writing {{stable|number}}, {{stable|1=number}} or {{stable|version=number}}. For example, with 2005 Pacific hurricane season, you could have:
A stable version of this article can be found here.
Titoxd(?!?) 02:34, 13 July 2006 (UTC)

But a vandal might tag a vandalized version as stable; people would then be unable to see if it is really stable without looking through the page history. And most Wikipedia viewers don't know how to do that. I think it might defeat the point of stable articles. -- Where 02:51, 13 July 2006 (UTC)

Would there be some way to set a user option (or custom .js file) to automaticlly follow links to stable versions. Also a small icon like the star for FA might be a good option rather than just a note on the talk page. Then the debate about sending non-logged in users to the active version or forwarding them to stable versions can start ;) Dalf | Talk 05:18, 13 July 2006 (UTC)

Stable versions are for casual visitors, not for power uers who have preferences set and understand talk pages etc. Power users already understand how to get back to a stable version by checking what has happened on the talk and history pages. The stable version has to the default version or else it is not worth doing. (and I'm still not convinced it is worth doing)Filceolaire 16:01, 13 July 2006 (UTC)

[edit] What happens when the development version clearly deteriorates in quality?

I really like this idea, I think I should say that right off. But, when thinking about the syncing back up issue I started to think about articles that get worse. It happens, some times there are low grade content disputes that never quite reach the status of edit wars, some times its a slow drift to bad prose. What happens when the 3 month limit comes up and the development version is clearly worse? I think there should be some sort of discussion re-syncs should be discussions not automatic and that revers syncing from the stable version to the development version should be an option (if there is consensus to do so). Ideally that would never happen and if there was consensus that the stable version was better then a merged version might replace the development version or some such. Dalf | Talk 04:55, 13 July 2006 (UTC)

I wanted to add that I think this is an important question since the main point, as I understand it, of stable versions is to protect quality /trustworthy articles. The way the proposal is written it seems to me that it will in most cases favor "damaged" development versions by destabilizing the article in almost all cases. I also am not sure that there is an easy solution to this (though I did suggest one above) since any solution that gives strong protection to any version is at odds with at least some of Wikipedia's perceived core values. Dalf | Talk 05:07, 13 July 2006 (UTC)
I'd certainly not expect anything to be done automatically. If development versions deteriorate, it should be simple to reset them to the current stable version. I wouldn't have thought the dev version would ever entirely replace a stable version - most likely there would be some changes needing integrating, others that were not good.
I'm not sure I agree with you that any of this would be in conflict with core values. Fundamentally, above all else, we're an encyclopaedia. To guide us in writing the encyclpaedia we have the WP:NOR, WP:V, WP:NPOV policies, and the tool we use to write the encyclopaedia is the wiki. Protecting articles only changes the nature of the tool we're using to write the encyclopaedia, not any of our core values. My fear is that if we never get static versions going in some form, we'll never be perceived as an accurate and reliable encyclopaedia. Worldtraveller 08:42, 13 July 2006 (UTC)
No the development version must replace the stable version in order to preserve history. We cannot edit choice parts of the development version into the stable version. The stable version should never be edited at all. Of course the the development version should be worked on until it is better than the stable version before replacement. I do not think it would be able to deteriorate too badly because as part of this procress people will be watching the changes made to it more than they would otherwise.--Birgitte§β ʈ Talk 13:14, 13 July 2006 (UTC)
So, to consider an example, if there were a typo in a stable version, or a suddenly false fact (say, the subject dies), and someone wanted to make just that minor change to the stable version, they would have to revert the development version to the stable version, delete the stable version of the article, move the development version in, and, what, delete the redirect that would be created and c&p the content over to the development page again? I'm trying to see a way where the history of the development version isn't lost on one page or the other in this scenario. JDoorjam Talk 18:02, 13 July 2006 (UTC)
I think you misunderstand the proposal... As I understand it, if an urgent change needed to be made in a stable version, and it wasn't so minor as a typo (which would be fine to simply edit), then the following would be done:
  1. Copy the stable version's wiki-text into the development version (i.e. revert the development version back to the stable version)
  3. Make the change, and save it (with a edit summary of something like: "Subject died; updating last stable version")
  4. Post a message on the talk page requesting that the stable version be updated with the correction, and get some other editors to agree; presumably, the change should be simple and uncontroversial enough that this should be easy. It will take longer than simply editing, but it should - the point of stable versions is that more than one person has agreed they are correct.
  5. Copy the wiki-text of the corrected version into the stable version page, and use an edit summary that mentions the revision_id of the just made development version.
  6. Revert the development version back to it's previous state (except, correct the fact that the subject died, or whatever needs correcting).
  7. That's all! No history was lost, and the stable version remained simply a set of copies of specific revisions of the development version, as it should be.

Yea I was not referring to WP:NOR WP:V and WP:NPOV which is why I put perceived core values which is the "anyone can edit. Though all in all, I think the trade off is worthwhile, my concern was that the safeguards in place to exclude articles with content disputes (therefor not enshrining one position over another in the stable version) might run in to problems when the devel version is 2 months old has gotten somewhat worse than the stable version then an edit conflict starts. Content disputes happen on lots of articles that have been relatively unchanged for a while. My question/concern is weather this system is meant to protect the article from such disputes which will almost always make them worse, or if it will cause an intimidate destabilization to the (inferior) development version? Dalf | Talk 23:25, 13 July 2006 (UTC)

This is meant to reduce vandalism by eliminating the gratification vandals recieve by seeing their edits on the default page. Not take sides in content disputes. This is how I understand the policy. The stable version should be free of obvious error since consensus is needed to declare it a stable version. The page is moved to the delvelopment position with the agreed on stable version being copied and pasted into the default position. Editing takes place on the development position. When there is marked improvement consensus is gained to replace the stable version with a newer stable version. This is again done with copy and paste. If there is no activity in three months the article now fails the criteria for stablization. Consenus is attained to destablized the article and approve the current development version. The stable version is deleted and the development version is moved back to the default postition. That is how I see it working, please correct me if I am mistaken.The stable version cannot be edited or it will destroy edit history--Birgitte§β ʈ Talk 01:32, 14 July 2006 (UTC)

Why not just destabilize the development version, errors intact, and let the wiki run its course? We're no worse off than we are now; in fact, we successfully delayed the inclusion of bad edits in the main article. --Spangineeres (háblame) 13:40, 14 July 2006 (UTC)

That's how it's supposed to work, but in practice, I'm not so sure. Given a situation with an article has a protected stable version, and there is a content dispute, which including complaints about the stable version, there are two options a) leave stable version protected until edit conflict resolved, or b) replace stable with development version which is in conflict, which may need to be immediately protected to stop edit warring. This proposal says that the latter should happen, but I can see pragmatics chosing the first option regardless. Regards, MartinRe 13:57, 14 July 2006 (UTC)
I suppose after thinking about it, the vandalims issue is the main one and my question was not exceptionally timely since no matter what we think here the community maight do their own thing when they encounter these issues. From that regard I think a limited test is probbly a good idea, but a large enough of a test so that a few of these problems are likely to be encountered. Dalf | Talk 07:51, 15 July 2006 (UTC)

[edit] Straw poll!

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

[edit] 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' [6].--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)

[edit] 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)

[edit] 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)

[edit] 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.
  3. Semi-protection - only logged in users can write, and what they write immediately goes live.
  4. 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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:

Image:AEQ1.gif

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).

Image:AEQ2.gif

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:

Image:AEQ3.gif

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:

Image:AEQ4.gif

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)

[edit] Elephant a stable version?

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

[edit] 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 [7]. 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)

[edit] Then, what about this?

I'll pick five articles at semi-random, none of which will be most vandalized pages, but none will be unedited Rambot articles, either. What's the consensus on doing something like this as a test? Ral315 (talk) 03:40, 2 August 2006 (UTC)

Well, first, that this claims that it is a tool for protecting already-good articles that don't get edited a lot. Not for protecting against vandalism (this is the purpose of the rollback, block and protect buttons, in that order). So Rambot articles would be the right place to start. But why? I don't see the motivation for this. -Splash - tk 03:47, 2 August 2006 (UTC)
I agree with a test of 5 articles each to both verions, Jdoorjam version and the orginal version. Jaranda wat's sup 04:06, 2 August 2006 (UTC)
  • I testing Jdoorjam version with Selena/Stable version, I'm not sure how to work this though :/ Jaranda wat's sup 04:12, 2 August 2006 (UTC)

To get the ball rolling, I've picked five wildly diverse articles: Saudi Arabia, Yahoo!, War of 1812, Calculus, and Jeopardy!. The reasoning behind these five are that they're all reasonably long articles, and all have mild editing (~100 edits since June). If this is successful, perhaps some oft-edited articles might be considered next. Ral315 (talk) 04:35, 2 August 2006 (UTC)

I don't think Jeopardy is actually stable. See http://en.wikipedia.org/w/index.php?title=Jeopardy%21&oldid=67181717 hoopydinkConas tá tú? 04:39, 2 August 2006 (UTC)
That was not the way I wanted to present that diff, so I'll elaborate. I successfully edited the article (I just dropped the infobox down a line), ergo it can't be stable. hoopydinkConas tá tú? 04:43, 2 August 2006 (UTC)
Right, fixed. Ral315 (talk) 04:49, 2 August 2006 (UTC)
  • I prefer to use 5 FAs instead though Jaranda wat's sup 04:37, 2 August 2006 (UTC)
I'd rather not use FA's as they're more likely to be frequently edited hoopydinkConas tá tú? 04:39, 2 August 2006 (UTC)
Acually not really the case, they get normal editing unless it's in the main page, Jeopardy! is not an article in high quality nither so I prefer to try it out in another article. Jaranda wat's sup 04:42, 2 August 2006 (UTC)
It actually is the case if you look at the FA you brought up, Selena, which has been edited 100 times since July 12. hoopydinkConas tá tú? 04:47, 2 August 2006 (UTC)
Well, my intent was that an FA would be reverted at this point, and a variety of articles, both high and low quality, should be tried. Ral315 (talk) 04:49, 2 August 2006 (UTC)
I agree that it's probably a good idea to try to stable versions out on a variety of articles. hoopydinkConas tá tú? 04:56, 2 August 2006 (UTC)
(Apologies for disappearing for two weeks from this discussion.) Except both methods can't be used simultaneously on the same articles. My method makes the dynamic version the default with a prominent link to the stable one. Because it'd be easy to find the version that was made "Featured", I'd recommend running my method with five articles that were very recently made into Featured Articles. JDoorjam Talk 04:43, 2 August 2006 (UTC)
Alright, alright, I'm going to now get off my lazy bum and actually write out my proposal. While I do please god somebody tell me that Dr. Colbert left us alone tonight (It hasn't aired here yet). JDoorjam Talk 04:46, 2 August 2006 (UTC)
He did. Ral315 (talk) 04:49, 2 August 2006 (UTC)

It might have been a wise move to have made some mention of the implementation of a proposed guideline on the talk pages of the articles moved before doing it. The guideline as written even states that the first step is to "Place the {{stablenotice}} template on the talk page and begin a discussion." This did not happen, and I'm all of a sudden seeing Calculus moved to Calculus/development without any prior discussion and no attempt to garner any consensus on the matter. siafu 05:16, 2 August 2006 (UTC)

I'm not sure as to whether that step's necessary as long as we're developing the idea still; regardless, I should have left a talk page message, and I apologize. Ral315 (talk) 05:22, 2 August 2006 (UTC)
Well, it happens to be late at night here in the United States, so I imagine the true reaction is only going to come out in the next 8-12 hours, either in the form of cranky objectors or enthusiastic supporters. However, the surprise nature of it I fear will cause more of the former than the latter simply from knee-jerk. I wasn't trying to elicit an apology, just comment on how this was a misstep for the process. siafu 05:25, 2 August 2006 (UTC)

I've gotten a lot of positive feedback for my proposal on this page but would like to get some "go for it"s (on the talk page for my proposal, perhaps) before picking five to go with on this. JDoorjam Talk 06:17, 2 August 2006 (UTC)

Ral315, I've reversed you. You signally failed to seek consensus for your test for more than a few hours, you signally failed to bother to actually follow the process you are supposedly testing thus making the test null, and you 'stabilised' articles that were being actively edited well inside the last 24 hours. In those cases currently linked from Template:Stablenotice, examining the talk pages shows almost nothing but opposition when the process is followed, and so you cannot claim to just be able to stuff this down everyone's throat because you fancy it.

Furthermore, JDoorjam has offered an alternative that you appear to have ignored entirely in deciding that this experiment was to go ahead - consensus, process, agreement or no.

Do it properly, or don't do it at all. You just discredit the process by wilfully circumventing it and the lack of consensus surrounding it. -Splash - tk 12:23, 2 August 2006 (UTC)

I agree that it was a mistake not to solicit opinions on the talk pages of the articles concerned. However, JDoorjam's proposal seems to be only about featured articles, which are of a very limited number. As I'm still interested in seeing the current proposal tested, I placed a notice on Talk:Calculus to solicit opinions. I hope that the editors that work on that article will be allowed to take the decision on whether to test "Stable versions now". -- Jitse Niesen (talk) 15:18, 2 August 2006 (UTC)
Not really. The active editors of an article don't get to vote themselves an exemption from the m:Foundation issues, nor to decree that people shall not edit their article. The correct way to go about this is, for the umpteenth time, to go and build a workable, accepted proposal somewhere and then test to see if it works. It is wrong on many levels to take a proposal, the talk page for which is littered with objections, ruminations, alternatives, proposals and everything else and say "right then, let's have some of that". You're doing it backwards, in the same way that these so-called 'test' earlier were backwards. Oppose, and object to the implication that only those who edit there should have anything to say. -Splash - tk 16:21, 2 August 2006 (UTC)
Jitse, I think it would be reasonable to expand my proposal to Good articles as well. There are currently 1324 such articles, and that number is growing faster than the number of Featured Articles. It'd still be a limited number, but honestly, if an article isn't good enough to be declared a "Good" article, why are we stabilizing it in the first place? JDoorjam Talk 18:53, 2 August 2006 (UTC)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] Why not just do this the easy way?

We have an easy way to set up stable versions without disrupting anyone or seriously changing the way we operate. Anyone who wants to is, after all, free to set up a stable downstream version of Wikipedia at any time. By setting up such an "official" stable mirror and using the existing Wikipedia as the development server, we could have stable versions without disrupting any of Wikipedia's existing functions. Plainly, permanently protecting pages here at Wikipedia is not the way things are done, but this proposal could be easily implemented in a properly-handled downstream fork. --Aquillion 18:43, 2 August 2006 (UTC)

  • I concur, for well established articles we should have a box with a link to a protected stable version with the dynamic version directly below. It could even be built into the software so that a vandal could not remove the box with a link to the stable version.--God Ω War 02:07, 3 August 2006 (UTC)
    • Up until the software part, this is exactly what I set forth in my proposal, which could be an easy launching point to incorporating just such a software fix. JDoorjam Talk 02:15, 3 August 2006 (UTC)

[edit] Problem with this suggestion as described.

For what my opinion is worth, here's what I see as the most serious problem with this suggestion, at least as it is currently described, plus some possible solutions:

  • It forces admins to use their janitorial abilities to make and enforce content decisions, something that is supposed to be avoided. Even if we ignore the potental problem of admins ignoring the rules and editing the protected page directly, and assume they work through the dev version for all non-trivial edits it still calls for, at the very least, an admin to decide on a version of the page to stabilize, followed by (presumably) repeated admin decisions on when the dev version is approprate to move over. Even if a page has no discussion or disputes when it is stablized, this essentially says that it will be moderated forever and that all further disputes on it will have to be resolved by an uninvolved admin, who will have to judge when discussions have settled down, decide if a version is stable enough to bring over, and perform the actual transfer. I do not think that even the most hard-working and stable admins could do this constantly without occasionally allowing their subjective judgements of a version's quality to influence their decision; who is seriously going introduce a new 'stable' version when they think that it is, on a content level, clearly significently worse than the current one?
  • The primary way to solve this is to have a clear 'Non-Stable Articles' process, and to make it extremely straightforward: If a single editor in good standing (i.e. not a vandal or a completely new account) claims that an article is not stable, it is not, and that status will be revoked immediately upon their request. No justification need be provided for this request; if any editor thinks that an article isn't stable, it isn't.
  • Per the above, a bot runs which checks the number of edits to developement versions; if they receive more than a set number, the article is automatically put in a queue for possible switching back to non-stable status (an admin would still do the actual de-stabilization, checking to ensure that the edits sparking the destabilization are not trivial or vandalism.) This could pose problems with people spamming the page with minor edits to destabilize it, of course, if it weren't for the above; but the fact that any editor can revoke an article's stable status on request would make such a situation unnecessary.
  • Some people might object that no article that would benefit from stabilization will be able to keep it under the above restrictions. This is probably true; but the problem with that is in the original proposal, not my proposed solutions. An article that is genuinely stable would, after all, not need any of these elaborate rules and regulations to keep it so. --Aquillion 20:08, 2 August 2006 (UTC)

[edit] Is this proposal dead?

Does anyone think this still has a significant chance of gaining consensus support? Especially given the myriad other proposals (such as JDoorJam's, which avoids most of the criticisms levelled at this one) on this topic, and the fact that the last contribution was two days ago, I would suggest not. Unless anyone objects, I'll mark it as {{rejected}} tomorrow (to give time for objections to be posted here). Cynical 13:11, 4 August 2006 (UTC)

No, it doesn't appear to be moving forward. It looks like we're going to need a software implementation and/or a command from our benevolent dictator to implement these things. Any time now Jimbo ;-) --Spangineeres (háblame) 13:16, 4 August 2006 (UTC)
I think there will be some semi-structured discussion about how to implement it at Wikimania, and I expect a tighter proposal that a lot of the participants at the conference have roughly agreed to will emerge within a few days. At least that's the impression I get from watching a bit of the live conference feed.--ragesoss 14:20, 4 August 2006 (UTC)

This proposal is definitely dead. I've heard conflicting information, but my understanding is that Brion Vibber has already coded or is in the process of coding or will soon be coding Mediawiki support for stable versions. That would render this proposal moot. Raul654 15:52, 4 August 2006 (UTC)

But the proposal would still need some sort of approval regarding how to implement the code properly, if it's even going to happen at all, no? --badlydrawnjeff talk 16:02, 4 August 2006 (UTC)

I have no objection to marking this proposal as {{rejected}}, although I was (and am) a supporter of it. It clearly has failed to gain consensus. JesseW, the juggling janitor 17:59, 4 August 2006 (UTC)

[edit] Test cases again

Folks are again rolling out test cases over at Wikipedia:Stable_versions. If you have an opinion one way or the other, you should be aware of the discussion. --badlydrawnjeff talk 12:11, 8 August 2006 (UTC)

Retrieved from "http://en.wikipedia.org../../../s/t/a/Wikipedia_talk%7EStable_versions_now_926b.html"