Misplaced Pages

Revision as of 21:31, 11 March 2009

Archives

Archive 1

Disadvantages of new DA

I did some cleanup on the section about the demo system for the new DA, and completely removed these two points that were listed under "disadvantages":

• Some objectors feel that the lack of formal user survey and specifications is a critical problem in the development of any software—particularly complicated software.
• Several objectors to the use of a bot to remove the current autoformatting have complained that a bot cannot distinguish between dates linked purely for autoformatting and dates linked intentionally. But the proposed new autoformatting method would abolish all such links, intentional or otherwise, the moment it was introduced.

The first point has nothing at all to do with the new system, and is just a point about software development in general (and one that is almost universally rejected by modern software engineering theory, particularly in XP/Agile/Lean/etc.) Nobody follows the Waterfall model of software development anymore, and for good reason — it doesn't work. It's not possible to develop a full, complete specification before starting development, and it's a waste of time to even try. You develop enough of a specification that you can get started with developing a working system, and then iteratively improve the system based on feedback and testing.

The second point doesn't make any sense. It's not the links that help bots (or other automated tools) but the markup around dates. The markup would still be there in the new system, and so whether that markup results in a link or not is irrelevant to the bot. --UC_Bill (talk) 00:07, 7 March 2009 (UTC)

I just realized that the second point wasn't actually about bots at all. It was comparing one argument (about bots) and trying to adapt it to the new system. In any event, it still doesn't apply, because the new DA system would allow date linking. It's only the default (for anons) that has been proposed as being "don't link dates" but the new DA system itself could support any default that the consensus wanted. In other words, arguments about what the default for anons should be don't translate into "disadvantages" of the system. --UC_Bill (talk) 00:58, 7 March 2009 (UTC)

The point I was trying to make was that several participants in this dispute who favour date linking, and have objected to automated removal of autoformatting markup because it would also remove links they consider important, may not appreciate that the proposed replacement autoformatting system would instantly eliminate all those links. For them, that would be a strong reason to oppose the new system. Colonies Chris (talk) 16:12, 9 March 2009 (UTC)

Under UC Bills system they could enable date links in Special:Preferences, overriding the linkless system present to anonymous users. —Locke Cole • t • c 16:16, 9 March 2009 (UTC)

So the choice would be either to see all marked-up dates autoformatted but not linked, or to see every autoformatted date also linked, as at present? Scarcely anyone has suggested that every one (or even very many) of the present unintended links generated by the autoformatting syntax are worth keeping. So editors who favour linking would have to switch off the linking preference in order to see which autoformatted dates they think should be linked but aren't, then go in and manually mark them up as linked as well as autoformatted. How is that any different from relinking after a bot has been through, or wrapping them in a special template to indicate why they shouldn't be unlinked by a bot? Colonies Chris (talk) 17:21, 9 March 2009 (UTC)

Editors who favor linking don't necessarily have a strong opinion on how everyone else should see things, so this might be a total non-issue. I want to see every single date in Misplaced Pages linked (even "duplicates" within an article) but I would never contemplate forcing that preference on everybody else. If I did want to check which dates were linked for anons, I wouldn't find it much of a bother to just temporarily disable my preference settings.. or click "edit" and just look for myself, since it's all quite evident in the wikitext itself. --UC_Bill (talk) 17:32, 9 March 2009 (UTC)

• If it was anyone on 'my side' who offered that sort of arguments, there would already be howls of conflict of interest. As it stands, I would be inclined to call Katz's last revert 'bullying' or "blinding with science". Ohconfucius (talk) 12:07, 8 March 2009 (UTC)

What conflict of interest? I hold no special position of authority here. I'm not even technically party to this ArbCom case, since I've mostly been contributing code rather than participating in the arguments on MOSNUM, or performing any date-related edits.

My point anyway was that arguments against a specific setting in a DA system that lets you specify any number of settings isn't an argument against the DA system. The only reason we've been talking about anons seeing dates unlinked is because that seemed to be what the majority wanted. If some other setting is better, then we should go with that.

You could still argue that it's a flaw of the DA system itself that it only allows one site-wide default for anons... but that's a flaw of doing it with manual edits ("plain text") too, so I don't see how it's worth mentioning twice if the same "flaw" applies to any of our current options. I suppose we could explain the reasons for this in its own section (the squid cache that the WP site uses means one default for every anon, unless we go for a javascript-based client-side solution) and leave it at that? --UC_Bill (talk) 18:29, 8 March 2009 (UTC)

If we invest extra computer processing and extra markup, we expect a return on investment. If the vast majority of readers see the same thing that could have been seen just by entering the text in the format appropriate for the article to begin with, one can argue there is insufficient return on investment. A separate argument would be whether correct display could be more efficiently achieved through reformatting software and markup, or correction of unmarked dates. --Gerry Ashton (talk) 18:38, 8 March 2009 (UTC)

Those are some really good points, Gerry. In the first case, the "investment" amounts to putting some kind of markup (] or {{date|xxx}} or whatever) around dates, which is more effort and can discourage novice editors. However, the benefits go beyond just letting registered users set a personal preference: date-specific metadata within articles will allow for the (eventual) development of a lot of useful new features like automated timelines (like the automated TOC but for dates), the ability to automatically create "this day in history" pages (like categories but containing links to all articles that mention that date, possibly with some relevant context like the sentence containing the date) and so forth. It would also allow for easier processing of wikipedia database dumps, looking for possible sources of new connections between articles... not to mention the reason you bring up yourself, that it makes it easier to enforce the site-wide standards. If for some reason the entire world decides to use "2009 July 15" format (or at least the majority of readers of wikipedia do) then it's easier to make a one-line change in the site's configuration file, than to edit hundreds of thousands of articles. With the "magic word" support in the new system that allows per-page defaults, it's easier to tag a page as being DMY or MDY or whatever and have all the dates automatically format themselves, than to do it manually for each date. We could even have it reformat dates when new revisions are saved, to keep the raw text itself consistent (similar to what happens when you "substitute" a template.) I think the benefits far outweigh the negatives, but I'm certainly willing to leaving it open to debate and determination via RFC. --UC_Bill (talk) 19:08, 8 March 2009 (UTC)

The metadata this would provide is of such low quality as to be worthless. All you could discover is that something related in some unknown way to the subject of the article happened on that date. That's not remotely worth the investment of marking up all dates. Much better metadata is already provided by existing categories such as ] or ]. Colonies Chris (talk) 11:41, 9 March 2009 (UTC)

I've done a significant refactoring of the section, and left everything in except this item:

• All autoformatting techniques provide a default format for I.P. users and a special, custom format that only can be seen by A) registered editors who, B) have set their user preferences.

I don't see what the actual objection is, so please clarify that point before adding it back. --UC_Bill (talk) 21:35, 8 March 2009 (UTC)

Concern with overly binary wording

I think the RfC wording proposed by Ryan here at Draft RfC, which basically asks “I support/oppose the concept of month-day markup'” is far too binary. The community has already spoken in the previous RfCs that it is nuanced issue (date linking should rarely be used) and can not be addressed with such a binary question. See my posted concern here on Ryan’s talk page. Greg L (talk) 20:16, 7 March 2009 (UTC)

Disadvantages of the proposed default date formatting system

With this edit user Ckatz has removed a disadvantage that I created (and Tony1 refined). Based on my stated adherence to the zero-revert rule, I won't simply do to Ckatz what he has just done to us. Instead, I've created this section for a little discussion. Needless to say, I believe the points I originally raised to be important, and reject the implications raised in Ckatz's un-edit comment: "rm. - the supposed importance of this "concern" is disproportionate to reality, and does nothing but make the RfC more convoluted". I would like the wording the above edit removed to be re-established so that others can decide its merits.  HWV258  06:18, 9 March 2009 (UTC)

The importance of standards and a road map are, I believe, overstated, and seem like an attempt to scare people away from supporting it. The simple fact is, UC Bill has a largely complete update to Dynamic Dates available which addresses fully 90% of the concerns of everyone involved (in fact, it makes the issue of when to link dates (years or month/day) largely moot except for anonymous editors; it really is a big win for everyone IMO). The only remaining issue of major importance is the ability of anonymous users to select their preferred format. That will require Javascript of some sort, but is by no means impossible to pull off. —Locke Cole • t • c 06:20, 9 March 2009 (UTC)

I am yet to be convinced of these claims. I'm putting back the "Disadvantage" until it's resolved; I doubt that it will be before 15 March, the planned started of this RfC. Tony (talk) 07:41, 9 March 2009 (UTC)

There's nothing to resolve here Tony: you simply have no idea what you're talking about and are entirely out of your element. —Locke Cole • t • c 07:53, 9 March 2009 (UTC)

That counts as a personal attack. Keep personal insults out of the discussion, please, as required by policy. Now, you are trying to censor mention of a matter that is rather inconvenient for your case. I suggest that you discuss the matter here rather than practising this censorship strategy. Tony (talk) 10:05, 9 March 2009 (UTC)

I thought that the RfC was for DA in general, not a specific proposed system. The spec is still open to contributions by any editor that has concerns. Rather than encouraging amendments to the spec, the listed disadvantage seems to imply that the system is immutable and that the spec and test cases are wholly complete. Lightmouse's edit is more concise and focused on the general DA concept. —Ost (talk) 13:06, 9 March 2009 (UTC)

The problem with developing before the community has decided what should be developed, is that we risk being locked into a particular way of thinking. We are still trying to determine what should be addressed (some sort of functional requirements—hence this page), so how the percentage of 90% was arrived at is worrying. Sorry to say it but (in terms of "entirely out of your element") the comment "The importance of standards and a road map are, I believe, overstated" is just painful to read for someone who has made a career out of software development. Still not convinced? Well, here is an example closer to home: an example of the results of poorly specified development is right under our noses—the current date linking/formatting system.  HWV258  21:28, 9 March 2009 (UTC)

