Wikipedia talk:Stable versions now/Illustration

message: 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)
replies: text: I like the idea immensely. It would be quite useful for, for example, a DVD version. [ælfəks] 09:46, 9 July 2006 (UTC)

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

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

text: 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)
replies: text: 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)

text: 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)

text: 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)
replies: text: 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 . --Gmaxwell 22:46, 9 July 2006 (UTC)

text: 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)
replies: text: 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)

text: Agreed, it's been just around the corner forever, we need to move forward. - Taxman Talk 15:23, 11 July 2006 (UTC)
thread_title:  Initial discussion 

message: : "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)
replies: text: 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)
replies: text:  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)
replies: text: 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)
replies: text: 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)
thread_title: "Only articles which are actively edited may become stabilised."

message: 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)
replies: text: 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)
replies: text: 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)

text: 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)

text: 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)
thread_title:  Good idea 

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

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

message: :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)
replies: text: 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)
replies: text: 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)
thread_title: Reduce editing

message: 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)
thread_title: Categories

message: 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)
replies: text: Why is this so imperetive to roll out now? --badlydrawnjeff talk 15:39, 11 July 2006 (UTC)
replies: text: We've been discussing the need for stable versions for a long time, and now someone has a decent idea to implement something that could work immediately.  What better time to test it than the present? --Spangineeres (háblame) 15:43, 11 July 2006 (UTC)
replies: text: 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)

text: I'm not saying "let's implement it permenantly, right now", I'm saying let's test it and see what happens.  It's all speculation until we know what the problems are.  I'm afraid I don't know what you're referring to when you say "stability fliers"—have processes like this been pushed hard in the past and then failed miserably?  I haven't seen any of that.  And what relevant problems do you see with the FA process?  --Spangineeres (háblame) 18:50, 11 July 2006 (UTC)
thread_title: Thoughts

message: read this. Herostratus 13:35, 11 July 2006 (UTC)
thread_title:  Average End Quality Hypothesis 

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

message: It seems there is already a trial of this proposal being begun .  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)
replies: text: Pop icons might be a good place to start because A) we have a number of them at FA and GA status, and B) they are typically edited/vandalized frequently.  Maybe get two groups of around 10 articles, with 2-3 FAs and 2-3 GAs per group.  Then implement this on one group and see what happens.  The problem is that the experiment won't be perfect, since the fact that this is a test run will make these articles get more attention than they otherwise would from people following this discussion. I don't think that "weighting" of vandalism/constuctive edits is necessary; trying to quantify the benefit in a way that everyone agrees upon will be tough. Let's just run the test and let people draw their own conclusions and discuss the result. --Spangineeres (háblame) 16:14, 11 July 2006 (UTC)
replies: text: 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)
thread_title:  Trial run 

message: 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)
replies: text: Re your crucial question, I believe the answer is that ideally, yes, once implemented some sort of stable versions would be in place forever.  Articles would be periodically updated (matched against the "development version"), and wouldn't be destabilized unless something happened that made it impossible for consensus to form over one revision (POV issues, etc.).  And of course, once the software is updated to make this whole process cleaner, we'd use that method and not this one. For your second question, a possible immediate solution would be updating the popups script to include a link to the development version.  Once the software is updated, perhaps an option could be added to preferences that would allow users to select which they want to see by default.  And finally, a page similar to WP:AIV could be created for the type of problems you describe. Anyone would be able to report a problem (like reporting vandals on AIV) and then an admin with the page on his/her watchlist could solve the problem. On AIV vandals are usually dealt with in minutes, and I don't see any reason why the same wouldn't be true here as well. --Spangineeres (háblame) 19:05, 11 July 2006 (UTC)
replies: text: 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)
thread_title:  Questions 

message: 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)
replies: text: That's one of the major problems I see with this.  --badlydrawnjeff talk 18:20, 11 July 2006 (UTC)
thread_title:  This is a KISS proposal; I like it.  

message: 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)
thread_title:  Tie-in with senior editors? 

message: 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)
thread_title:  Why not just use GA/FA status? 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: Sounds good to me. - FrancisTyers · 22:36, 11 July 2006 (UTC)

text: Me too, that seems like a much better proposal. —Keenan Pepper 22:41, 11 July 2006 (UTC)
replies: text: 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)
replies: text: 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)
thread_title: Strongly disagree

message: .... 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)
thread_title:  Btw, there's a technical flaw: