Wikipedia talk:Stable versions now/Archive 1

Archive 1

Archive 2

Archive 3

Archive 4

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

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)

Average End Quality Hypothesis

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

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)

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)

Trial run

It seems there is already a trial of this proposal being begun [1]. 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. --Spangineer^es (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)

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)

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)

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)

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— Preceding unsigned comment 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)

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)

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. --Spangineer^es (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. --Spangineer^es (háblame) 13:00, 12 July 2006 (UTC)

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)

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. --Spangineer^es (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. --Spangineer^es (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. --Spangineer^es (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)

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)

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)

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)

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)

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)

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

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)

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)
2. Make the change, and save it (with a edit summary of something like: "Subject died; updating last stable version")
3. 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.
4. 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.
5. Revert the development version back to it's previous state (except, correct the fact that the subject died, or whatever needs correcting).
6. 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. --Spangineer^es (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)