I perceive a desire on the part of some to implement a new date autoformatting system incrementally. The dangers I see in approving a proposal to reach some distant goal incrementally are:

1. There is no minimum threshold of improvement to allow implementation. Approval of a new system should specify certain minimum requirements, and failure to meet the minimum requirements should preclude implementation.
2. Failure to envision the ultimate function may mean that millions of dates are marked up in a way that fails to contain enough information to achieve the ultimate function. --Gerry Ashton (talk) 21:38, 9 March 2009 (UTC)

Nobody (that I know of) is proposing incremental implementation of the system, and honestly I'm not even sure what that would look like. Some (including me) have been discussing incremental (or iterative) development of the system, but that's different. All that means is that we start off with a basic working demo system (already done) and then improve it in stages, based on feedback and testing. Once it's deemed ready (i.e. all the required features have been identified and implemented, ample documentation and specification produced, etc.) then it would be submitted to the Bugzilla site for testing by other developers (and the Misplaced Pages systems administrators, who are the ones that control the servers — and thus software — on which Misplaced Pages runs) and then — and only then — put into production. The only "incremental" (or "iterative" or "agile" or "lean") part about it is that the specification (and other artifacts) are produced in parallel and in stages alongside the code development itself, rather than as an up-front step to be completed before development begins. --UC_Bill (talk) 21:54, 9 March 2009 (UTC)

Okay—thanks for that. It needed to be explicitly stated that nothing will be implemented to the wider WP community until "it's deemed ready". In terms of the incremental specification-development methodology, see my recent post on this page for a concern. As a specific example of that concern, I notice the demo page promotes the use of square brackets. I'm not convinced that the community believes that to be the best solution to the problem (based on the over-loading assumptions of the current WP linking system).  HWV258  22:23, 9 March 2009 (UTC)

HWV258, I'll reply to your above point here. You wrote: "The problem with developing before the community has decided what should be developed, is that we risk being locked into a particular way of thinking." I'd say that the problem with developing a specification before development work begins is that we risk encountering aspects of the system that can only be discovered during development (i.e. technical feasibility issues) and which end up requiring major revisions to the specification. That's why you do both in parallel. Both the code base and the specification (and other documents) should evolve in response to changing expectations and user feedback. Often, people don't know what they want until they've seen it (or something like it) and that's why it's a good idea to start work on a demo/test system right away. The type of design rigidity you describe is indeed a problem, but it's one that stems from having a process that's too rigid, not from the order in which the steps are begun.

Anyway, I'm happy to discuss Agile development with you until the proverbial cows come home, but it should probably be done in a different forum, since it doesn't really have much direct bearing on the issue at hand. --UC_Bill (talk) 22:53, 9 March 2009 (UTC)

I used to think the same way (as it definitely is more fun for programmers to have a freer hand). However, more experience has convinced me that (at least) functional requirements are essential for a successful development. The point about "technical feasibility issues" is understood, however that is never a reason for hindering the "wish list" aspect of a functional specification. At worst, issues with technical feasibility are grounds for a rethink during a development, but not for a pre-emptive development activity. However, I don't anticipate such technical issues here, and have supreme confidence that you (and others) can solve the issues required for the development of an effective date formatting/linking system. Beyond a shadow of a doubt, the vast majority of the complexity in this project is to do with understanding what needs to be programmed. I will take issue with your statement "Often, people don't know what they want until they've seen it"—as in this case we have unlimited time, and some very fine minds willing to work co-operatively in the ceaseless search for a solution before development. Of course, if you notice something that you believe will be difficult to program, please let us know so that we can address your concerns. In terms of an Agile Development discussion, I won't thanks; except to point towards the well-known criticisms, and to point out that that list contains some hauntingly familiar points.  HWV258  23:34, 9 March 2009 (UTC)

Son of autoformatting as yet is an imagined experiment

This statement was prepared by Tony1 with input by several others, including HWV258 (a corporate IT specialist) and Lightmouse.

In making these comments, we have placed to one side the triviality of the differences in display that are sought to be addressed (whether month or day comes first or second).

We are surprised that exactly what question would be put to the community about this proposed technology in this RfC has not yet been revealed.

Summary

• The proposal is at a very initial stage, with a host of significant technical and administrative problems that can already be foreseen, let alone those that have not yet arisen. Yet it is presented as a fait accompli, without acknowledgement of the technical and administrative hurdles that lie ahead.
• Asking WPians to commit to or even to formally comment on a complex excursion yet to be defined by clear, detailed specifications or disciplined by exposure to comment on structure and coding would amount to asking the community to surrender control over the nature, quality and reliability of the program and its functional output. Without these, we are being asked to buy a pig in a poke; we got a really ugly specimen in 2003 that has taken years to dispose of.

Lack of transparency; no demonstrations

The key questions are:

1. where is the coding?
2. where is the actual "demo"?
3. why isn't it written within Misplaced Pages?

The "demo" page for this technology has been expanded, but it still only approaches a summary of what would normally be regarded as a list of specifications against which outputs can be tested. When we see references to a "demo" page, we expect to (1) see demonstrated how the coding will work in both edit and display modes; and (2) be able to key in examples to satisfy ourselves that the extremely complicated coding really does exist and does work (more on that below). What we find, however, is just a wish-list of promised functions, without critical details. We await evidence, because bitter experience has taught us to be cautious about the whole business of programming. Once control (i.e., oversight) of the programming is taken away from the community and put entirely into the hands of a programmer or team of programmers, things almost always go wrong. Programmers can and do make critical decisions without reference to clients (analogous, here, to the WP community); it happens all the time, and this is why programs often end up badly. Who, for example, made the dumb decision to piggyback the old date-autoformatting system onto the wikilinking system? Was the community properly consulted on such a critical move? No, people just accepted it as though handed down from Moses. The principle is that before even thinking of accepting or rejecting this proposal, the community needs access to every aspect of the technology as it is developed, and to be satisfied with the outcomes through demonstrable testing.

Wish-list incomplete and faulty

1. Regular dates: The idea is clear enough, but there is no functioning demonstration of the many lines of code that would be required (see "Complexity" below) so that we can test whether it works in all conceivable situations.
2. Date ranges: The first two produce hyphens rather than the required en dashes, even though en dashes are input. The second two ("multiple months") produce an unspaced en dash, since both units ("18 January" and "19 February" both have internal spaces). This is wrong according to best practice, and is a distinction that has been required by WP:MOSDASH for some time. Even where one of the two units has an internal space ("New York – Chicago flight"), a spaced dash is required (cf. "Washington–Chicago" flight). The system will need to translate (i) a spaced en dash, (ii) an unspaced en dash, (iii) a spaced hyphen, and (iv) an unspaced hyphen, into a spaced en dash, since some people get it wrong (just as they got the syntax for the old date autoformatting wrong some of the time). The same permutations will be required of the first two examples (i.e., translating a wrongly spaced hyphen, a correctly spaced hyphen, and a wrongly spaced dash, into an unspaced dash). The alternative is to shift the responsibility onto users to select the dash and whether spaced or not; but would the system function correctly to do this? If so, we need to see a demonstration of this, as well as to see properly formatted examples, to start with.
3. Per-page defaults—Odd name; I'm unsure quite what it means. There is no functioning example.
4. Commas: Um ... which commas? The ones internal to US-style dates, or the pesky ones that some people put after them by default, rather than according to the underlying grammar of the clause?
5. Autoformatting without linking: But the example does link: it's blue, and you hit "2008" and it takes you to this page, which is about as relevant to the price of fish as most year-page links are. Forgive my confusion: the previous examples is a link, and where it says how not to link, it does link. Huh?
6. Linking without autoformatting—the example is just as can be done now, but why you'd want to jam together a link to "18 January" and "2008" is hard to fathom; it seems either to confuse DA with the linking of date-fragments or to pre-empt another RfC issue.
7. There is no reference to slashed dates ("the bombing raid of the night of 21/22 September"), the Gregorian/Julian calendar problem, or the non-breaking spaces that the old system lacked.

Complexity of the task

The proponents of this technology do not appear to be realistic about how large and complex the task is. User:HWV258 tried to convey this by posting a very initial table to get things going. Its mere eight columns belie the complex web of forked combinations of possibilities that would have to be catered for in the coding, all of which would need to be tested in a variety of contexts. However, the structure of the program remains a mystery. Just to provide an example, say, for a so-called regular date, "December 31, 2009", presuming that both elements have been correctly spelled out, ordered and syntaxed:

• Page default is either "dmy" or "mdy" (2 options)
• User logged in or not (2 more options)
• Another 5 options if "yes"; another one option if "no".

Now that looks as though it could be 24 options (2 × 2 × 6). Then there's the no-comma option and the Euro-style (another 24 each)—72 in all. (Our experience in date auditing indicates that a sizeable proportion of items are not perfectly input, which would complicate matters further.)

Bots required?

Dates will require either a slow manual job to make millions of examples comply with the new syntax, or the running of bots to achieve this. We don't doubt that bots can identify plain dates, but date ranges and slashed dates may be more challenging. Lightmouse spent many months refining his own bot and script to unlink syntax, with false positives a major issue (eventually worked through, but only after feedback, sensitive responses to complainants, and dedicated tweaking of the codes). Bots would need to gain permission in the usual way; this is not an easy task.

Administrative hurdles

