Wikipedia:Stable versions now/Illustration

Initial discussion[edit]

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

I like the idea immensely. It would be quite useful for, for example, a DVD version. [ælfəks] 09:46, 9 July 2006 (UTC)[reply]

Great work Greg! I love it.--Brad Patrick 11:12, 9 July 2006 (UTC)[reply]

I see no reason not to use this. Kelly Martin (talk) 18:59, 9 July 2006 (UTC)[reply]

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

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

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

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

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

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

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

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

Agreed, it's been just around the corner forever, we need to move forward. - Taxman ^Talk 15:23, 11 July 2006 (UTC)[reply]

Comments from the peanut gallery[edit]

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! hoopydink^{Conas tá tú?} 21:04, 9 July 2006 (UTC)[reply]

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

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 hoopydink^{Conas tá tú?} 22:42, 9 July 2006 (UTC)[reply]

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

"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)[reply]

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

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

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

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

Naming format[edit]

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

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

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

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

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

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

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

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

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

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:

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.
Newbies will have a hard time finding the actual talk page of the article, as clicking on "discussion" will not yield the expected results.
Templates like {{POV}} and many others who link to talk pages will link to an empty page.
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)[reply]

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

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.
Sure, we can help them finding it, my point is that we will make it harder for them to find the actual talk page.
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.
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)[reply]

Good idea[edit]

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

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

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

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

Fantastic[edit]

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

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

But whyyyyyyyyyyy?[edit]

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

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

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

Wikipedia Mantra in Jeopardy[edit]

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... joturn e r 19:34, 10 July 2006 (UTC)[reply]

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

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

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)

Premature and unacceptable[edit]

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

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

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

Reduce editing[edit]

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

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

Categories[edit]

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

Bad idea.[edit]

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

And why wouldn't this "quick hack":

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.
Be easy enough to dismantle and/or port to the software solution when need be? —Bunchofgrapes (talk) 03:28, 11 July 2006 (UTC)[reply]

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.

Thoughts[edit]

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.

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.
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.
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.
See also a similar proposal at WP:STATIC. Worldtraveller 09:30, 11 July 2006 (UTC)[reply]

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

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

Why is this so imperetive to roll out now? --badlydrawnjeff talk 15:39, 11 July 2006 (UTC)[reply]

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? --Spangineer^es (háblame) 15:43, 11 July 2006 (UTC)[reply]

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

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? --Spangineer^es (háblame) 18:50, 11 July 2006 (UTC)[reply]

Average End Quality Hypothesis[edit]

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

Where to keep article histories[edit]

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. --Spangineer^es (háblame) 15:38, 11 July 2006 (UTC)[reply]

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

Trial run[edit]

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

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. --Spangineer^es (háblame) 16:14, 11 July 2006 (UTC)[reply]

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

Questions[edit]

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

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. --Spangineer^es (háblame) 19:05, 11 July 2006 (UTC)[reply]

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

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

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

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

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

Tie-in with senior editors?[edit]

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

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

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. JDoorj a m Talk 21:00, 11 July 2006 (UTC)[reply]

Strongly disagree[edit]

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

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

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. JDoorj a m Talk 22:32, 11 July 2006 (UTC)[reply]

Sounds good to me. - FrancisTyers · 22:36, 11 July 2006 (UTC)[reply]

Me too, that seems like a much better proposal. —Keenan Pepper 22:41, 11 July 2006 (UTC)[reply]

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

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. JDoorj a m Talk 22:55, 11 July 2006 (UTC)[reply]

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

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. JDoorj a m Talk 22:29, 11 July 2006 (UTC)[reply]

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

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? JDoorj a m Talk 00:42, 12 July 2006 (UTC)[reply]

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

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? JDoorj a m Talk 01:16, 12 July 2006 (UTC)[reply]

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

.... 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. JDoorj a m Talk 01:34, 12 July 2006 (UTC)[reply]

I love this idea...[edit]

For featured articles only. I think all FAs should have stable versions at the point of their promotion by Raul (or, for old FAs, a determined point). This will ensure that the prose isn't degraded, and it especially ensures that fancruft isn't added into fictional FAs. — Deckill e r 05:50, 2 August 2006 (UTC)[reply]

Development page