1. The double-square brackets are the basic syntax for wikilinking on all of WikiMedia's hundreds of sites. How is this new system going to use the same syntax for a completely different function?
2. If a different syntax is to be chosen (I've seen double curly brackets bandied about), how difficult will it be to get WikiMedia to agree to this syntax (provided no one else has reserved it on any one of the many many WikiMedia sites, a major issue for the failed attempt at a simplified syntax for non-breaking spaces.)
3. Will all of our MilHist editors and many casual visitors who write on battles—to take just one example—have to be tutored in the syntax? Date ranges are critical to battles. What will happen to raw dates that are added by users/visitors who are unaware of this system? Will they display differently to the "default" format of the tag at the top of an article (or the dates settings, in the case of logged-in, preferenced Wikipedians)?
4. Will there be false positives—i.e., syntaxes that render correctly for logged-in, preferenced Wikipedians, but are inadvertently wrong for the 99.9% of others? Please do not doubt the capacity of such a system to produce unintended results.
5. How will the system render other date formats, particularly ISO ("2001-08-09")?
6. How will it cater for WPs who choose a setting that is not one of the two standard ones. There are "2001 January 15" and "2001-01-15" among the five possible settings.

Conclusory remarks

There is a distinct tendency to present this proposed new technology as a fait accompli. It's much easier from a programmer's POV for the community to collapse into what has already been constructed than struggling to program what the community wants. We cannot imagine that it is fair to the community to seek an endorsement or rejection of the code at this early stage, particularly as an endorsement would entail the community's loss of control over the pathway towards implementation and whatever interim product might emerge in a reasonable timeframe.

We also contend that the other two issues are quite sufficient for WPs to digest and provide considered judgements on in a single RfC. This must wait until the issues raised above have been addressed—specifically, openness of coding, and testing against specifications. The community is right to be cautious about experiments, and to ask it to commit to this one might be to exploit the lack of technical understanding (and the time to absorb such a complex issue) of all of us non-experts on WP. It is unrealistic. Tony (talk) 14:59, 9 March 2009 (UTC)

Comments

The community shouldn't be voting or commenting on a specific implementation, but rather whether a fixed system is something they want at all. This seems to be something you're avoiding: I suspect because it would give you less angles of unreasonable attack. The RFC should discuss this in purely non-technical terms, otherwise we risk gaining oppose !votes simply because people don't understand it. Basically, "complexity" and "lack of design" are total non-starters, and I will take a dim view of any RFC incorporating such obviously biased (and purely clueless) language. —Locke Cole • t • c 15:09, 9 March 2009 (UTC)

A dim view? Perish the thought. This topic is unsuitable for community input until its claims are clear and verifiable. Tony (talk) 15:35, 9 March 2009 (UTC)

I don't even know what to say to this, it's so bizarre. So I choose to say nothing and hope that Ryan will see past this stonewalling. —Locke Cole • t • c 16:00, 9 March 2009 (UTC)

• Jeez. We’re discussing things in too many places for one bag of neurons to keep track of it all. Locke, you wrote here on Call for participation of how we apparently shouldn’t be having an RfC on UC Bill’s idea and you stated that what we *ought* to have is Consistent date output for anonymous users, including the ability for anonymous users to choose their own date format..

  Great! I’ve been asking for such features for a long time. But such a feature isn’t in the offing anytime soon. It is just another “we oughta do this ’cause it’s keen”-idea. Spiffy ideas are a dime a dozen; it’s the hard work by a team of developers that makes things happen. If some team of developers comes up with dates preferences settings for anon users, then we can go nuts with all sorts of settings in preferences, such as a pref setting for Dialect of “British” or “American” so that code like He put the bomb in the {{dialect|boot|trunk}} of the car would produce He put the bomb in the trunk of the car for some users and He put the bomb in the trunk of the car for others. In the end, preferences settings that benefit everyone—just as what I have just proposed regarding dialect—is all fanciful desires.

  If you are suggesting that we stop wasting our time then and drop Autoformatting off the table as an RfC topic, I want to see UC Bill weigh in here and agree to stop pushing for his current autoformatting. If he doesn’t do so, then there is every reason why the community should have a say in whether they like what he is selling. Greg L (talk) 16:02, 9 March 2009 (UTC)

• No, I don't propose dropping the question, I propose putting it to the community in a generalized manner to ensure there is support for it. After all, why bother working on something if the community will shoot it down? Again, per my comment at Call for participation, the community should be aware of the incremental nature of MediaWiki development (MediaWiki did not spring in to existence one day, feature complete, it's taken years of development and improvement over time), and that will likely be the case with Dynamic Dates (at least reaching the last mile– allowing anonymous users to select a date format preference; the rest has proven to be remarkably simple to implement). —Locke Cole • t • c 16:08, 9 March 2009 (UTC)

• Absolutely unacceptable. This would have the effect of putting up an RfC to the community of “Should developers make all sorts of cool things in the future that have all sorts of features not currently being offered?” We don’t ever have RfCs on questions like that because the answer is obvious. I’m not going to allow a half-baked autoformatting tool like UC Bill’s be thrust upon the community by hiding it behind the apron strings of an RfC that asks whether the community wants free gold raining from the sky and all things good and holy. Either UC Bill takes his proposal off the table and drops it, or the community votes on UC Bill’s proposal in this ArbCom-sponsored RfC. Greg L (talk) 16:16, 9 March 2009 (UTC)

An excellent, and well-written summary of the current situation. I see this summary as a great milestone toward the solution of the date linking/formatting problem. I will add:

• Things don't have to be solved for tomorrow; and we should take the time to specify what we need to accomplish. We are not deciding this just for ourselves—we are deciding it for the WP generations to follow. Let's get it right this time.
• Incremental development on this topic is unacceptable. The number of pages and users affected by a staged implementation mean that gradual changes risk being confusing (if not downright upsetting) to the larger WP community. Incremental development is one way of achieving an end (but contains many disadvantages in this case); carefully planned specifications followed by the usual coding, testing and implementation phases are another way of achieving the same end (but with less issues along the way). This "project" is perhaps unique (certainly when compared with software development projects in industry) in that there is no real deadline. That may appear frustrating at first, but in actual fact is an asset of which we should take advantage.
• In my experience, developers don't enjoy being the meat in the sandwich. I won't pretend to speak for UC_Bill, but I would be surprised if he wouldn't prefer to be presented with a well thought-out specification (instead of risk ending up being the punching bag for decisions he and others will be forced to make at the time of coding).

So, I appeal to everyone to put aside the past, to roll up their sleeves, and work together towards the next step in finding a solution. Thanks.
 HWV258  22:11, 9 March 2009 (UTC)

Locke (referring to the first statement in this thread) if the community is going to indicate support for some form of responsive DA, it seems to me essential that they have an actual proposal to evaluate. Just asking if the community thinks that there should be a better way of handling dates is like asking the community if the devs should finish MediaWiki. UC_Bill is working on an "actual" method to do this. Seems to me the best course would be for everyone involved to pile on the special cases and see if he can work out a bulletproof solution. Software solutions always come down to whether it can actually be done, and there's only ever one way to prove it - do it After all, our dollar expenditures to-date are zero and we've got a willing donkey. And to mix the animal metaphors, it may be difficult to get people to buy a pig-in-a-poke. :) Franamax (talk) 22:51, 9 March 2009 (UTC)

The problem with pointing to UC Bills work and asking the community to vote it up/down is that it may not be the one which is ultimately implemented. Remember, Wernda made a comment to MOSNUM only a month or so ago indicating he was working on another method of date formatting/linking, with different goals and ideas in mind. If the community votes for UC Bills proposal, but gets Werdnas (or, to throw another possibility out there, a fixed version of Tim Starlings Dynamic Dates which is in use now), then those opposed to this would say "but the community only supported X, not Y or Z". I want a general question so we can gauge interest without devolving the discussion down to "but Z doesn't support A or B". Instead I think it would be more helpful to come up with a wishlist of sorts (with reasonable goals, perhaps even allowing for incremental development (specifically, not everything will be implemented at the same time)) and allow the community to indicate support or opposition to that. In this way the various devs all working on this individually would have a reasonable target to shoot for. I view a vote on UC Bills specific version (to take an example you use Franamax) as being akin to asking the community if they supported using the very first revision of MediaWiki (which likely had many bugs and wasn't feature complete compared to what we have now). —Locke Cole • t • c 23:42, 9 March 2009 (UTC)

No, get a system running and tested and demonstrable first: then ask for the community's opinion. It is totally counterproductive to go swinging a wish-list in front of people, asking what they think. That is an invitation to surrender control by the community to the programming side ("you said you wanted it"). No. Tony (talk) 02:42, 10 March 2009 (UTC)

OK LC, I think I see where you're coming from on variant approaches to the software. I still think it comes down to which team actually delivers the good solution - 'cause we can all discuss vapourware forever. !Voting on hypothetical solutions - well, yeah we can do that all day month and year(s). That's actually persuasive to delaying delinking, which of course will be anathema to many - hence my search for plausible and active solutions in software that we could use. But one or other of them mules had best haul the load. A lot of the rational opposition to this is uncertainty about whether all the weird date notations will be handled. Changing MW is a much bigger deal than any bot or script, so it needs to be both feasible and practical.

And Tony, think again about "surrendering" control to the devs. You (as in "you the community") have no control as it is. Commits happen in a process where people might hear your voice but they have no need at all to obey it. Software is software, the way people use software is not a concern of a developer, and can't even be foreseen. If you search around, you'll find a proposal I made for an alternate magicword to turn off all DA - specifically to escape the software. Franamax (talk) 04:00, 10 March 2009 (UTC)

At WP:MOSNUM/RFC there was majority support for some form of auto formatting. Part of the problem with that, I think, was that it was vague and didn't describe how it would work or what would be fixed. If we generalize it, we can 1) get an idea of what requirements the community feels are needed for a fixed/new system, and 2) don't tie ourselves down to one specific implementation (which is still being developed as we speak). MediaWiki development has always been incremental, features being developed and expanded over time, but if the community approves of a specific target the devs will have a road map to work from as far as feature requests and bug fixes. That's not "voting on vaporware", it's providing a clear message of what is expected by the community. —Locke Cole • t • c 04:21, 10 March 2009 (UTC)

Ah, you're referring to the cooked one, are you? The one where two extremes were put as book-ends? I'm surprised you're still drumming on about this one as though it represents a reliable finding. It most certainly does not.Tony (talk) 04:23, 10 March 2009 (UTC)

Key questions on new date management system

Where is the coding?

All code currently resides on the demo server at dates.xoom.org and will be submitted as a "unified diff" patch to the Wikimedia Bugzilla site as soon as it is completed. An explanation of most of the code changes is currently available on the demo site. A link to download a full copy of the code is at http://xoom.org/demo.tgz.

Where is the actual "demo"?

The demo site at dates.xoom.org contains a fully working (albeit incomplete) version of the code. Curious Wikipedians should feel free to either create an account on the demo site (with the standard warnings regarding privacy) or to edit on that site anonymously, to test out the features. Curious software developers who wish to test out the code themselves (or contribute to its development) should feel free to download a copy of the software from the demo site: http://xoom.org/demo.tgz

Why isn't it written within Misplaced Pages?

Since the new date management system involves changes to the software codebase of the Mediawiki software, there is no way to test the new system within Misplaced Pages itself. However, the documentation can (and will) be migrated to Misplaced Pages, should the new system be adopted. Everything on the demo site is Public Domain and can be freely copied to Misplaced Pages by anyone that wishes to do so — however it should be noted that many of the examples on the new system will not work the same way on Misplaced Pages as they do on the demo site, because of the differences in the software.

Comments

• Comment So? Maybe its as spiffy as the steam engine that started the industrial revolution. Developers don’t get their work product rammed through the Misplaced Pages process though ArbCom-sponsored RfCs; they work within the developer community and suffer SPAM-level Wikitech-1 e-mails for months until there is a consensus within the developer community to make it available. The process works (mostly) and has safeguards to ensure code is bug free. Perhaps there are yet other ways to promote what you’ve got. But this ArbCom ain’t it. Are you willing to take the tool that is under discussion here on Ryan’s talk page off the table as a proposed tool for use on Misplaced Pages? Greg L (talk) 16:50, 9 March 2009 (UTC)

Greg, the developer vetting process is nothing compared to the process we're undergoing right now to get the community to agree on what they want. These code changes are fairly simple and are really just modifications to the existing code, and should be simple to test if and when we reach that point. Don't worry about that for now, just focus on the features that the system should have. Note that when I write "the system" I mean "whatever system eventually replaces the existing DA system" and not "this particular bunch of code that I have written." In that regard, I don't think the RFC should refer to any specific version, except to point out that one is under active development (if even then.) So no, I'm not going to take my work "off the table" but you should feel free to remove all references to it from the RFC, and have the RFC simply discuss "possible future systems" or something along those lines. I'd prefer that really, since I don't much care for this focus on me that's currently in the debate. --UC_Bill (talk) 17:04, 9 March 2009 (UTC)

• OK, you’ve all got me galactically confused. This started out with your proposed tools, which are the sort of stuff any ol’ template author could make and doesn’t require a behind-the-scenes developer (and full cooperation within the developer community). Those tools, as described here on Ryan’s talk page, would have required extra markup on dates that allowed a special and separate view of date formats only for registered editors. That proposal got all wrapped around the axle of date linking and bot removal of same; ergo, this ArbCom.

  Now we see Locke backing away from it, since he wrote above as follows: After all, why bother working on something if the community will shoot it down?. Now you just wrote I'm not going to take my work "off the table" but you should feel free to remove all references to it from the RFC. “Remove all references to it ” isn’t good enough. We are mired here, in part, because of a drum beat of promotion of your tool. And now there is a tacit admission from Locke that he recognizes that if put to an ArbCom-sponsored RfC to the community, it would go down in flames. However, if we don’t hold a community-wide RfC to consider your tool, and just “drop” the issue entirely from this ArbCom, there is nothing to prevent your camp (e.g. Locke) from vociferously promoting its use—or even starting to use it in articles; the past RfCs make it exceedingly clear the community doesn’t want it. We would be solving nothing.

  So, if everyone from your camp is no longer willing to stand behind this tool and write the Statement for, in an RfC, then I will call for a declaratory ruling out of this ArbCom enjoining, for a period of one year, you and all other parties to this ArbCom from promoting the adoption of that particular tool on Misplaced Pages.

  As for whatever other new & improved tools and code and ideas you have, that is totally beyond the scope and jurisdiction of this ArbCom. There are other, proper venues on Misplaced Pages for you to pitch what you’ve got; this isn’t one of them. If you feel that what you have can only be handled with some sort of RfC, then I suggest you start at Misplaced Pages:RFC#Instructions and Misplaced Pages:Requests for comment/All. Greg L (talk) 18:04, 9 March 2009 (UTC)

Greg, since you obviously have no idea how the software development process works, please just stay out of that part of the discussion. If you have suggestions for features or want to help with testing, by all means do so. Otherwise, shut up. --UC_Bill (talk) 18:15, 9 March 2009 (UTC)

• No offense taken. If you are somehow under the impression that the standard practice for software developers is to 1) offer up an idea no one wants, 2) go to an RfC where the idea gets shot down, 3) keep pushing the idea until there is an ArbCom on the matter, and 4) sorta back pedal on what you were promoting and try to get some new idea of yours to be the subject of the ArbCom proceedings, you are sorely mistaken. If you think ArbCom-sponsored RfCs are, in any way, a standard part of how the software development process works, please present your evidence.

  Again, if no one from your camp is willing to stand behind your tool and write the Statement for, in this ArbCom-sponsored RfC, then I will call for a declaratory ruling out of this ArbCom enjoining, for a period of one year, you and all other parties to this ArbCom from promoting the adoption of that particular tool on Misplaced Pages. Greg L (talk) 18:30, 9 March 2009 (UTC)

Although no offense was taken, I still feel obliged to apologize for my rude language, both to Greg and to the community. I stand by my sentiment, but I should have worded it differently. I understand that tensions have run pretty high on this matter, and there's no need for me to contribute to the escalation. Greg, I still don't see any point in continuing to carry on conversations with you, so please don't bother addressing any comments to me. Plonk! --UC_Bill (talk) 18:52, 9 March 2009 (UTC)

Not sure where to put this, so here goes, largely to Greg:

• From anything I've ever seen, MediaWiki does not work by detailed spec's, it works by individual ideas, code reviews, commits and scap's (I think that's the word for when they make the commits go live). Just a few weeks ago there was a big rollup and several things went kablooie. And even the most tightly written, reviewed and tested rollouts 'asplode when released to the wild.
• Solutions in-template are nowhere close to the efficiency (and simplicity) of code solutions. We're told to ignore efficiency, but for something as common as dates, there's a risk of hitting the "post-expansion" limit for templates. However, your specific template proposals would be welcome.
• Your statement that date formatting is something "no-one wants" seems to be untrue on its face. You yourself have advocated the same, although you prefer a manual approach. We may be able to attain the best of all worlds here, where we can let editors learn by doing (put dates in square brackets) and also achieve our aims of consistent formats and delivering comfortable formats for our global readership (depending on how well we can geo-locate and offer flex-formats for IP readers).
• And I hope you realize that the approach UC Bill is pursuing could also be used to solve that {{dialect}} problem you mention, since it involves a magicword at the top of the article to indicate "locale" preference, and the same or a similar system could be used for word-spelling preference. That way you could keep your honor intact, and I could still feel that I preserved my honour. :) Franamax (talk) 23:21, 9 March 2009 (UTC)

• Let’s address your last bullet point first. You completely missed the drift of my point regarding dialect. I was pointing out that *if* there was a way for I.P. users to set a preference for British or American English, then the text in articles could appear more natural. For instance, it would appear as color for American readers and colour for other readers. There isn’t too much confusion when this occurs, although some readers will think it a misspelling. It could also work for words that are entirely different, such as solicitor and attorney or trunk and boot, wherein there truly can be some misunderstanding. What I was decidedly not suggesting is that a header tag be placed in an article setting that entire article to, for instance, British English. What would be the point of that? If someone were to *accidentally* type {{dialect|solicitor|attorney}} then the header for that article would render it as solicitor? Of course, that makes no sense whatsoever; you just write out “solicitor” (unless you are thinking this would be a special feature for us *privileged* registered editors…). Anyway, I was making a point and wasn’t trying to promote the idea here.

  As to the last part of the last bullet point regarding “honor.” I don’t give a dump about that concept and that’s not what is motivating me here. This was purely about UC Bill’s technical solution to a problem that the community didn’t want as evidenced by this RfC. Period. What you want or *I* want is irrelevant. We conducted that RfC on the autoformatting tool, the community spoke, and the proponents of the autoformatting tool cried ‘foul’ and declared that the RfC was rigged with biased wording; ergo we were dragged into this ArbCom.

  As to all the rest of your bullet points: I don’t care, it’s irrelevant. You are wasting away the legend ink on the keytops of your keyboard arguing the merits of whatever new spiffy‑cool technology is available or could be available. This ArbCom-sponsored RfC was—in part—about this apparently now-discredited autoformatting tool and it now appears that even the past proponents are distancing themselves from it and are unprepared to defend it. Locke has already stated After all, why bother working on something if the community will shoot it down? So that’s the end of that idea and there can obviously be no ArbCom-sponsored RfC on that bastard-child piece of technology. If UC Bill et al. have some new whiz-bang thing that you think now ought to be offered up to the Wikipedian community, go through the usual channels for promoting it. Where in the world did you get the notion that you ought to be able to slip some entirely new idea sideways into an ongoing ArbCom? Greg L (talk) 02:22, 10 March 2009 (UTC)

Interesting...

Werdna just committed this so it seems we have a new date autoformatting system already. --Sapphic (talk) 02:02, 10 March 2009 (UTC)

I see comments of "Fixed, r48249", "Provide preference-based autoformatting of unlinked dates with the dateformat parser function", and "See rev:48249. Hopefully this clears things up a little". Exactly what was fixed, what is the fix, and what is the implication of "little"?  HWV258  02:29, 10 March 2009 (UTC)

• All sorts of templates and magic words and stuff is made. The halls of Misplaced Pages are littered with all sorts of unused tools. Whether these things get used depends on what MOS and MOSNUM say on the matter and that is determined by community consensus. If Werdna just produced something that will make gold dust squirt out of every Wikipedian’s USB port, it will be quickly blessed for use on MOSNUM and will prove exceedingly popular with the Wikipedian community.

  The only reason were are here is because of unreconcilable bickering even after there were RfCs. There were claims and counter-claims about what the RfC results meant and didn’t mean. In part, this was aggravated because of the nuanced complexity (gray area) on when one should and shouldn’t link. After hundreds of man-hours, these details have been mostly fleshed out. Forget Werdna. It’s time to be done with this ArbCom, unlock MOSNUM, and function again. Greg L (talk) 02:33, 10 March 2009 (UTC)

  • Indeed, I'm sick of being held to ransom by this whole business. Greg is right: ArbCom and this RfC are absolutely inappropriate to be beating the drum about your proposal. Put simply, many people do not trust the gleam in a programmer's eye. Not for one second. I suggest you work at your proposal until it is solid and tested, and launch your own process for gaining community input; to do so now, as I said, is to exploit people's lack of knowledge about how programming typically ends up. It is unfair to the community. Tony (talk) 02:50, 10 March 2009 (UTC)

I wrote a parser function that does automated preference-based formatting of dates, without linking them. It provides another option for those who want to record metadata and/or provide automated formatting of dates without the clutter of links. Whatever consensus is developed, it exists as a "second option". — Werdna • talk 03:24, 10 March 2009 (UTC)

I do not believe Werdna has created a parser function that does automated preference-based formatting of dates, because I do not believe (s)he has any means to determine the preference of readers who are not logged-in. I also caution Werdna that if (s)he intends to use the letters "ISO" or the character sequence "ISO 8601", or in any way imply that (s)he is following the ISO 8601 standard, (s)he should read that standard before proceeding. Pay particular attention to the part about the Gregorian calendar.--Gerry Ashton (talk) 03:33, 10 March 2009 (UTC)

Werdna, Gerry is pointing out a fundamental problem in that strategy. And does it have specs, and has it been demonstrably tested? Tony (talk) 04:21, 10 March 2009 (UTC)

I've had a look through the code, however as my expertise is in C#.net and t-sql, it was a struggle. I must admit that I find comments like "Horrible hack" and "Another horrible hack" simultaneously troublesome, and refreshingly honest. By the way, your code needs to be flooded with many more comments. I notice that another user has commented that "{{#formatdate:9 March 2009}}" produces 9 <span class="mw-formatted-date" title="0009-03-20">March 20, 09</span>. That leads me to ask the following questions (before further analysis):

• Which sample dates did you use for your unit testing? Could you please publish those so that we can see if they are representative of the dates we will be considering for this issue.
• Did anyone else test your code before you published its availability to the WP community (under the heading of "Fixed")? A peer-review, walkthrough, and testing by someone else can often be invaluable.

Cheers.  HWV258  04:30, 10 March 2009 (UTC)

"Let's hope this works"—okay, that comment in the code indicates that we're now getting a little crazy. Or is that an attempt to bait us? Either way, I think we're done here. Pity.  HWV258  05:50, 10 March 2009 (UTC)

"We're done here." Care to explain what you mean by this? --Ckatz_spy 06:01, 10 March 2009 (UTC)

I'm questioning whether we should be spending time considering using code that contains comments such as "Horrible hack", "Another horrible hack", and "Let's hope this works". Do you feel those comments inspire confidence in the end result? In addition, with the lack of testing (and test cases), the bug found after the initial post of "Fixed", and the fact that the code doesn't address the range of concerns raised during the various RfCs (e.g. date ranges), why are we considering this within this forum? Werdna's (well-meaning) submission should have been announced at another venue, and perhaps used as part of the solution—after the requirements are known.  HWV258  06:14, 10 March 2009 (UTC)

Heh. Do you judge code by the comments or by the code itself and the output? Have you prepared the test cases for the devs, or are you secure in your armchair? HWV, you seem to know the requirements, please enunciate them. There are now multiple software people on the case, let's apply some wetware to get it done. You yourself can outline the requirements - we're all volunteers here. Franamax (talk) 07:30, 10 March 2009 (UTC)

Where to start? Yes, I do judge code by its comments as well as its output (and I especially take note of self-deprecating comments that cast doubt on the efficacy of the coding itself). If you are curious as to why, I'm happy to have an off-line discussion with you concerning the software life cycle. Unit test cases are prepared by the developer, and I've requested a copy of those (by the way, there was no opportunity to prepare test cases as the code was presented as fait accompli by the developer as "Fixed"). I myself cannot outline the requirements as this is a community effort. I will say that I have contributed to the effort by encouraging the specification process (here). Your attack here suggests that in some way you are supportive of the process that happened around release 4582—can that be right?  HWV258  21:31, 10 March 2009 (UTC)

Good grief, this is a tempest in a teacup.

The code I committed was a very simple fulfillment of a MediaWiki feature request almost as old as dynamic dates itself. I merely wrote some code to extend existing date formatting to unlinked dates (which was the request in the relevant bug). As I have stated repeatedly, that particular feature has been fulfilled. Please file other requests as separate bugs.

I have little or no interest in the current arbitration, which, after all, features people who care enough about date formats to actually carry on sustained and frequently unpleasant arguments about them voluntarily. The bug report was not about resolving that arbitration case, but about extending date formatting to unlinked dates. Questions of anonymous user preferences, and ISO 8601 compliance should be opened as separate bugs. Whether or not the required hardware and software infrastructure to support any selection method other than user preferences for sparing Americans the horrors of seeing the day before the month is an open question, and one that I conceive most of the technical team would answer in the negative. I would have to ask Tim, but I imagine that the preference was put in mostly to stop bickering, rather than to improve user experience.

As for the insinuations about the quality of my code, I ask that people here leave such matters to those who know what they are doing (i.e. the technical team). If you can find a concrete bug in my code, I invite you to provide a test case. This means you should install the latest svn revision of MediaWiki and try it out. This is a welcome contribution to the development process, and the best way for you to participate in development.

What is less welcome is supposition and paranoia based on my code comments. Yes, conducting string manipulation on regexes is a horrible hack. No, that doesn't mean the code doesn't work correctly. Myself and at least one other highly experienced MediaWiki developer have decided that this was the best way to approach the problem. Without testing code, writing it off because of my opinion of its implementation is unhelpful, as obviously if I felt it was inadequate, I would not have committed the code in the first place.

Requests for test cases are possibly understandable, but most of my testing was done by trying out all the different input and output formats in the edit window and clicking 'Preview'. We don't have a well-developed unit testing framework in MediaWiki (perhaps one of you would like to write one!) Regrettably, one bug when invalid input was entered slipped through, and it was fixed as soon as it was reported. This is considered normal. Most commits to subversion are revised once or twice because a bug or two has slipped through, and our code is better for it, as most code changes are reviewed by several developers before going live. We appreciate feedback on any bugs or shortcomings.

My apologies for the long response, there seemed to be a lot to reply to and a lot to say! Constructive suggestions for improvement to my specific changes (i.e. exclusively the parser function to allow unlinked dynamic dates) may be addressed to me. Other concerns relating to dynamic dates should be submitted as bugs on bugzilla with the component "Page rendering". — Werdna • talk 13:07, 10 March 2009 (UTC)

Werdna, thank you for the time you've put into this. However, the issue has long been decided that the community does not care for hi-tech solutions where there is no discernible problem. The implementation of your programming, if it were demonstrated to work without hitches, would still violate a basic principle—that we should all see the same output: us and our readers. It's basic to ensuring that we know what our readers see. Nowadays, BTW, we don't seem to bicker about which format should be used in each article. Tony (talk) 13:35, 10 March 2009 (UTC)

It has long been decided that Tony likes to steal candy from small children, and kick dogs. By "long" I mean I just made it up right this instant, and I don't have a very good memory. Nonetheless, if I repeat it enough times, people that don't bother reading the (epic!) history of this dispute might be fooled.

Good job Werdna. Your help is much appreciated. You'd do well to just get away while you can, and don't get drawn into the insanity of this discussion. I'll handle the insanity part. It's fun. --Sapphic (talk) 14:12, 10 March 2009 (UTC)

Autoformatting - moot?

Given that a recent bug fix has led to users being able to autoformat unlinked dates, can we all agree that the whole autoformatting issue is essentially moot now? Ryan Postlethwaite 11:04, 10 March 2009 (UTC)

• Werdna’s software is simply a date-related piece of code that might or might not be used in in tools, depending on what the community wants on MOS and MOSNUM. It doesn’t impact the question of whether the community wants UC Bill’s autoformatting tool.

  It now appears that Locke and UC Bill themselves no longer believe the community wants UC Bill’s “son of autoformatting” tool. IMO, the issue of UC Bill’s tool in this ArbCom should be ruled as “defaulted” (the community doesn’t want formating tools if they don’t benefit I.P. users equally) if no one from that camp steps up to the plate and writes the Statement for in support of it. They dragged us here, in part, over this issue and now want to sweep it under the rug and say “never mind”. That is unacceptable. The community should either vote on the issue or a default judgement be issued. Greg L (talk) 17:11, 10 March 2009 (UTC)

To be absolutely clear, I fully stand by my code, 100%. The point that Locke Cole and I (among others) have been trying to make is that the RFC shouldn't be locked into voting on my specific implementation. If the community decides it wants a new system to replace the current date autoformatting/autolinking — but they ultimately decide on a different implementation — that's fine with me. If somebody else wants to download my code (available here) and come up with their own version, that's also fine with me. Nobody is "backing away" from my code, we're simply trying to make it clear that it's not the only software-based solution. Werdna's recent change to the actual Misplaced Pages software (his wasn't just proposed, it's now the "law of the land") might make a template solution feasible, in which case there's yet another entirely workable solution, that's also software-based. People need to be made aware of all the options, not just a few specific examples. --UC_Bill (talk) 17:25, 10 March 2009 (UTC)

• Perhaps UC Bill stands by his code, but Locke, at least, seems to have a premonition that the community won’t stand behind it, since he wrote above After all, why bother working on something if the community will shoot it down? (16:08, 9 March 2009 post).

  Now, once again: That camp declared that this RfC, where UC Bill’s concept was thoroughly rejected by the community, had suffered from rigged questions. So that camp dragged us here into this ArbCom. Now they claim they stand by their code but acknowledge the community will reject it. This reminds me of companies that pay FTC fines but don’t admit fault: “We didn’t do anything wrong but agree not to do it again and would you like to buy some of our new & improved® Swedish anti-aging cream?”

  We somehow need to get out of this ArbCom, a decision—either from an RfC presented to the community or via a summary judgement by the ArbCom—that the community doesn’t want date formatting tools that provide “purdy-lookin’ dates for we privileged registered editors but a default for everyone else.” You guys are just pissing in the wind if you hope to keep ducking that basic point, which the community has already made itself exceedingly clear on, but which you refuse to acknowledge. If necessary, it’s back to basics. The basics are good. Greg L (talk) 17:50, 10 March 2009 (UTC)

Huh? What bug fix where? Colonies Chris (talk) 11:48, 10 March 2009 (UTC)

See rev:48249 for the exact fix (it has gone live yet, but it will do with the next sync). Ryan Postlethwaite 12:05, 10 March 2009 (UTC)

Can you please explain in simple terms what this is about? Is this a fix to the existing autoformatting system? Is it a fix to the proposed autoformatting system, or what? Specifically, is this a new facility, in addition to the present autoformatting system or a change to the current system? Does it work with the same markup? If not, how does it work - will additional markup be necessary? When you say "users being able to autoformat unlinked dates" do you mean that autoformatting happens without markup? Or do you mean that dates marked up for autoformatting will not be linked? Or that there will be some new markup to autoformat without linking? If it's the last case, what about all the existing autoformatted (and linked) dates? What part of the autoformatting issue does it make moot, and why? For those of us who haven;t been following every nuance, clarification please. Colonies Chris (talk) 12:54, 10 March 2009 (UTC)

Werdna's change (which has already been committed — meaning it will be part of the software, regardless of what we have to say here... not entirely sure how I feel about that) creates a new "parser function" that can be used in templates. It doesn't change any of the other behavior of the current date autoformatting system... except possibly to break YYYY-MM-DD formats (I'm looking into some test cases there.. trying to figure out why Werdna made some changes to some "case" statements.) It means that you would be able to use syntax like {{#formatdate|January 15, 2008}} to produce autoformatted dates that aren't linked. That syntax could be hidden inside (say) the {{date}} template, or elsewhere. It's really pretty nice.

All that said, it doesn't make the date autoformatting/autolinking issue moot, because it doesn't change the behavior of the rest of the system. Dates within square brackets are still autoformatted and autolinked, anon users still (potentially) see a mix of incompatible date formats within a single article, and registered users have no way of disentangling autoformatting from autolinking. It's possible that a template-based solution might solve a lot of those issues... but it would still need to be developed. So no, Ryan, it's not moot.. but we're getting closer. --UC_Bill (talk) 15:08, 10 March 2009 (UTC)

How does the new facility interact with linking? I'm not a fan of date linking, but I recognise there are cases where it's appropriate to link a date or a date fragment. Will this new facility allow both autoformatting and linking to coexist on a single date? Colonies Chris (talk) 15:23, 10 March 2009 (UTC)

You can already get autoformatting and linking by using the ] syntax. What Werdna's new parser function does is allow you to get autoformatting without linking, which was previously impossible. --UC_Bill (talk) 15:32, 10 March 2009 (UTC)

I don't think it's going to help us wth this dispute at all. I don't think we should be bothering with autoformatting at all but, as a compromise, if, for example, the millions of existing dates linked for autoformatting could be converted to the new syntax, that would give the fans of autoformatting what they want, and give the opponents of overlinking what we want, but the people who insist that the links are vital and can't be touched wouldn't accept that at all. So we're no further forward. Colonies Chris (talk) 15:58, 10 March 2009 (UTC)

You can always ask on the code review interface or read the comments, rather than trying to second-guess my intentions. That was to fix a revision a moment earlier to add a <span> element with the Y-m-d format around autoformatted dates. I just moved the lazy initialisation of some regex matches further up, as they needed to be used later on anyway (so there was no use in lazy initialisation). Look at the bottom of format(). — Werdna • talk 15:18, 10 March 2009 (UTC)

Thanks for the explanation. I missed the part where you moved that initialisation up to before the case statements. I'm currently (re-)installing svn so I can checkout a fresh copy of the trunk and put together some unit tests for the various date formats. I'll post the results here once I'm done (so please everybody stop bugging Werdna about his testing process, and bug me instead.) --UC_Bill (talk) 15:43, 10 March 2009 (UTC)

Cole's edit-warring to remove the link / Tony's edit-warring to insert the link to Tony's collection of support

The section "History of the dispute" is biased without a reference to the large amount of support that was gathered from the community at the time. Cole insists on removing the link to this (censorship again), so I have placed a dispute tag on this section. Tony (talk) 14:30, 10 March 2009 (UTC)

Disadvantages of year links section

Tony1, do not undo my change to this section again. The wording you're trying to keep is entirely opinionated and draws conclusions that are prejudicial to RfC respondents being able to come to their own decision about year links. -- Earle Martin 15:28, 10 March 2009 (UTC)

And you've done it again. Using the word "tampering" in your edit summary clearly demonstrates your ownership issue with this process. -- Earle Martin 16:06, 10 March 2009 (UTC)

Ah, what right do you have to order me not to undo your changes, when you are undoing my changes. A little rich, don't you think. You are introducing your own significant bias into the section. Would you like us to go around tampering with the advantages? Quite happy to. I'll start tomorrow. Tony (talk) 16:27, 10 March 2009 (UTC)

I should have said blindly undo, because that's what you specialize in.

Significant bias? Horseshit. Your version states unproved opinion (year links always lead to dilution and overlinking; year links complicate syntax ) as facts. My version states facts as facts - unless you would like to argue that it is untrue that year links can lead to overlinking and dilution.

"Tampering" with the advantages? I'd have called it disagreeing with or modifying, personally. And it would be accompanied by talk page discussion. But I'm glad you're willing to use such language in reference to your own actions; it displays a previously unseen degree of honesty. -- Earle Martin 16:49, 10 March 2009 (UTC)

New parser function

Werdna has committed a new parser function to the software, and it will be available on the Misplaced Pages site sometime soon. I've put together a demo site — including a page of unit tests — here:

• http://phase3.xoom.org/index.php/Unit_tests

(Once Werdna's changes go live, the content of that page can be copied to Misplaced Pages.)

Note that the parser function will not work for dates that are missing a year, so while it will handle {{formatdate:15 January 2009}} correctly (formatting it according to user preferences, or else leaving it as "15 January 2009" for anons and users with "no preference") it will not work for (e.g.) {{formatdate:15 January}}. That might be fixed at a later time, or it might be a completely unnecessary feature that nobody wants.

In any event, it will soon be possible to have autoformatted dates that are not linked. Development of an even more robust system is still underway, and development of improved template-based solutions should now be easier. --UC_Bill (talk) 18:12, 10 March 2009 (UTC)

The parser function passes the date unchanged for those who are not logged in, so it falls under the clear rejection of the present autoformatting system. It is just plain unacceptable. --Gerry Ashton (talk) 18:18, 10 March 2009 (UTC)

I really hate it when people use the word "unacceptable" for things that are already done. This code has already been committed. It doesn't matter whether you "accept" it or not — it's going to be part of Misplaced Pages, probably later today (or whenever the next update occurs.) I'm not entirely sure I like that (since it bypassed this process entirely, and a lot of the points made here have been really good, even if I don't agree with all of them) but it's the way things are. If you don't like it, we'll need to work to get it changed, but it has already been "accepted" by the people who run the website, and ultimately theirs is the "acceptance" that matters. --UC_Bill (talk) 18:25, 10 March 2009 (UTC)

These tactics make it imperative to rip out autoformatting syntax at the earliest moment that such is allowed, in order to wrest control of this issue from the developers who like to play with their toys. --Gerry Ashton (talk) 18:38, 10 March 2009 (UTC)

What 'tactics' are you talking about? I don't think there's anyway to take control of the software out of the hands of software developers. And this whole site is one of the "toys" you're complaining about. You do realize that Misplaced Pages runs on (shudder to think!) software, right? And that this software was written entirely by developers? If you're really that much of a Luddite, Gerry, then what in the world are you even doing here? There are plenty of paper encyclopedias that I'm sure could use some volunteer help. As for those of us who like software, we'll keep contributing both content and code to this project. --UC_Bill (talk) 18:46, 10 March 2009 (UTC)

Werdna and UC Bill make it evident that Wikimedia developers cannot be trusted and that I should abandon accounts with my name in them. --Gerry Ashton (talk) 18:58, 10 March 2009 (UTC)

As I've tried to explain on countless occasions, the "Wikimedia developers" are anybody that submits code. Think "developer == editor" in terms of Misplaced Pages terminology. The people with real power are the committers (think "admin") or systems administrators (think "steward") and I am neither of those things. Werdna is a committer, which gives him the power to make actual changes to the software directly (rather than just submitting them for approval.) Saying "Wikimedia developers cannot be trusted" is like saying "people that edit Misplaced Pages cannot be trusted" and is silly because it potentially applies to just about anybody. --UC_Bill (talk) 19:09, 10 March 2009 (UTC)

(outdent) UC Bill, let me see if this message connects with you (maybe not): You are a programmer/developer-type, yes? You slave over cool code and make cool tools available to the community, yes? Please consider what this really is all about. Locke doesn’t like looking at dates formatted like “15 December 2007" (or the other way around; I don’t know for sure and don’t care). What the Wikipedian community does not want is to fuss around with extra effort of any sort instructing editors to put double-curly-brackets around dates (or even more horsing around), just so a vanishingly small percentage of registered editors like Locke can be spared the shock of seeing a Euro-formatted date. There is simply no point to suffering with this hassle if it only provides a fixed default format that 99.99% of our readership sees; we might as well just write out a fix-text date in the format suitable for a given article.

I suggest that if you want to make a really cool software tool, you make something that either A) looks to anonymous users’ I.P. addresses and looks to a table of country codes in order to anticipate the date format they customarily use in that country, or B) develop something that gives all users (especially regular I.P. users) the ability to set a personal date preference. But what the community does not want is to horse around with stuff that provides a special view of article content for a vanishingly small percentage of our readership.

And another thing: this “small percentage” of our readership happens to be active editors who are keenly tuned to date-related issues. The community has also spoken to the point that they want these editors looking at precisely what everyone else sees and does not want to horse around providing them blinders that prevents them from seeing when date formats are inappropriate for a given article. And, one final point: The community is also really, really tired of this issue. It is a big fuss about minor arrangement of month and day that causes no confusion whatsoever. It is a fuss over nothing.

I think your talents would be better spent making tools for problems the community thinks is truly a problem. Greg L (talk) 19:31, 10 March 2009 (UTC)

"a fuss over nothing": My God, Greg, I think you and I actually agree over something. -- Earle Martin 19:41, 10 March 2009 (UTC)

Greg, let's try this another way. What's the substantial (and objectionable) difference between manually writing dates according to WP:ENGVAR and forcing anonymous (IP) readers to see that, and marking up dates with brackets (] ]) and letting a magic word ({{DATEFORMAT:DMY}}) control the date format that is ultimately output? I think the only one I've seen is this bizarre principle you keep putting forward that editors and readers shouldn't see different things, but this actually happens all the time on Misplaced Pages (the thumbnail size you set in Special:Preferences is used to change the default size of images rendered as thumbnails; we use markup to bold and italicize things repeatedly, and wikitext is often filled with template calls that look nothing like the final rendered product). So why the resistance to something that actually resolves some of your biggest complaints (that readers see an inconsistent date format (that was the original complaint))? Why the moving of the goalposts? —Locke Cole • t • c 20:55, 10 March 2009 (UTC)

This isn't only about giving Locke Cole (or anyone else) the ability to see dates in the format they want — it's about making them shut up about trying to force their preferences on other people. The point of user-specifiable preferences is to take away the main reason people have to get into arguments about it. A policy on MOSNUM isn't going to solve that. If the policy is anything other than "all dates should be in YYYY-MM-DD format and fully linked" then I'm going to fight you on it. So will a lot of other (probably mostly tech-oriented) people who prefer that format and don't consider "overlinking" to be a problem at all. Those people are (mostly) quiet right now, because they still mostly see dates in the format they prefer. If that option were to be taken away from them, then it would provide grounds for endless argument over the "correct" format to use. The point of preference-based autoformatting/autolinking is to eliminate most of the arguments over date formats. If people with strong opinions can simply choose their own format, then the only thing to argue over is what the default for anons should be, and nowhere near as many people care about that (I know I don't.. as long as the default is sane, obviously.) As for the other features you'd like, I'd like those too. The lookup table approach won't work because of how Misplaced Pages's cache servers are set up. A Javascript-based approach could work, but it would need to be developed and I am not a Javascript programmer so I can't do that. Somebody else could, though. In any event, some kind of markup around dates would be required no matter what approach we take (except the "plain text" approach, which should be put to the community in an RFC) and something should be done with the existing date autoformatting/autolinking code that's already in the code base — even if it's to rip it out entirely and go with "plain text" for all dates. This head-in-the-sand "I'll just call it 'unacceptable' until the mean people go away" strategy just really makes no sense. --UC_Bill (talk) 19:44, 10 March 2009 (UTC)

• Quoting you, UC Bill: It's about making them shut up about trying to force their preferences on other people.: There are other ways to accomplish that end without burdening all editors with extra editing labor just to provide a privileged few with a special view of article content. If editors won’t stop flogging the dead horse, and/or edit tendentiously, they can be so advised by admins and blocked if necessary. I don’t pretend to understand why this hasn’t happened yet, but I wouldn’t bother attaching myself to a cause if I knew, deep down, the larger community wasn’t anxious to embrace it. This sort of thing happens all the time in the *real world*; if you had any idea about the amount of money and effort put into getting patents on ideas that never went anywhere in the marketplace… Greg L (talk) 20:31, 10 March 2009 (UTC)

"In any event, some kind of markup around dates would be required no matter what approach we take (except the "plain text" approach, which should be put to the community in an RFC) and something should be done with the existing date autoformatting/autolinking code that's already in the code base — even if it's to rip it out entirely and go with "plain text" for all dates."

Been there.

Done that.

Got the T shirt.

(Although, not for all dates: a very few plausible exceptions will stay linked.)--Goodmorningworld (talk) 20:06, 10 March 2009 (UTC)

• So… what kind of to-the-point, central question should be put to the community in your opinion, Goordmorningworld? Do your best to come up with something that can put all this to bed. Greg L (talk) 20:22, 10 March 2009 (UTC)

  P.S. I propose that this be part of whatever you come up with:

Should editors ever be burdened with extra editing labor just to provide a privileged few with a special view of article content that regular I.P. editors don’t see?

Greg L (talk) 20:36, 10 March 2009 (UTC)

"Privileged few"?!? Greg, I'm surprised you didn't mention the "very very special licence" at the same time. Why do you persist in pushing this idea that registering for a web site - registration that takes next to no time, that requires no validation whatsoever, that costs nothing - is in some way exclusive? Anyone can register, anyone can set the user preferences, anyone can take advantage of the Wikimedia features - settings, gadgets, Javascript, and so on. Making it out to be some sort of secret club adds nothing positive to the discussion. --Ckatz_spy 22:00, 10 March 2009 (UTC)

• Sure, Ckatz. Anyone can register. But 99.9+% of Misplaced Pages’s readership doesn’t. While there are 48,464,049 registered editors, a vanishingly small number of those are truly, very active editors. Although Misplaced Pages can serve as a fine stand-in as a social networking site for those who want to get that much out of it, the primary purpose of Misplaced Pages isn’t about us; it’s about providing an encyclopedia for regular users. It’s a damn slippery slope heading down the path where we start providing special article content for some users and not others. To do so over this issue: date formatting where there isn’t even any confusion(!); but just because some users don’t like looking at some of the date formats in some of our articles, is inane beyond belief. And it’s just not me who feels that way; past RfCs indicate that this is a community-wide attitude. For those with a galactic-grade inability to accept the obvious, that much will be proven again with yet another RfC. Greg L (talk) 22:30, 10 March 2009 (UTC)

• Exactly.  HWV258  22:57, 10 March 2009 (UTC)

• We're not "providing special article content for some users and not others", and to argue otherwise is nonsense. It might be a fair claim if Misplaced Pages were a pay site, where only members had access to certain features based on what they paid or who they knew. That is not the case; anyone - anyone - who wants access to the features is absolutely free to do so, merely by registering. I hardly think one can say it's a "slippery slope" when there are no restrictions at all. --Ckatz_spy 23:35, 10 March 2009 (UTC)

• I daresay that most IP users are not aware that such features even exist. Dabomb87 (talk) 23:41, 10 March 2009 (UTC)
• To Ckatz: you're quite right that readers of WP are "absolutely free to do so", however the obvious point is that: the vast majority don't!  HWV258  00:06, 11 March 2009 (UTC)

• Also, I find the idea of making readers register to enjoy certain features bizarre. When intend to edit Misplaced Pages, I log in; when I just want to browse, I see no point in logging in. Dabomb87 (talk) 00:12, 11 March 2009 (UTC)

• I second everything my above wikifriends have written. Just because every visitor on the Internet can theoretically register as a Wikipedian editor, extraordinarily few would know how to do so, an even smaller portion of this subset would actually bother to do so, and an even smaller yet portion would ever remember to renew their logged-in status after it expired in 30 days.

  Further, what in the world would educate and motivate the average reader of Misplaced Pages to register?? Is there to be a splash screen for six months at the top advising all visitors that to see a *special*, top-tier view of article content with dates formatted to their liking, they should register? That is just specious babble that is beyond absurd, Ckatz. For you to suggest that this is somehow an appropriate remedy to the inherent shortcomings of a two-tier system of article content betrays the utter and complete vacuousness of your camp’s arguments.

  Fortunately, the general Wikipedian community isn’t so encumbered with the ideological certitude on this matter that you labor under, has already voted to flat reject what you propose, and will do so again—of that, I am quite confident. And you are willing to come here and spew this nonsense because you too can’t stand being exposed to a date format that is foreign to you? If I were you, I’d start looking for some other cause behind which to throw your support and efforts. The Wikipedian community doesn’t have much stomach for coding {{humorCkatz|February 15, 2006}}, they’d just as soon simply type out a date—you know—because this date-formatting issue is a bug splat on their windshield of life. Further, it’s somehow *pretty* to think that Misplaced Pages hasn’t been perpetually hijacked by a handful of intransigent editors and forced to become galactically dysfunctional for life. Greg L (talk) 01:45, 11 March 2009 (UTC)

Actually, I come here despite what certain people "spew" (your words, not mine)... apparently, this "privileged" registered status gives certain "special" editors the right to indulge in abusive behaviour as they see fit. I find it quite fascinating that the act of registering an account is portrayed as such a monumental task, especially given that every page has a "Log in / create account" link at the top of the page. Furthermore, edit screens already promote accounts as a way to gain access to "many other benefits", with an entire page devoted to detailing these features. Since you're so concerned about having a level playing field for the "99.999999999999999999%" (gotta love these unverified numbers), does that mean you'll be giving up the other "perks" registered readers also benefit from, such as watchlists, gadgets, and scripts? --Ckatz_spy 02:25, 11 March 2009 (UTC)

• "99.999999999999999999%": I told you a million-trillion times not to exaggerate. ;-) Greg L (talk) 02:33, 11 March 2009 (UTC)

• Wouldn't that make for some miniscule fraction of a registered user (assuming the entire rest of the population of the planet as readers)? Are we all just sockpuppets of a single fractional mind? It would explain a lot. --Sapphic (talk) 02:37, 11 March 2009 (UTC)........

Well to be fair, those other "perks" don't impact readers or editors that don't use them. There's no downside for readers of an improved date autoformatting/autolinking system (the current one contributes to their seeing a mismatch set of formats) but there's a cost to editors — the extra syntax of having to put square brackets around the date (or two sets of square brackets, for full dates.) I don't think that cost is significant, but I think it's important to acknowledge that it's there. --Sapphic (talk) 02:31, 11 March 2009 (UTC)

Golly. This dispute has been running for months now, with lots of opinions, a locked MOSNUM, disputed RfCs, and no clear community consensus in sight, however (based on UC_Bill's comment above "It doesn't matter whether you "accept" it or not — it's going to be part of Misplaced Pages"), one developer produces and submits code (with at least one bug, and with no documented testing procedure—so who really knows what else is lurking under the covers), and in about a 24 hour period a change in the way dates can be formatted on WP is to be released for use by hundreds of thousands of editors on potentially millions of pages. Wow! Are we really sure this isn't a clear case of circumventing any sort of natural justice? I came to WP (primarily to add information about the works of Handel) in order to get away from my daily work in the computer industry, so I'm naturally disappointed to have the software development process at WP revealed to me in such a way. If there's one place where I expected developers to sit by, and only code things that had clear specifications and consensus, it would have been in that great egalitarian exercise called WP. But sadly no. Could we at least agree that an instantaneous software release, whilst a guideline page (that might be able to describe the release's use) is locked, is not a good idea (unless, in addition to abandoning specifications, comments, reviews, unit testing, etc., WP has also done away with "how-to-use" documentation as part of a software release)?  HWV258  22:24, 10 March 2009 (UTC)

The fiction that there is a boiling cauldron of bickering over which date-format should be used on which page needs to be struck down right now. Please point to this bickering? It would need to be on a reasonably large scale for all of this bother. Also point to the significant bickering about whether US or UK spelling should be used in articles.

No, the bickering seems to be only about whether a programmers' toy should reverse day and month for some Wikipedians' displays. It is not a problem in the first place.

The RfC should concern the two issues already there. Some new form of DA cannot be put to community unless its form, function and workability have been tested and can be demonstrated. Putting a general "would you like a new silver service" is idle and misleading. Tony (talk) 04:11, 11 March 2009 (UTC)

"The Generalities" of autoformatting

So… if you autoformattingophiles don’t want to stand behind UC Bill’s specific implementation of autoformatting and only want to have a vote on the “generalities”, do tell: what are the general virtues of autoformatting? Unless there is something big-time new, I know of only one attribute to describe autoformatting as a generality that would apply to all conceivable incarnations that programmers in this and all known parallel universes might conjure up: autoformatting would invert the day-month order in dates for registered editors who’ve set their user preferences to something other than “No preference.” Is there anything else???

And all this ignores that there would actually be some *specific technology* to make this actually occur. In the engineering world, we say “don’t sweat the details on how we might do this; let’s just assume that through FM (f***ing magic), we give you these features.” So… assuming the community is going to flat-out reject UC Bill’s “specific implementation” (read: “something real”), what general virtues of autoformatting as (maybe) delivered to the community by FM should be voted upon in an RfC? Greg L (talk) 05:02, 11 March 2009 (UTC)

Since you seemed to miss this above, here's another chance for you to reply:

Greg, let's try this another way. What's the substantial (and objectionable) difference between manually writing dates according to WP:ENGVAR thus forcing anonymous (IP) readers to see that, and marking up dates with brackets (] ]) and letting a magic word ({{DATEFORMAT:DMY}}) control the date format that is ultimately output? I think the only one I've seen is this bizarre principle you keep putting forward that editors and readers shouldn't see different things, but this actually happens all the time on Misplaced Pages (the thumbnail size you set in Special:Preferences is used to change the default size of images rendered as thumbnails; we use markup to bold and italicize things repeatedly, and wikitext is often filled with template calls that look nothing like the final rendered product). So why the resistance to something that actually resolves some of your biggest complaints (that readers see an inconsistent date format (that was the original complaint))? Why the moving of the goalposts? —Locke Cole • t • c 10:30, 11 March 2009 (UTC)

• I didn’t miss this the first time you posted it. I saw it. No, let’s not “try it this way.” I’m not going to respond to rhetorical arguments masquerading as attempts at problem solving. If you want to have the community vote on the “generalities” please add to the one attribute I’ve described above. If there are no further attributes, please advise. We can always just go ahead and have the community vote (again) on UC Bill’s “specific implementation”, which was something you were extolling the great virtues of when you dragged us here into an ArbCom with the allegation that the community *really* wanted UC Bill’s idea were it not for the RfC I “rigged”. 16:18, 11 March 2009 (UTC)

The questions I see are: (options that apply to the majority of readers are boldface)

• What are the minimum features to allow the first increment of date formatting, without which any implementation is rejected by the user community?
  • Never implement date formatting under any circumstances
  • Per-page formatting for non-logged-in readers and preferenced based formatting for logged-in editors
  • Inferred preference based on browser language setting or geographic location for non-logged-in readers and preference based formatting based on express preference for logged-in editors
  • Preference based formatting based on express preferences for everyone

A question that can't really be addressed until the preceeding question is settled is:

• Considering the state of the encyclopedia, the need to provide certainty to developers of templates that contain dates, and the length of time needed to develop the first increment of date formatting, should remove the markup that implements the existing autoformatting immediatly after determining the results of the RfC? —Preceding unsigned comment added by Jc3s5h (talk • contribs) 12:57, 11 March 2009 (UTC)

• Regarding inferred preferences based on browser language setting or geographic location I'm sorry to say that such a solution isn't currently possible, given the way Misplaced Pages's cache servers are set up. All anons will see the same thing, since those requests are usually served from cache rather than hitting the PHP servers directly. A Javascript-based solution could work here, in which case anon readers could simply choose a date setting directly, rather than having to infer it from their browser settings or IP address (the latter of which would introduce serious privacy concerns anyway.)
• Regarding what should be done in the event that the community totally rejects any form of date autoformatting/autolinking, I'd suggest that the first step would be to set $wgUseDynamicDates to false in Misplaced Pages's LocalSettings.php file, which would instantly disable autoformatting for everybody, although dates inside square brackets would still be linked. Then, dates could be delinked in an orderly fashion, using work-lists generated through database analysis to identify the articles that either have the most linked dates or which have the worst "mix" of inconsistent formats. --UC_Bill (talk) 15:39, 11 March 2009 (UTC)

• Good job UC Bill. Thanks. I submit that all we need to settle out of this ArbCom is whether or not the previous RfC, where the community rejected “son of autoformatting”, was a fair and proper reading of the community consensus. Locke dragged us all to this ArbCom because he said that RfC had been rigged with slanted questions. It appears that you are conceding that, while you back your code, you acknowledge that the community doesn’t want “son of autoformatting”. If that is the case, I think we are done here on ArbCom on that issue.

  Misplaced Pages is a hobby; we’re all volunteering our efforts. And I would dislike it a great deal if I worked on something that few Wikipedians wanted. If I were you, I’d solicit input on what exactly the community wants through RfCs of your own. I’d also drop posts on the talk pages of known opponents of “son of autoformatting” (like Tony, Dabomb87, Ohconfucious, and me) in order to get a clear understanding of what the community would really like to receive, and then go to work on that. Greg L (talk) 16:18, 11 March 2009 (UTC)

Learn to read, Greg (or more accurately, stop intentionally misrepresenting what other people write.) UC Bill has offered useful suggestions for what to do IF the community rejects all forms of date autoformatting. --Sapphic (talk) 21:25, 11 March 2009 (UTC)

• Learn to read, Sapphic. I didn’t make any representation whatsoever about what UC Bill wrote, other than it was a good job. As to your imaginations as to what I am “intentionally” trying to do, your imagination runs oh so wild. Greg L (talk) 21:31, 11 March 2009 (UTC)