Template talk:Infobox OS

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Software / Computing  (Rated Template-class)
WikiProject icon This template is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 Template  This template does not require a rating on the project's quality scale.
Taskforce icon
This template is supported by WikiProject Computing.

Ready for use[edit]

I finally got around to writing the documentation for this infobox... whew, there's quite a bit of it! Hopefully it will serve as a useful guide for implementers of this template. -/- Warren 00:25, 24 September 2006 (UTC)


I added an optional logo_size parameter for logos that look bad at 250px like this one. It still defaults to 250px, so existing uses should be unaffected. Deco 21:41, 27 February 2007 (UTC)

Style / layout[edit]

So there's a perfectly good set of defaults for {{infobox}}. These defaults work fine on a great many templates, including most of the computing ones ({{infobox software}}, {{infobox computer}} and {{infobox OS}} being the most obvious). There's no real need IMO to deviate from these at all. I'd appreciate a rationale for why this box demands a special layout. For now, I've conceded to re-adding the colour strip for headers and collapsed the table borders. Chris Cunningham (not at work) - talk 20:12, 2 December 2008 (UTC)

I've made yet more concessions to the old version. A reminder again that this is temporary, until Warren explains what he means by the terms "organized", "too wide" et cetera. However, the current version is practically the same layout as the old, and is by my reckoning more compact. Chris Cunningham (not at work) - talk 08:05, 3 December 2008 (UTC)
If you consider it "concessions", then you haven't thought about why the old template was the way it was.
I've set up User:Warren/Tableau with the current template at the top, and working backwards chronologically to the original template, so you can see the issues all at once.
Width: You've increased the width of the template by 35 pixels without a justification. Again, it's vital to remember that width is at an absolute premium at the beginning of articles. The navbox was 310px before, which is already too wide.
Chances are pretty good that you're using a high-resolution display... try viewing User:Warren/Tableau when the browser is set to fit within a 1024 pixel-wide display. The lead sentences of the article break roughly as follows: "Windows Vista is a line of operating systems[4] developed by Microsoft for" "use on personal computers, including home and business desktops," "laptops, Tablet PCs, and media center PCs. Prior to its announcement on" "July 22, 2005, Windows Vista was known by its codename Longhorn.[5]" The original template layout has enough extra width to add two more words, "Development of", in those first four lines. It's not much, but every bit helps on a smaller screen.
Now you might argue that you needed to make it wider to fit "Default user interfaces" on one line. I don't think we don't need this field at all; it wasn't in the original template design, but someone added it and several other parameters earlier this year without an edit summary or any decent rationale for doing so. With the exception of "Platform support", which is something that has changed from version to version of the operating systems we use this template on, I think all of those fields can go. That'll reduce the perceived need for width.
Organization: The old template had sections for Developer (whose contents are centered), Release Information (which is a table), Support Status (whose contents are centered), and a free-form "Further reading" section. Remember that the only purpose of the navbox is to help the user navigate and find some detail they're looking for quickly. Your earlier design lost all of that organization and turned it into a single long table... long tables are hard on the eyes, and the user ends up not even trying to take it all in. (this is user interface design philosophy) Your revisions have fixed some of this, but I still believe that "is it being supported" is still worthy of its own section.
Border: It should go around the whole thing. There is a visual consistency involved in having the top border of the box align with the first line of the article. Having a logo and part of the information contained in the navbox floating free adds a bunch of empty space around the top, which is disconcerting. Again, this is UI design philosophy.
Also, the colons are missing. The text on the left serves as a label for the text on the right. Colons are a visual cue. Again, this is UI design philosophy.
I keep bringing UI design up because I work professionally as a user interface and user interaction designer. Organizing and presenting information on computer screens is my life's work. So I like to think what I know what I'm talking about here. You self-identify as a system administrator on your user page, so I understand why you'd value consistency and the technical aspects underlying how the template works. But that's really not important as far as the final output is concerned -- what's important is the answer to the question, "will the user look at the article and be helped, or be frustrated?" Everything you do with template editing should serve only that purpose. Warren -talk-
Hey, my current job isn't under discussion here. Let's not go pulling rank. To address these points:
  1. Width. The default width of an {{infobox}} is 22em. This is used by all {{infobox}} templates by default. If you think that this value is too high, then it should be addressed at template talk:infobox, which will benefit the whole project and not just a handful of articles on various Windows and Mac OS versions. The same goes for the additional spacing caused by not making the borders collapse - if you think this should be the infobox default then please request that centrally and it'll benefit everyone. Turns out that just shortening a couple of labels fixes this without resorting to hacks. With the borders uncollapsed (which is the default), the infobox is currently only a handful of px wider than the old one, and doesn't result in any wrapping of text relative to the old one if the first paragraph of your test page.
  2. Organisation. I agree that there is some value in breaking up long lists of key-value pairs if it helps readability. This can be easily done using section headers. The current version splits at the same points as the old one.
  3. The infobox is a table. Using a caption to denote a table heading is a perfectly standard, semantically valid way of presenting an HTML table title. I just can't agree that this is a negative usability-wise.
  4. The colons are unnecessary - the information is presented in clear key-value pairs, using separate HTML elements and different styling. We could add all sorts of different ways of making the types stand out from each other - putting the key in upp case, or making it bright red, for instance - which we do not do because it is unnecessary. Colons are an indistinct form of screen punctuation and do not add significantly to the distinction.
In the interests of keeping a dialogue going, so far as I can tell the only current sticking points are:
  1. The need for colons as separators;
  2. The use of a caption rather than an in-table header for the title;
  3. The need for an off-green background colour to the headers rather than leaving it transparent.
Chris Cunningham (not at work) - talk 11:28, 3 December 2008 (UTC)
Coloured Infobox section headers are extremely common on Wikipedia. I picked Cleveland Indians, World War II, Mars and James Earl Jones off the top of my head as articles likely to have Infoboxes, and all four of them use a background colour. Again, it's a visual navigation aid; if you don't like coloured backgrounds for Infobox section headings, fine, but you'll have to take up the fight elsewhere.
I disagree that colons are unnecessary, but whatever, not worth arguing over. I've seen colons go into and out of Infobox templates a number of times over the years.
I am also in the group of people that thinks 22em is too wide for most Infoboxes. {{Infobox}}, at its default size, will occupy almost a third of the browser's total width when maximized on a 1024-pixel wide screen. And that's a third of ~1000 pixels... a lot of people using mobile devices don't have that kind of luxury, and a lot of other people don't use fully-maximized browser windows. Frankly, it looks like shit, and I have some doubts that that particular decision was made through any kind of process beyond "hey, what's this wedged in my ass? i'll pull it out! oh, it's a 22!". 19 or 20em would work better for a wider range of display devices, and wouldn't infringe on the actual content of the article so much.
Finally, the Infobox isn't a "table". It's a box containing information, which includes a list of name/value pairs (and a name/value pair is really stretching the definition of a "table", which is typically a construct that gives specific meaning to the X and Y axis), lists of articles, images, and other navigation elements. The notion that a table caption appears above the top of the table's border doesn't apply here. And again, it looks bad. If you aren't going to change it back, then I will. Warren -talk- 16:16, 3 December 2008 (UTC)
In order:
  1. transparent headers are also extremely common. I could rattle off a few examples too. And I already did "take up the fight elsewhere"; I took it up on the WikiProjects: I took it up on the {{infobox}} discussion; and I take it up periodically when people discuss further standardisation of infobox templates. The rest of the computing WikiProject uses them, which was my doing, and has done for some time now without opposition. So here I am "taking up the fight" with the last hold-out on the Project. If you'd like to give the argument for why it is that including an arbitrarily-coloured stripe aids in readability of the template significantly enough to overcome the drawback of the distraction it causes, then we can have that, but I'd rather it were done centrally on template talk:infobox.
  2. Cool, that's settled then. Again, I'd have no problem with these going back in if there were consensus on the issue. In fact, in the long run these could be automatically generated using the CSS :after pseudo-class. But that's something to discuss in the years ahead.
  3. Well, that the standard width "looks like shit" is definitely a minority position right now. I'd have to ask you to take up the fight elsewhere on this one. :)
  4. It's made from a <table>, uses semantically-valid HTML table constructs and classes, and presents data in a structured and tabular format. I don't think the definition of "table" you've given is what is generally meant by the term when discussing semantic HTML. As for it "looking bad", again, it's gone unopposed on a good deal of other templates, so this is an issue of personal preference. If you want to change it then it can be modified into an "above" attribute pretty easily, but I'd rather we had a wider discussion on the final outcome.
Chris Cunningham (not at work) - talk 17:02, 3 December 2008 (UTC)

←Perhaps one of you could kindly put both versions side by side so that others might compare them? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:23, 3 December 2008 (UTC)

/testcases. Warren's pre-infoboxing rev is in the /sandbox. Chris Cunningham (not at work) - talk 20:46, 3 December 2008 (UTC)
Thank you. I made a table so that they are now side-by-side. I can't believe there's an edit war over such small differences, but FWIW, I prefer the {{infobox}} version overall, but prefer the heading to be inside the box, as in the "Previous" version. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:58, 3 December 2008 (UTC)
Windows 7 is one of the top 100 articles on Wikipedia. Windows Vista was in the top 20 when it was released. This template isn't off in some far-flung corner of the encyclopedia; tens of thousands of people see it every day. I've been working on the encyclopedia long enough to know that people need to be literally brow-beaten into producing something that looks good instead of focusing solely on the technical exercise of simply adding content, or consolidating for the sake of maintainability. The new {{Infobox}}-based template may be more maintainable, but given that there were only a handful of non-bot edits in the last year and a half, there's no solid justification for improving the maintainability at the expense of the visuals. Warren -talk- 00:00, 9 December 2008 (UTC)
That's a purely subjective call. Given that there has been no discussion on any of the other software templates regarding the styling, and that several articles using those infoboxen are higher placed than Windows 7 in the page view listings, this suggests that you're the only one who feels so. You're using "code versus looks" as a straw man, when in fact I believe that the new styling was more attractive as well as being more functional. Still, there's no time limit on getting these improvements rolled out; I'll take the issue to the WikiProject page. Chris Cunningham (not at work) - talk 00:51, 9 December 2008 (UTC)

Reference styling[edit]

So a change to have the references in the lede changed to use proper <ref></ref> tags instead of superscripted inline extlinks was reverted with a cryptic edit summary which I can only assume was meant to mean something like "I respectfully disagree that this is a productive change". I don't see why there's a reason for these links to be included inline instead of in the refs section - reference styling should be consistent within articles and that includes the infobox. Planning on restoring the use of proper ref tags here. Chris Cunningham (not at work) - talk 11:56, 8 December 2008 (UTC)

Os Cite needed[edit]

The "Os cite needed" is not working, if the release_version does not have a URL, still show "[info]" but with no link--Sotcr (talk) 01:42, 9 December 2008 (UTC)

I Mean, like in here [1], in the Preview_Release says (citation needed), but now that does'nt work --Sotcr (talk) 01:44, 9 December 2008 (UTC)

Discussion at WP:SOFTWARE[edit]

I've opened a larger discussion of the styling issue over at Wikipedia talk:WikiProject Software#Infobox discussion. Chris Cunningham (not at work) - talk 10:11, 9 December 2008 (UTC)

Six weeks later, there has been no opposition. This has been broadcast as widely as it can be put now; as such, in the continuing lack of opposition from anyone but the template author, I'm syncing this with the new sandbox code again. Any issues, please let me know. Chris Cunningham (not at work) - talk 14:25, 17 January 2009 (UTC)
Yeah, you didn't resolve /my/ issues with the infobox layout. Until you can produce a version of the {{infobox}} template where the top part goes inside the box, not outside, then I vehemently oppose this change. Warren -talk- 17:55, 17 January 2009 (UTC)
Done. Test cases. Chris Cunningham (not at work) - talk 11:24, 18 January 2009 (UTC)

ref tag broken[edit]

It appears that some changes to this template have broken the element that generates the <ref> ... </ref> tags. This looks to be from the data9 and data10 elements in the template.

For examples, see:

  • Windows 7 where the first entry in the references section is "[{{{preview_url}}} info]"
  • Mac OS X v10.5 where the first two entries in the references section are: "[{{{first_release_url}}} info]" and "[{{{release_url}}} info]"

--- Barek (talkcontribs) - 18:09, 17 February 2009 (UTC)

I don't know why the URLs aren't being formatted properly in the ref tags, but I've changed them to inline links again to fix this. Chris Cunningham (not at work) - talk 09:27, 18 February 2009 (UTC)

proceeded by/succeeded by[edit]

Could we have:

| header22 = proceeded by
| data22 =
| header23 = succeeded by
| data23 =

Such that one can indicate Apple System 6 was succeeded by System 7 etc.. ? An alternative might be next/previous. Alternative:

| label31 = Predecessor
| label32 = Successor

Electron9 (talk) 09:37, 12 May 2009 (UTC)

I just swung by to ask for the exact same thing (only it's spelled preceded). I would love to just go through OSes and not have to hunt for the earlier OS. But looks like this was requested a year ago with no comment (I don't know if the addition was made to the template and the /doc page not updated). But if anyone's out there, a "preceded by" and "followed by" parameters in the infobox would be wonderful. – Kerαunoςcopiagalaxies 00:26, 10 June 2010 (UTC)
YesY Added. I tested it on my own sandbox, but obviously feel free to fix/revert and be sure to double-check my additions to the /doc page as well. Appreciated. – Kerαunoςcopiagalaxies 01:00, 10 June 2010 (UTC)

Merging templates[edit]

When this template is merged with template:inforbox os could we create a section so for example it would look like it is now but you would for example do this to get version

{{inforbox os 
| os version = yes

So that it is still a different type of template compared to template:infobox os please (talk) 16:50, 15 December 2013 (UTC)

Who says it is going to be merged? I tried to merge them twice but their technical differences are so huge, I aborted midway. Those carried-away flock of uninformed editors who blindly voted can sure try, but if I see a single problem with their merger, I'd revert.
Best regards,
Codename Lisa (talk) 02:50, 16 December 2013 (UTC)

Completely new Infobox OS[edit]

There is no way we can merge Template:Infobox OS and Template:Infobox OS version, because as Codename Lisa said, there are huge and complex differences between the two infoboxes. My suggestion is that we create an entirely new Infobox OS, or at the very least add more parameters to the existing Infobox OS. It's not worth merging the infoboxes when there are huge differences between the two. That's my suggestion.

Warm regards, Helixsoft (Talk|Contributions|Templates|Userboxes) 15:20, 22 January 2014 (UTC).

Hi. Joel Spolsky once wrote that it is only on TV that two quarreling kids are subdued by shouting louder than either of them. In real world, such an attempt would turn into a three-way quarrel. He says such was the case when someone tried to resolve the conflict between the incompatible RSS versions with an Atom specification.
We have two infoboxes already. A third won't fix a problem. It only adds to the problem. A merge is out of question at the moment but something close will eventually happen, either by me or someone more experienced than me, or someone who just finds the delicate spot of compromise. When I was replying to the other user, I needed to snap him out of his daydreaming of bliss. The guest editor had assumed so much about the end result that was already making edit requests on the future template!
Best regards,
Codename Lisa (talk) 15:52, 22 January 2014 (UTC)

date parameter?[edit]

A user edited OS X Mavericks, saying "|date=June 2013" deleted from Infobox. Not sure what it is (doesn't display))", although they didn't actually remove that in the edit.

As a test, I tried changing the date parameter's value to "hello sailor" and previewing the article; it showed the article as being in the redlinked category "Articles with unsourced statements from hello sailor".

I then removed the "date=" parameter; the AnomieBOT put it back, with a value of March 2014.

Does a date=XXX parameter add the article to the category "Articles with unsourced statements from XXX"? Are some of the "Articles with unsourced statements from XXX" categories hidden, so that they don't show up?

Where, if anywhere, is that parameter documented? Guy Harris (talk) 20:13, 4 March 2014 (UTC)

Hi. Just checked the source code for your question. Unlike several other infoboxes, {{Infobox OS version}} does implement an actual |date= parameter. You see this infobox implements |first_release_url=, |GA_url=, |release_url= and |preview_url=; if they are empty, the infobox inserts a {{Citation needed}} in their places and passes the |date= parameter to {{Citation needed}}, which needs a date.
Best regards,
Codename Lisa (talk) 06:53, 5 March 2014 (UTC)


What does "userland" mean in the context of this template? The User space article it references doesn't shed any light on the subject, and the documentation for this temaplate doesn't explain the parameters with any vigor. -- Mikeblas (talk) 03:01, 26 March 2014 (UTC)

Hi. This is one of the inventions of the Linux folk. In Windows, this field would be equal to Windows Shell. In Linux distros, however, windowing system and a lot of other things tangible to user also into user mode. Plus, articles on Linux distros use this field to say where the bundled apps come from, e.g. GNOME or KDE This is not an issue with Windows, Mac, OS/2 and a lot of others outside Linux distros. (In fact, in Mac, the concept third-party is negligible.
Best regards,
Codename Lisa (talk) 00:29, 27 March 2014 (UTC)
P.S. Guess what? There is a |ui= too. Very confusing. Best regards, Codename Lisa (talk) 00:31, 27 March 2014 (UTC)
I would not say that Linux articles use this field to say GNOME or KDE. The userland encompasses much more than the GUI. The "ui" field is clearly for GNOME or KDE, while the userland field is typically either "BSD" or "GNU" indicating the family membership of all the application-level utilities such as ls, rm, mv and others. Elizium23 (talk) 01:03, 27 March 2014 (UTC)
The problem is that UI is not outside userland. Besides, KDE or GNOME aren't UI elements only. GNOME Character Map or Kate are apps after all. Best regards, Codename Lisa (talk) 01:12, 27 March 2014 (UTC)
Indeed, "userland" implies a particular architecture; and the shell is the shell -- it's only a part of what some call "userland". POint is, there's zero documentation for the parameter's intention here and therefore weak understanding of it; it's based on a colloquial phrase and therefore not broadly agreed-upon, and it suffers from inconsistent application throughout the corpus. Seems like it should be clarified or deleted. -- Mikeblas (talk) 15:14, 5 April 2014 (UTC)
"Userland" is a very strange-seeming parameter. I would suggest renaming it to "Significant user mode components" -- i.e. "of the major functions of this operating system, which are implemented outside of kernel mode or ring 0?" Jeh (talk) 00:40, 10 July 2014 (UTC)
I'm having a discussion about Unix - operating systems. Some seems to view Unix as only kernel space (APIs). OSes clearly include (some part of) userland also - User interfaces (at least one) - for Unix eg. the CLI. I wander what components should be included in modern usage of the term OS and "Significant user mode components" - eg. a sound-subsystem is not critical - but still part of the OS (not just inputand/UI)? And when OSes would not be considered the "same" anymore (when sound-subsystem is changed? graphics/replaced by surfaceflinger?).. comp.arch (talk) 16:07, 21 July 2014 (UTC)
As I gather, "userland" is here for articles about Debian GNU/kFreeBSD and alike. At least it is too ambiguous outside this scope. — Dmitrij D. Czarkoff (talktrack) 16:27, 21 July 2014 (UTC)
Now that @Czarkoff: mention it, would you say one of the options for userland should be Android? I disagree personally with calling Android Unix-like (as a family), but while that is how WP describes it would Fire OS and Android be "Unix-like"/Android? (family/userland)? Android doesn't have GNU by design? And Bionic is not BSD (a fork)? And Dalvik (for now..) and more as a whole is "Android's" userland? comp.arch (talk) 20:54, 21 July 2014 (UTC)
Android has several layers of userland:
  • BSD userland (bionic is fork of NetBSD's libc, and multiple NetBSD utilities are included);
  • Android-specific utilities (adb and friends, custom frameworks, etc.);
  • Dalvik;
  • UI goo;
  • Standard applications (clock widget, alarm, browser, etc.);
Enumerating all of this in infobox is plain silly, so |userland= parameter for Android just should be left alone. FWIW same is true for any GNU/Linux distro. — Dmitrij D. Czarkoff (talktrack) 21:32, 21 July 2014 (UTC)

Add frequently updated[edit]

Hi please add support for frequently updated. (talk) 22:44, 26 March 2014 (UTC)

Over my dead body! And over Jimbo Wales's dead body too: This parameter would be a recipe for a disaster called eternal state of sourcelessness, eternal undue weight, associated edit wars and version number vandalism. No! Let the sleeping devil lie! Hell, don't create the sleeping devil.
Best regards, Codename Lisa (talk) 03:25, 27 March 2014 (UTC)

Do users really need to see "Initial release" date above other relevant information?[edit]

My edit summary: "(Not rocket science.) Moved "Initial release" down (below Latest and Preview). It's annoying to have to read past the Initial release every time it's present, when it's NEVER the first date I'm looking for."
(Here's the change, though diff does not show how simple it actually is (cut, move, paste; adjust the numbers).)

00:03:57 later: "Reverted 1 edit by A876 (talk): BRD revert. It is your own fault for using Wikipedia for discovering release dates. Wikipedia mission is different." (user:Codename Lisa)

"BRD", as in "BOLD, Revert, Discuss". Okay, let's.

I kind-of expected a frightened panic-button revert on a Template edit. (Change is scary. Acceptance is too unlikely to be true.) But I could not anticipate the exact "reasoning" that would be used. I never expected such vengeful thuggishness. What lowlife scum I must be, to use Wikipedia for something that [you presume] I want to use it for. Why, I'm desecrating the Mission of sacred Wikipedia (which surely is NOT accommodating lowlife scum such as me). The fact that I am irked occasionally by seeing the least-useful information first - why, I deserve that suffering and much much more. I should even be made immortal, so that I can suffer the deserved pain of seeing my own ugly selfishness, forever.

Wikipedia and this template are very old! If any meaningful change was required, why, surely it would have already been made by the Geniuses that be. (I expected an argument like this, but didn't get it. However, it is implicit.) There is a threshold for annoyance - small errors often are not annoying enough to provoke an edit. By recurrence, this little objection finally reached my annoyance threshold and I acted. This reversion will drive up my threshold for testing changes - it's harder to do anything knowing in advance that it will be casually smacked down. Will it please the Powers when I cease attempting such vile disruption? Or will they feel unsatisfied when they don't get to smite the blasphemer as often?

I committed the atrocity of writing my comment in the first person! Why, correcting something that occasionally annoys me makes Wikipedia more useful ONLY FOR ME, and couldn't possibly make it less annoying or more useful for other users.

If anyone reads an article about an operating system or other software product, WHY is the AGE of its first release more important to them than whether it is maintained and updated? For Jimbo's sake, give someone a chance at common sense. If I'm not supposed to "[use] Wikipedia for discovering a release [date]", then why not get rid of the Infobox altogether? It seems like pure reactionary bigotry: undo any change you see, and make up any insulting surrealistic justification you like. (After reading the editor's history and talk pages to see what they deserve). Bold, Revert, Intimidate. Bold, Revert, let Die in committee.

To the unlikely person who ever comes across this suggestion on this Talk page, please consider the idea on its own merits, agree or disagree, and let the bureaucracy continue preventing anything helpful from happening. -A876 (talk) 00:42, 31 May 2014 (UTC)

Weird, I was pretty sure that it was me who reverted your edit. Two reasons:
1. It is already absolutely trivial to identify right dates, and your change improves nothing in this regard.
2. Infobox contents are logically arranged, with dates coming consequentially. Your edit breaks this for nothing.
As you may notice, your little selfish theory has nothing to do with reality. — Dmitrij D. Czarkoff (talktrack) 06:42, 31 May 2014 (UTC)
Initial release date should come first for the same reason that birth dates come before death dates: It forms a range, a period of time. It is also compatible with the flow of article's prose.
Try assuming good faith and commenting on the contribution only; you'll be surprised to see how lovely people are about it. (talk) 09:15, 31 May 2014 (UTC)
So Dmitrij D. Czarkoff is also Codename Lisa? How sweet, but isn't there a stern rule about this? Or are you not technically a sock puppet if you only share a soul but not a body?
1. It improved something. Start date is sometimes present, sometimes not.
2. Oh, I see, my edit destroys Logic. Obviously I knew I was taking the dates out of sainted Chronological order. Current - Future - Past is also a sensible order for things. It's not like no thought went into this.
3. The added unsubstantiated insult ("your little selfish [hypothesis]") only confirms.
Yup, birth–death. I can't argue against that. "Abraham Lincoln (February 12, 1809 – April 15, 1865)." Now that is a format where it is "absolutely trivial to identify right dates". But chronological order in an article can get burdensome – for weak unchecked example, must the Windows article always begin with Windows 1.0? Few are really looking for thatinformation, so it is pushed aside.
I did not make the first personal attack. B-R-D does NOT prescribe reverting, so it is no excuse ("It is not the intention of this page to encourage reverting.") – so why cite it? Thus a real reason is required. The vindictive edit-excuse provided is no explanation. The most relevant advice for any edit seems to be write for the enemy. Anticipate every shallow, unconsidered reaction that will come up when the other editor does not assume good faith, but assumes my idiocy, and assumes that their shallow, unconsidered reaction is a complete answer and definitive, when they really just didn't like something. I would like to "comment on the contribution", but it is still hard to see an Undo as a "contribution". It is a de-contribution, a reversion, whose only substance is the edit-excuse provided. Editing quiet pages is like playing White in chess. Returning to subject:
Do users really need to see "Initial release" date above other relevant dates? -A876 (talk) 04:29, 1 June 2014 (UTC)
What a joy!
1. You have three editors saying that users really need to see "Initial release" date above other relevant dates. What makes you think that asking another time would help pushing your side?
2. BRD, and particularly R in it, does prescribe reverting. Seeing someone damaging templates for no apparent reason even more so.
3. Yes, Windows article must begin with Windows 1.0, and Microsoft article must not begin with Windows. We are working on encyclopedia here, not the yellow pages of internet.
4. I am not Codename Lisa. If in doubt, please proceed to WP:SPI.
5. "your little selfish theory" is not an insult – it is accurate neutral summary of your comment. And of your second comment as well. If in doubt, please proceed to WP:ANI.
6. There is no evidence that anybody assumed idiocity on your side. At least I did not, despite your attempts to make me doing so.
Being pointy and accusing others is not helpful even when you are right, which obviously is not the case here. — Dmitrij D. Czarkoff (talktrack) 07:26, 1 June 2014 (UTC)
1. Three editors did not say exactly that. If they thought about it, they would not say it. ("Need", indeed.) Don't put words into their mouths. Codename Lisa undid my evil, selfish repurposing of Wikipedia. (abrasive) You said I broke logic (unlikely) and "improved nothing". (so?) said "Initial release date should come first for the same reason that birth dates come before death dates..." (insufficient, irrelevant.) (Always knee-jerk; zombie-logic; status-quo; no one else ever had a point.) I sometimes run my life by the numbers - as they say, if TEN people say I'm drunk, I'll probably go sleep it off. (It's surprising, though, how many people will stand up to prevent correction of a blatant wrong (in other places), as if status quo is the only Truth.)
2. BRD is NOT carte blanche to automatically revert every change; it says so. It even links to Wikipedia:Revert only when necessary. I found some interesting notions there: "Don't revert an edit because it is unnecessary — because it does not improve the article." "Whenever you believe that the author of an edit was simply misinformed, or didn't think an edit through, go ahead and revert." (that must be me, eh?) "Reverting [of itself] tends to be hostile..." "No edit, reversion or not, should be made for the purpose of teaching another editor a lesson or keeping an editor from enjoying the fruits of his crimes." (See?) My favorite: "When reverting, be specific about your reasons in the edit summary..." (i.e., just say you don't like it, ha ha.) Templates are watched a little more closely, but does that justify a prior reversion comment like this one (not applied to me): "This user is too careless. I will not risk having these changes without someone having vetted it first." (WOW!) — (followed by not vetting anything)? It can get a little high-tech with all this coding and extended reach — but I don't expect guideline pages on editing Templates any time soon.
3. Abraham Lincoln article does NOT begin with his boyhood - the intro jumps straight to his presidency. Infobox can be seen as another intro - it certainly is NOT the [chronological] article body; it's another summary.
4. Fact: Codename Lisa reverted my edit. Somehow you said "Weird [my new nickname?], I was pretty sure that it was me who reverted your edit." (In case you wondered where I got the idea that you were Codename Lisa - that statement says so.) And then you went on to state reasons why [you or she] did what [you or she] did! (Whatever. I agree you are not Codename Lisa.)
5. No need for Mom and Dad. Somehow I found myself smacked down. I objected.
6. I had a point. Sometimes it looks like people just don't try.

Moving screenshot to the bottom?[edit]


I am writing to inquire about edit #614639082 by Technical 13 which moves the screenshot of the OS to the bottom.

Both the edit and its edit summary ("stacking the two images looks horrible") surprised me. For one thing, editors go through a lot of efforts to make sure the logo and the screenshot look good and artistic together. For another, most infoboxes including {{Infobox}}, {{infobox software}}, {{infobox web browser}}, {{infobox OS version}}, {{infobox OS component}}, {{infobox video game}} and others (I am sure there are others) show the screenshot at the top. Why must this one deviate from that consistent format? Oh, and non-free images are often uploaded with the rationale of helping to identify the subject of the article and deliberately putting them where scroll bars hide them isn't exactly conducive to that objective.

Overall, my thought was that we should act on this one exactly as we are encouraged to edit, when it comes to templates: Radical changes need discussion first.

Best regards,
Codename Lisa (talk) 06:33, 28 June 2014 (UTC)

I am all for keeping screenshot in upper part of infobox simply because it provides valuable graphical clue about the subject of the article. Unlike illustration in the article's body, which are there to illustrate the particular aspects of the software, this one serves the same purpose as lead section, and its content and placement should follow the same rules. — Dmitrij D. Czarkoff (talktrack) 09:07, 28 June 2014 (UTC)
  • @Lisa, Dmitrij: {{Infobox OS}} was brought to my attention by Wikipedia:Teahouse/Questions#Infobox Problem where I found this version of VxWorks where the stacking of the two boxes on top of each other looked bad and just didn't flow making it hard to gain anything from either of the images. Rob had created two separate infoboxes for the sole purpose of adding some kind of space in between the two images. I consolidated the infoboxes into one template (as it should be) and then modified the infobox template to address the root issue of the two images looking bad without some kind of separation in between them. I'm not opposed to it being near the top, but there needs to be at least "some" information in between them because I find there is a loss of perception exactly where one image ends and the next starts and only a line or more of content (context) is going to fix that. — {{U|Technical 13}} (etc) 11:23, 28 June 2014 (UTC)
  • Hello, Technical 13. Before I start, you need to double-check your diff links. (Holocaust?) Now, small problem requires small tools. VxWorks deviated from the standard 64px size for rectangular logos. At 64px, the image looks okay. Wide logo size is only provisioned for logos with wordmarks.
Best regards,
Codename Lisa (talk) 01:14, 29 June 2014 (UTC)
  • Lisa, are you saying we should force |logo_size = {{#if:{{{screenshot|}}}|64px|{{{logo_size|64px}}}}}? I'd be okay with that, but otherwise I expect there are other infoboxes out there that "deviate" from the standard (where is that documented with a warning saying using other sizes is bad, I may have missed it) size for logos ("it should fill the width of the box, of course"). — {{U|Technical 13}} (etc) 02:18, 29 June 2014 (UTC)
  • No. I am definitely not saying that. All I am saying is that red attracts the most attention, grey on white attracts the least attention, such a big logo and such a small screenshot back there were not optimal combinations. Like I said, editors spend time making sure the article looks good. VxWorks editors hadn't. 64px is not a policy; it is a discovery.
Best regards,
Codename Lisa (talk) 02:24, 29 June 2014 (UTC)
FWIW I am all for limiting height of logo in infobox, although to my knowledge we only control width... — Dmitrij D. Czarkoff (talktrack) 07:46, 29 June 2014 (UTC)
One single case is not enough to warrant this change. In this case, the problem is Robpater himself. A chain of his edits has concerned me: e.g. he changed back IA-32 to x86 despite I having dropped him a note about it and him have promised to go over it. If it transpires that he is a stubborn person, any hard limit that we apply probably drive him to use alternative means of circumvention. On the other hand, his only fault might have been using "Save" button instead of "Preview" button and not getting his priories right. We should wait a bit longer and see how things unfold. I know I have said this at least ten times before but patience is one of the virtues of an encyclopedia writer. Best regards, Codename Lisa (talk) 00:36, 1 July 2014 (UTC)
My comment was based on my experience with multiple pages with huge logos. I have no opinion on Robpater's edits – I didn't look into his edits. — Dmitrij D. Czarkoff (talktrack) 04:39, 1 July 2014 (UTC)
Oh! Very sorry for complete misunderstanding! Well, yes, if a large number of articles are the source of the problem, it is very natural, yes. (And since you are a veteran in the field of templates, your word has double the worth.) If you wish to elaborate, by all means, I am all ears.
Best regards,
Codename Lisa (talk) 13:09, 1 July 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Some changes to Module:InfoboxImage are required to implement my idea. Currently they are pending approval. — Dmitrij D. Czarkoff (talktrack) 21:48, 1 July 2014 (UTC)

True. But before I can agree or disagree, I have to a sample of problem articles and know the hard limit you have in mind. Best regards, Codename Lisa (talk) 01:19, 2 July 2014 (UTC)
I didn't think about any particular hard limit value, and frankly I would prefer to delegate this aspect to editors with better design skills and visual taste then I have. For the testing purposes I implemented 250px vertical limit in this template's sandbox, which is probably too small to be practical. I also implemented hard limit of 800×800 px in corresponding Lua module's sandbox, which is rediculously high and is basically only needed to simplify code. I would appreciate your thoughts on these digits.
Regarding samples: I normally shrink oversized logos on spot. We could temorarily add tracking categories to this template to get a grasp of sizes people manualy specify. Or, alternatively, I could build a script to query all articles with this template and publish a short report. — Dmitrij D. Czarkoff (talktrack) 11:46, 2 July 2014 (UTC)

Completing Infobox_OS_version merge[edit]

Per Wikipedia:Templates for discussion/Log/2013 August 24#Template:Infobox OS_version, I have added fields to support Infobox_OS_version. The new fields do not affect current Infobox_OS articles. The merge has been delayed long enough. -- Netoholic @ 23:17, 9 July 2014 (UTC)

I very dislike the "merged" version of this template:
  1. Putting operating system family on top of the template is appropriate for OS version articles, but is completely inappropriate for articles about operating systems.
  2. With a separate Releases "group" the "Preceded by" and "Succeeded by" look very much out of place.
  3. The ugly plainlinks in Releases.
  4. |released= may be specified alongside the Release dates-related mess from {{infobox OS version}}, and is shown in different location.
These are the most outstanding issues, and they should be fixed before the production version of this template is updated. — Dmitrij D. Czarkoff (talktrack) 23:21, 9 July 2014 (UTC)
Feel free to fix or correct it as much as you like, as long as you preserve the parameters unique to Infobox_OS_version. I am not here to dictate how the infobox should look, only to complete a very, very long overdue merge backlog decided by consensus. In practice, the OS_version articles look just fine converted to the OS template. --Netoholic @ 23:25, 9 July 2014 (UTC)
Hello, old timer
I'd like to re-iterate what I said in your talk page: The consensus was to merge, not to mutilate. Your switch misfiles many parameters, especially those related to WP:V. While I appreciate undertaking a long-overdue endeavor, I do not appreciate creating problems that didn't exist before.
Best regards,
Codename Lisa (talk) 23:32, 9 July 2014 (UTC)
I extensively tested on the sandbox and left the edit on the main template for about half-a-day before I began the article conversion work. This is a required merge, and any problems with the new version must be addressed by going forward by including the OS_version parameters, not backward, and definitely not stagnant as it has been for approaching a full year. Today is the day. --Netoholic @ 23:36, 9 July 2014 (UTC)
@Netoholic: FWIW keeping all the parameters of both infoboxes is harmful. The merge does not excuse from necessity to keep this template consistent. — Dmitrij D. Czarkoff (talktrack) 23:45, 9 July 2014 (UTC)
(edit conflict)Although I sympathize with your high spirit of no more procrastination, I do believe that patience is one of the virtues of a a Wikipedian. The reason this task was delayed was because everybody knew that it would be time-taking and arduous, so much so that no one dared starting it. There is no deadlines in Wikipedia and there is no excuse for faking completion of long overdue task.
Do not misfile information. That's all we ask.
Best regards,
Codename Lisa (talk) 23:49, 9 July 2014 (UTC)

@Czarkoff:,@Codename Lisa:: I will give editors a day to implement a version which both implements the Infobox_OS_version parameters and addresses any specific concerns raised above (re: layout, etc.). If no version is live, I will re-implement mine and continue the article work. If editors here continue to act in violation of the consensus decision after that time, I will escalate. There is simply no option to continue to pushback efforts to implement a near-unanimous decision on TFD. -- Netoholic @ 23:53, 9 July 2014 (UTC)

Then You should escalate right now, because I see this ultimatum as inappropriate action, as well as the way you enforce the merge, and the way you remove comments as well BTW. — Dmitrij D. Czarkoff (talktrack) 00:00, 10 July 2014 (UTC)
(edit conflict) Now, now. Are you threatening me? By all means do escalate; the sooner the damaging, disruptive and non-collegial nature of your work comes to light, the better. I on the other hand, advise you to stop commenting on the contributors and begin working your differences of opinion with us.
Concerned, Codename Lisa (talk) 00:06, 10 July 2014 (UTC)
I agree with Codename Lisa: By all means, escalate. Your "consensus" to merge two templates and force all uses of one to switch to the other is not binding on the community at large. Did you, prior to any discussion, notify maintainers of the articles that use the template you want to delete? Any notices on those articles' talk pages? Not that I ever saw. Your subsequent editing of articles that use the template you want to delete, with edit summaries and talk page comments that apparently are completely unallowing of any compromise (~"it's been decided behind your backs, deal with it") is at best disruptive and... well, "non-collegial" is about the most polite way to put it. Please stop. Jeh (talk) 00:24, 10 July 2014 (UTC)
@Jeh: actually, I'm just a worker-bee trying to clear up a backlog from WP:TFD. The decision to merge was made at Wikipedia:Templates for discussion/Log/2013 August 24#Template:Infobox OS version almost a year ago. I don't have an opinion one way or the other about specifics, I'm just trying to move it along. --Netoholic @ 00:37, 10 July 2014 (UTC)
I do not agree that any "decision to merge" that was made (however long ago; that's irrelevant) without notifying maintainers of articles that use the template is binding on anybody outside of your little beehive. If you want something that is defensible as a community-wide consensus, then you had better have involved the community long prior to the decision. I don't see that that happened.
Your recent conduct and phraseology do not suggest a mere "worker-bee", but rather someone who is rather strenuously trying to push an agenda. I personally would have said "you know, the many users of Template:Infobox OS version seem singularly uninterested in switching over. Maybe they don't even know about this new thing? Maybe we should bring this up on the talk pages of the articles that use it?"
And the conclusion after that effort might well be "Huh, they really don't like the merged template. I guess we'll have to keep both." You have to remain open to that. Template creators and maintainers don't run this place.
Don't expect that you can do what you recently did without pushback. And saying "there is no option for pushback" under such circumstances is just pouring gasoline on the fire. Jeh (talk) 01:00, 10 July 2014 (UTC)


Hello everyone

I propose the merger should occurs on the basis of {{Infobox OS}}, because it is implemented on more articles and changing its layout to {{Infobox OS version}}'s layout is more likely to be contested. If you think the other layout is a better idea that will be lauded, I suggest we complete the merger first, then do the layout with a separate bold edit. Therefore, the following changes must occur in {{Infobox OS}}:

  1. These parameters added: |RTM_date=, |support_status=, |other_articles=
  2. |GA_date= should be added as an alias for |released=
  3. These parameters renamed in the article space to those of {{Infobox OS}} equivalents:
    • |first_release_date=|RTM_date=
    • |release_version=|latest release version=
    • |release_date=|latest release date=
    • |preview_version=|latest preview version=
    • |preview_date=|latest preview date=
    • |human language=|language=
  4. These parameters discontinued:
    • |first_release_url=: Merge implementations with |first_release_date= and convert to {{cite web}}
    • |GA_url=: Merge implementations with |GA_date= and convert to {{cite web}}
    • |release_url=: Merge implementations with |release_date= and convert to {{cite web}}
    • |preview_url=: Merge implementations with |preview_date= and convert to {{cite web}}
    • |date=: Disregard
  5. Special provisions added for |Discontinued=: This parameter must be disregarded when |family= is set. The word "discontinued" is never used for a single version because all development efforts on a version of program ceases when it is released to manufacturing; any patch released consists development on a later version. (For support status, we have another parameter.) We could do it the other way, but this way is more fool-proof, so to speak.
  6. Special provisions added for |Discontinued=: This parameter must be disregarded when |succeeded by= is set. The word "discontinued" is never used for a single version because all development efforts on a version of program ceases when it is released to manufacturing; any patch released consists development on a later version. (For support status, we have another parameter.)

Best regards, Codename Lisa (talk) 00:31, 10 July 2014 (UTC)

|family= and |source model= already exist. --Netoholic @ 00:47, 10 July 2014 (UTC)
  • Question |Discontinued= has no documentation, is that a simple discontinued = yes flag? Can you give an example of an article with one? --Netoholic @ 00:55, 10 July 2014 (UTC) Striking question. This |Discontinued= seems to only to be in Infobox_OS, not Infobox_OS_version, and |succeeded by= exists in both already, so this is unrelated to the merge itself (its a question for future maintenance). --Netoholic @ 01:01, 10 July 2014 (UTC)
  • We already have |family= here, and it is used in different meaning – in {{infobox OS version}} it basically means "operating system this is version of" (see template:infobox OS version/doc#Example), which has nothing to do with OS family. More appropriate name should be chosen, eg. "series". — Dmitrij D. Czarkoff (talktrack) 01:06, 10 July 2014 (UTC)
    • How is it used here differently, and why can't we use the same (existing) parameter and field for both meanings? --Netoholic @ 01:48, 10 July 2014 (UTC)
Actually, it is related; the merge now enables incorrect activation of a flag on articles that previously didn't suffer. The fact that the articles using {{Infobox OS}} didn't suffer from this issue is just a merry coincident, caused mainly by the consequences of WP:GNG. However, we are about to take an action that can potentially open an avenue of mischief. So, provisions to prevent it, is our responsibility. Best regards, Codename Lisa (talk) 01:58, 10 July 2014 (UTC)
  • FWIW I would propose to avoid adding aliases to this template. I'd rather turn template:infobox OS version into a wrapper and collect its native syntax uses into maintenance category. This will create a backlog of ~70 articles, which could be timely ported to the syntax of this template. — Dmitrij D. Czarkoff (talktrack) 01:06, 10 July 2014 (UTC)
    • You don't need a wrapper or a maintenance category. Part of my task is to actually complete the migration once Infobox_OS has all the right changes to accomodate, not leave it to languish for someone else. --Netoholic @ 01:12, 10 July 2014 (UTC)
"Family" is an inherently vague word; it is just a loose metaphor. As any attempt to invoke a definition for it constitutes original research. But we can add a |version of= with the same function as that of "family" in {{Infobox OS version}} that also disables |family=. How is that? Codename Lisa (talk) 01:58, 10 July 2014 (UTC)
Family is not the only problem here. {{infobox OS version}} has many alternative parameters, most undocumented; this template has many duplicates already. Introduction of this many new parameters will make it barely readable and will eat unreasonable amount of processing resources. Keep in mind, that this infobox provides both underscored and spaced syntax, while {{infobox OS version}} only has underscored parameters, so basically we'll have to introduce two new parameters for each missing from {{infobox OS version}}. We'll definitely loose some on the way – at least those URL things.
That is: the end result will be incompatible with {{infobox OS version}} enough to make wrapping unavoidable. Why not drop quirky syntax that won't sit well here anyway? — Dmitrij D. Czarkoff (talktrack) 02:13, 10 July 2014 (UTC)
Alternate parameter problems have two very simple causes: The template supports spaced parameters (it shouldn't have in the first place), and the template documentation itself is inconsistent, using some spaced and some not. A simple bot run can eliminate the old, inappropriate parameters, but for today, we'll have to leave them in and support them. What's most important is to know the most preferred parameters names, and update the documentation to be 100% correct and current. --Netoholic @ 03:06, 10 July 2014 (UTC)
Why do we have to support them? — Dmitrij D. Czarkoff (talktrack) 06:20, 10 July 2014 (UTC)
Because this is a merge. After the articles are all converted, then someone can lead a separate project to standardize the parameters. --Netoholic @ 06:40, 10 July 2014 (UTC)
This is a harmful way, IMO. The wrapper would harm this template less, and I see no reason to believe that the damage is really required. Also, as stated above, these template's syntax is incompatible, so your way of merging is impossible at all. — Dmitrij D. Czarkoff (talktrack) 10:01, 10 July 2014 (UTC)
  • Question - are {{{RTM_date}}} and {{{GA_date}}} the more preferable default names for their respective fields (replacing first_release_date and release_date, etc.? --Netoholic @ 01:13, 10 July 2014 (UTC)
Hi. Actually, collision of the application domain was my main concern. When you hear "release date", does it mean "release to manufacturing" or "general availability"? This distinction decides what we do.
Best regards,
Codename Lisa (talk) 01:27, 10 July 2014 (UTC)
Definitely GA date. Software is released to customers, not to CD fabs. — Dmitrij D. Czarkoff (talktrack) 02:15, 10 July 2014 (UTC)
FWIW I would drop RTM altogether – it is unapplicable to articles about operating systems, and OS version articles discuss these dates in prose anyway. In the end, RTM is not even user-visible process stage. — Dmitrij D. Czarkoff (talktrack) 02:21, 10 July 2014 (UTC)
A very strong consensus through editing is formed in favor them. We had a widespread misuse of |release= tag when people added both dates of Windows version to it and microformat broke. (I used to revert them but they were so recurrent that Dogmaticeclectic to filed an edit warring case against me. Of course, it was finally decided that I wasn't doing edit warring; but I was took the cue and separated the fields.) It stopped when I finally added those dates. So, as you can see, we definitely need them.
As for your other concern, I fully agree with you that we do not need alias proliferation. That is why article 3 of my proposal suggests renaming implementations instead of adding them.
Best regards,
Codename Lisa (talk) 19:36, 10 July 2014 (UTC)

@Codename Lisa:/@Czarkoff:: I've completed the requests for the template and the changes can be seen on Template:Infobox OS/testcases#Merge OS version along with a corrected list of the most preferred parameter names (old ones are still supported). Please take a look, and let me know if there are any major concerns before I continue with the merge. -- Netoholic @ 09:29, 10 July 2014 (UTC)

"General availability" works for Windows, MacOS and Android (the users of {{infobox OS version}}), but it does not work with other operating systems. For example, initial release of Plan 9 from Bell Labs was only available to select customers, and first release in general availability was "Second release", which came years later.
I also strongly oppose moving rather significant release information to the bottom, and I don't see any need in child infobox, which effectively doubles the server load penalty of this template. — Dmitrij D. Czarkoff (talktrack) 11:08, 10 July 2014 (UTC)
I understand. But this isn't something to address in merger stage. Let's be done with it, then we can discuss how best to dispose of them. We already have enough to discuss, you see.
Best regards,
Codename Lisa (talk) 19:36, 10 July 2014 (UTC)


I updated template:infobox OS/sandbox and template:infobox OS version/sandbox, and the results can be seen at template:infobox OS version/testcases. I ported as many parameters as I could (actually, per suggestions by Codename Lisa), though I believe that "Release to manufacturing" and "Further reading" should be dropped. The rest of the merge process appears to be the following:

  1. Update all articles using {{infobox OS version}} to use {{infobox OS}} directly.
  2. Change {{infobox OS version}} to output error in case of using old syntax.
  3. After a grace period (eg. 1 month) redirect template:infobox OS version to template:infobox OS and consider merge complete.

If this option gains support, I will agree to be held accountable for the whole process. I will also manually convert all references from plainlink fields of {{infobox OS version}} into proper references in articles' native citation formats. — Dmitrij D. Czarkoff (talktrack) 12:36, 10 July 2014 (UTC)

  • Issue: There is no reason at all to make Infobox_OS_version into a wrapper. You can see from the testcases that the release_url information goes missing anyway. Articles will be directly changed from Infobox_OS_version to an updated Infobox_OS, so no articles will ever use such a wrapper and there is no need for a grace period as OS_version will have been completely orphaned. After the articles are converted, Infobox_OS_version can be immediately redirected - merge complete. --Netoholic @ 18:08, 10 July 2014 (UTC)
    • Again, there are |family= parameters in both infoboxes used in different meanings. — Dmitrij D. Czarkoff (talktrack) 19:01, 10 July 2014 (UTC)
      • I don't see what that has to do anything. During the conversion, change OS_version |family= into |version_of= and its done. --Netoholic @ 19:07, 10 July 2014 (UTC)
        • Sure. And this is the same for all other parameters as well. The syntax of {{infobox OS version}} will not survive, so there is no reason to break consistency of this template. — Dmitrij D. Czarkoff (talktrack) 19:17, 10 July 2014 (UTC)
          • Yes. I'll update the main OS template and also the documentation to reflect the most preferred and consistent parameters. Then as I (we) go through the old OS_version articles, the OS parameters will replace the OS_version ones. --Netoholic @ 20:00, 10 July 2014 (UTC)
  • Issue: Far too many parameters in Infobox_OS don't look anything like their row labels, nor are they consistent/predicable. There is no point in introducing a GA_date field if the row label isn't going to say General availability. I'd suggest calling it just |release_date=. During the article conversion, you're switching parameters to their most preferred OS_version equivalents anyway, so no need to support something that didn't exist before in Infobox_OS_version. --Netoholic @ 18:08, 10 July 2014 (UTC)
    • This template supported both spaced and underscored versions. I see no reason to break this. — Dmitrij D. Czarkoff (talktrack) 19:17, 10 July 2014 (UTC)
      • It will support both. --Netoholic @ 20:00, 10 July 2014 (UTC)
        • Then please make sure it does say "general availability". We are merging, not deleting parameters. We must have a set of |RTM_date=/|GA_date= that override |release_date= or an equivalent alternative. As I said earlier, there has been a whole conundrum leading to the creation of RTM date and GA date fields. This isn't something to let go just because of fancy.
          Best regards,
          Codename Lisa (talk) 20:15, 10 July 2014 (UTC)
          • You know, I wanted to merge yesterday, and the version you guys reverted would have done that perfectly. Discuss it after the merge, as I still don't see a consensus on the right label to use (General availability vs Initial release). -- Netoholic @ 20:31, 10 July 2014 (UTC)
            • Yes, thanks for your good idea yesterday. I assure you, this great idea wasn't the reason for which I reverted. Misfiling existing fields was. Best regards, Codename Lisa (talk) 20:36, 10 July 2014 (UTC)
  • Issue: Separating all the release information under a single header is far better than throwing arbitrary information onto the screen in what looks, to me, like a random order. People have complained on this talk page about the presentation, so putting similar information under headers is desirable. This is a merge, so some ideas from Infobox_OS_version should be incorporated, and headers are a very good one. --Netoholic @ 18:08, 10 July 2014 (UTC)
    • I strongly disagree on this statement. Frankly, to me everything different in {{infobox OS version}} looks either inferior or completely wrong. I feel particularily strong dislike towards the visual style of that template, and sectioning is another aspect that I believe we should get rid of ASAP. Frankly, I see nothing in {{infobox OS version}} that would be an improvement over current {{Infobox OS}}. — Dmitrij D. Czarkoff (talktrack) 19:17, 10 July 2014 (UTC)
      • Seconding this for now. We can discuss this after a merge. Best regards, Codename Lisa (talk) 20:16, 10 July 2014 (UTC)
        • Preserving the existing headers of OS_version so as not to shock anyone watching those pages today. Post-merge, the subject can be discussed. --Netoholic @ 20:31, 10 July 2014 (UTC)
          • It will definitely be a change for 800 other article who hadn't seen it. So, no. We only have the go-ahead for merging OS version into OS, not the other way around. So, I still second Dmitrij's opinion. Best regards, Codename Lisa (talk) 20:36, 10 July 2014 (UTC)
            • Then you should have let me proceed yesterday as that version made NO visual change at all to Infobox_OS articles OR Infobox_OS_version articles. It was a straight merge, and visual discussion could have happened afterward. Now you guys have asked for certain changes, which I have tried to accommodate, but those changes to unify fields are now what you're objecting to. The OS articles now will will see some label changes, some reordering of rows, and a clean, simple header for the "Release information" with release information grouped under it. They will either come here to complain or praise it, in which case we'll get a lot more feedback and change it later, but the reality is we need to move forward with the merge and concerns like this should not be stopping that from happening. --Netoholic @ 21:04, 10 July 2014 (UTC)
              • We need to move forward with merge. If you also want to restructure this infobox or change style, gain consensus first. Right now it is 2 vs. 1 against change of visual style and sectioning. — Dmitrij D. Czarkoff (talktrack) 21:26, 10 July 2014 (UTC)
                • The version I tried to implement yesterday that you guys reverted made no visual changes to either set of articles. I am seriously considering just implementing that again and leave you guys to discuss visual aspects later. Right now, either the OS articles gain a header, or OS_version articles lose their headers - and I'm not comfortable with either direction. -- Netoholic @ 21:44, 10 July 2014 (UTC)
                  • The version from yesterday introduced sections (one, which is better then many but still one more then appropriate), equated operating system to OS family and allowed GA, RTM and "initial release" side by side, all of which are inappropriate. — Dmitrij D. Czarkoff (talktrack) 22:10, 10 July 2014 (UTC)
                    • All of which are easily-done changes to the template that did not require a full revert and complete undoing of the article conversion work I'd already done. -- Netoholic @ 22:23, 10 July 2014 (UTC)
                      • Revert and complete undoing were necessary because the change happened out of process. You really should have given a clear notice and a reasonable timeframe. |family= issue is a good example of a reason to avoid rushing in such cases – your article convertion work would mislead readers instead of helping them. — Dmitrij D. Czarkoff (talktrack) 23:07, 10 July 2014 (UTC)
                        • "out of process"? This merge has been overdue for almost a full year. I came here to help, and have been bitten pretty hard for stepping into this particular walled garden. Now, let's stop with the blaming and get this little project over with. After the merge, you guys can discuss the future of the template as it applies to all OS's. We don't need all the answers today, we just need something good enough that doesn't cause data to be lost. --Netoholic @ 03:01, 11 July 2014 (UTC)
                          • Agree with Dmitri. Out of process: I watch most of the Windows NT-family articles and I never saw any notice that anyone was discussing merging (deleting) a key template, nor any notice after "consensus to merge" was established at TFD. That was not your doing (or your lack of doing), but you compounded it by just disruptively forcing the new template on so many articles (and losing information), again without any prior notification. You compounded this further by stating there was no room at all for pushback. So, yeah, you've been bitten; take a lesson and try to do the next one better. Meanwhile, the amount of disagreement here suggests, if nothing else, that the previous consensus is no longer valid (see consensus can change; it has, after all, been a year). Certainly there is not support for your arbitrarily setting one-day deadlines and issuing ultimatums. "Something good enough that doesn't cause data to be lost" we already have—in the existing templates. The urgency to "get this little project over with" is all in your head. Jeh (talk) 03:36, 11 July 2014 (UTC)
                            • Wikipedia is a big place, sometimes people miss key discussions, but when it was put up for TFD, a notice was placed on the template that appeared on the every OS_version article for 5 days. I can attest, without doubt, that I made sure every article I started converting to Infobox_OS did not lose information. I had every article up side-by-side old and new template before I hit "Save page". My contribs show I converted 12 Windows OS articles in about 45 minutes. That means I gave each one about 4 minutes of time on average. Pretty damn thorough. When I start merging again, I will be equally diligent. Even more-so now that people have requested I change parameters and create cite_web refs to replace bare links. --Netoholic @ 03:48, 11 July 2014 (UTC)
                              • The trouble with that notification is that unless you're watching the template, nothing shows up in your watchlist; it's not the same as putting a notice on the article talk page. So I'm still having a problem with the notion that consensus at TFD is binding on WP at large, requiring us to accept the new template. The dissent here shows that you have no consensus or mandate (and certainly no necessity) to "start merging again". If article maintainers don't want to move away from the old template, they shouldn't have to. Jeh (talk) 04:07, 11 July 2014 (UTC)
                        • You know, the TfD never approved any particular version of merged template. Provided that the template you edit has 825 transclusions, so one may argue that boldly changing this template is unacceptable per se. Even if you disagree, WP:BRD defines due process: if you were reverted, discuss to reach consensus. — Dmitrij D. Czarkoff (talktrack) 14:22, 11 July 2014 (UTC)
  • Comment I probably agree about removing "Further reading" - it doesn't seem like a very good use for the infobox, better as an article section. During article conversion, I'll look at how that is being used on each article and if needed we'll remove or change it. --Netoholic @ 20:31, 10 July 2014 (UTC)
    • This isn't something you can disagree with. It is created in attempt to curtail the creation of separate mini-navboxes. You need obtain addition consensus for misfiling it. Best regards, Codename Lisa (talk) 20:36, 10 July 2014 (UTC)

Straight merge[edit]

I merged all parameters of {{infobox OS version}} into sandbox of this template. Apart from |family= vs. |version of= issue this template will safely replace {{infobox OS version}} without loosing any data at all. The inconsistency between RTM and GA on one side and "initial release" on the other side is dealt by hiding "initial release" if either |RTM date= or |GA date= is used. This template may be installed without disrupting 825 articles that are already using it.

@Codename Lisa, Jeh, Netoholic: Comments? Quesions? Issues?

P.S.: Netoholic, please don't edit production, sandbox and testcases before all participants have responded. — Dmitrij D. Czarkoff (talktrack) 18:02, 11 July 2014 (UTC)

I must apologize but I am having a bad headache right now. It was a busy day both in and out of Wikipedia. I make a full review tomorrow. But you can use this track parameter implementations.
You need to download it and use Excel to view it. But in case you don't have Excel, here is an Online version, courtesy of one of my pals:
Right now, only one issue caught my eye: In this diff, I see you've changed
...which you shouldn't. The {{#if}} tag is there to make sure someone does not provide a name consisting of whitespace characters. We had an experience with this in {{Infobox web browser}}.
Best regards,
Codename Lisa (talk) 19:01, 11 July 2014 (UTC)
I am afraid you are wrong:
Markup Renders as
{{infobox OS|name=   }}
Infobox OS

{{infobox OS
| name =   ↵
Infobox OS
As expected, whitespace is stripped and {{PAGETITLE}} is substituted. Anyway, I don't care much about this particular change – if you think that one more parser function there is not a problem, just go on and change it back. — Dmitrij D. Czarkoff (talktrack) 19:52, 11 July 2014 (UTC)
No, it is me who is wrong. — Dmitrij D. Czarkoff (talktrack) 15:48, 13 July 2014 (UTC)
re Codename Lisa's comment above: I'm sorry too - I am not at all familiar with template syntax and don't have time to come up on it, not in a useful time to work on this. I will look at diffs of results but I can't comment usefully on the code. Jeh (talk) 10:50, 12 July 2014 (UTC)
@Jeh: you can assess results at this template's testcases and testcases of {{infobox OS version}}. — Dmitrij D. Czarkoff (talktrack) 12:25, 12 July 2014 (UTC)
Would it be inappropriate to suggest any other changes at this time? I intensely dislike the "userland" parameter. "User mode" is less OS-specific and more formally accepted. Jeh (talk) 18:22, 12 July 2014 (UTC)
I also have some issues with some parameters. Let's keep them aside until the merge is complete, or we'll never get it done. — Dmitrij D. Czarkoff (talktrack) 21:26, 12 July 2014 (UTC)
Just finished reviewing with Araxis Merger. Your work is excellent. Here is what I can find.
Small issue: You've implemented |version of= in the same place as |family=. The only reason I suggested |version of= was as a compromise to have the text "a version of Windows NT" displayed below the title. If it is not going to be below the title, then we don't need this. |family= would suffice.
Missing parameter: |other_articles= is missing. We can discuss its merits after the merger. Right now, let's just add it.
Best regards,
Codename Lisa (talk) 19:12, 12 July 2014 (UTC)
Totally forgot about |other_articles=; thank you for adding it. I really want to see support status together with |succeded by= and |preceded_by= (logically connected), but this can really be discussed later. I still insist on separate |version of=, because I totally can't accept |family=[[Linux Mint]] or |family=[[Android (operating system)|]]. If it is less controversial moved to top, so be it. — Dmitrij D. Czarkoff (talktrack) 21:26, 12 July 2014 (UTC)
Excellent. Can the transition begin?
Best regards,
Codename Lisa (talk) 09:54, 13 July 2014 (UTC)
I guess so. In template:infobox OS version/sandbox I have a wrapper that passes arguments of {{infobox OS version}} into {{infobox OS}} substituting |family= with |version of= and leaving all other syntax intact. I'll push both sandboxes to production and redirect template talk:infobox OS version here now. I believe that we should pass to discussion of other changes (parameters' names, necessity of fields, etc.) not before the merged version stays live for couple of days. — Dmitrij D. Czarkoff (talktrack) 10:25, 13 July 2014 (UTC)
Wait a second. It think you must move the maintenance category code into {{Infobox OS}} so that the wrapper can be substituted, i.e. I edit every article containing {{Infobox OS version}} and replace it with {{subst:Infobox OS version/sandbox}}. You don't even need to push the wrapper into production area. We can then merge the documentation pages (because they save a lot of rewrite) and delete the entire OS version hoopla. Don't you agree?
Best regards,
Codename Lisa (talk) 10:45, 13 July 2014 (UTC)
@Czarkoff: Should I take your edit as a "yes" and begin immediately? Codename Lisa (talk) 11:23, 13 July 2014 (UTC)
Unfortunately I've seen your comment too late. Actually, I've already pushed the template. And I think we still need this wrapper even after the |family= gets out: the future syntax discussion will require keeping track of other deprecated parameters. If you disagree, please go ahead and implement it your way – I don't have strong preference here. — Dmitrij D. Czarkoff (talktrack) 11:28, 13 July 2014 (UTC)
@Codename Lisa: No, wait! You can't add this category to {{infobox OS}}, because it will categorize the valid use of |family= as well. And we can't delete {{infobox OS version}} per Wikipedia:Copyright policy – it is merged, so we have to retain attribution. Please, don't substitute {{infobox OS version}}! — Dmitrij D. Czarkoff (talktrack) 11:36, 13 July 2014 (UTC) (updated 11:40, 13 July 2014 (UTC))
(edit conflict)
@Czarkoff: Please excuse my abusing the ping system but I think you need to see my last edit in the template. Better abuse ping than sorry, right?
Now, you don't need to worry about the category; you can attach it to |version of= instead. The result is the same. And yes, we won't delete Template:Infobox OS version page; we redirect it. (Earlier instances of "delete" mean "replace implementation".) But the purpose of the merger discussion from the beginning was to eliminate the case of two templates with slightly different syntax being in existence. So, don't worry; the substitution can go ahead without a problem. I still wait for your reply.
Best regards,
Codename Lisa (talk) 11:48, 13 July 2014 (UTC)
No, if we attach it to |version of=, it will capture legitimate uses of |version of= in {{infobox OS version}} (which now has this parameter). Actually, template:infobox OS version is a legitimate redirect to template:infobox OS, so I don't see any necessity of bypassing it. Furthermore, I am still not sure whether this merge version will be there for long – I really intend to start discussion about split them back – and in such case we really should keep the redirect usage where appropriate. — Dmitrij D. Czarkoff (talktrack) 11:57, 13 July 2014 (UTC)
I'm not sure what exactly you are trying to capture and why you are trying to capture it. But please carry on. And please start the split discussion before any other discussion. Best regards, Codename Lisa (talk) 12:02, 13 July 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I am trying to categorize articles that block redirection of {{infobox OS version}} to {{infobox OS}}, namely those using |family= in sense of "operating system" as opposed to "operating system family". I am currently updating documentation of this template to include new parameters. This update is required to make the actual problem with the merge visible. When I will finish that, I'll start the split discussion. — Dmitrij D. Czarkoff (talktrack) 12:24, 13 July 2014 (UTC)

I finished initial run of documentation changes and started split discussion below. I suggest local discussion first, and then probably RFC with more succint wording and polished arguments. I hope that you, Codename Lisa could write the RFC question if/when it is necessary. — Dmitrij D. Czarkoff (talktrack) 15:33, 13 July 2014 (UTC)
Some of these long parameters added to template leave almost no space for the actual values, so I temporarily disabled "white-space: nowrap;" See Windows Fundamentals for Legacy PC and Splashtop for examples. Best regards, Codename Lisa (talk) 12:20, 14 July 2014 (UTC)
I think it would be better to wrap the particular "Released to manufacturing", which was "Released to<br />manufacturing" in {infobox OS version}. Or – even better – forget about it entirely, as it is just plain trivia, definitely not significant enough for infobox by all means. — Dmitrij D. Czarkoff (talktrack) 16:29, 14 July 2014 (UTC)
I think its clear even in just this discussion that people do consider it significant and in my passes of OS_version articles it is referred to often (even though the confusing parameters sometimes placed RTM date information into the "GA" row, something I tried to fix but was reverted). Remember, if its not appropriate for any particular OS, then leave the parameter blank and RTM won't display on the article. No need to make a bunch of articles lose information that is relevant to them just because its not relevant to others. --Netoholic @ 19:15, 14 July 2014 (UTC)
Of 900+ articles using this template it is relevant to about 50 (x86 Windows releases, MacOS releases and OSX releases). At the same time, the possibilities for confusion and misuse are endless. P.S.: Netoholic, could you, please, revert your edit: this redirect opens gates for abuse due to |family= parameter conflict. Not all editors are already familiar with new syntax or know about this merge at all. — Dmitrij D. Czarkoff (talktrack) 21:28, 14 July 2014 (UTC)
If an editor adds the infobox to an article, and they try using "family" and don't get the result they were expecting, they will look up the documentation and fix it. The redirect will point them to the correct merged template name and to the documentation of the syntax. There is no need for a tracking category. -- Netoholic @ 22:16, 14 July 2014 (UTC)
Sure. Unfortunately, editor may not even inspect the result, being sure he knows how to handle {{infobox OS version}}. Or see this edit for example of another potential probelm. — Dmitrij D. Czarkoff (talktrack) 10:03, 16 July 2014 (UTC)
I can sympathize how it feels when you're reverted after making technical improvements. That doesn't mean you stop moving ahead. --Netoholic @ 17:18, 16 July 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── You've missed the point: the editor was acting under strong believe that he knows how to handle {{infobox OS version}} without knowing that it was merged and this parameter now means something it didn't use to mean. That is: he accidentially inserted misinformation to the article (well, not really, because in this case it was |family=Microsoft Windows, which is absolutely OK), just because he was expecting things to be stable. Given that most likely he was never aware of TfD or merge discussion, that is a reasonable expectation, isn't it? That is the only reason I want to see a wrapper in place of {{infobox OS version}}. — Dmitrij D. Czarkoff (talktrack) 19:42, 16 July 2014 (UTC)

All it takes is to inform the editor of the changes. Let him know that these two templates are now one, and that some of the parameters are changed/changing. -- Netoholic @ 20:39, 16 July 2014 (UTC)
You are again missing the point: the problem is not with one particular editor or edit, but with the unknown set of editors. That's why there are grace periods and wrappers. — Dmitrij D. Czarkoff (talktrack) 23:11, 16 July 2014 (UTC)
Does it help to think that I am "missing the point", so you don't have to acknowledge that I disagree with the point? I trust that editors will correct any future mistakes in the parameters, either themselves or the people watching the pages. I have no confidence that any tracking category will actually be monitored by anyone, and highly doubt mistakes last long enough to show up there. Based on the rest of the discussion here, I suspect the real reason for the wrapper is to keep the merge from being fully completed, and eventually to keep trying to split these back up. That mindset is limiting. Time to move forward and treat all OS articles under one umbrella, and address education as its needed. People are pretty smart and they'll figure this out. -- Netoholic @ 03:27, 17 July 2014 (UTC)
I hope that you are missing the point, because otherwise your comments don't make any sense. I was monitoring this category, and will be if you stop blocking its usage. It does not hurt anyway. Obviously, the wrapped has nothing to do with completion of the merge – it was already complete when it was installed, and nothing changes in this regard. Obviously, it has nothing to do with split discussion – the list of articles using {{infobox OS version}} is available here, and wrapper does not help in any way. Unlike you I have a respect for others' opinions, and the only reason I want this wrapper to be there is to reduce the damage from parameter conflict of pre-merge templates. Do you have at least any argument against this wrapper, which is not based on bad faith assumption? — Dmitrij D. Czarkoff (talktrack) 08:23, 17 July 2014 (UTC)

Mini-poll: wrapper[edit]

{{infobox OS version}} was merged into {{infobox OS}}. Both these templates prior to merge used |family= with different meanings behind this parameter ("operating system this release is version of" and "operating system family this OS belongs to"), so during merge the |family= parameter of less used {{infobox OS version}} was renamed to |version of=. Corresponding changes were committed to all articles which used {{infobox OS version}}, but this change still causes confusion among editors (examples: 1, 2). I propose a wrapper template in place of {{infobox OS version}}, which would convert |family= into |version of=, and put all instances of such |family= parameter use in articles into Category:Articles using infobox OS version syntax (which was used during merge for this purpose), transparently passing all other arguments intact, for the time span of one month (until 14 August 2014)? Alternative option, as suggested by Netoholic in discussion above, is to leave everything as is in hope someone would eventually fix the misuse of parameter. — Dmitrij D. Czarkoff (talktrack) 08:28, 17 July 2014 (UTC) (updated at 14:33, 17 July 2014 (UTC) per comment by Widefox below)
  • Support (obviously). @Netoholic, Codename Lisa, Jeh: pinging participants of this discussion. — Dmitrij D. Czarkoff (talktrack) 08:28, 17 July 2014 (UTC)
  • Support Maybe with a "template is going away" warning. Jeh (talk) 08:53, 17 July 2014 (UTC)
  • Comment @Plastikspork, Rezonansowy, Uniwersalista, Longbyte1, Pigsonthewing, Wizardist, Lukeno94: @Dogmaticeclectic, Widefox, ViperSnake151, Aunva6, EverythingGeography, OsmanRF34: - Pinging the people that voted in the original TFD to see what they think about your plans to continue to delay this merge, per this wrapper suggestion and the #Split OS versions back section below also. -- Netoholic @ 09:41, 17 July 2014 (UTC)
    • You are constantly accuse me of delaying the merge. What exactly am I delaying? Which part of merge is not finished? — Dmitrij D. Czarkoff (talktrack) 14:36, 17 July 2014 (UTC)
  • Comment I see a solution, but no (concise) description of the problem and options. (below there's discussion of splitting, 10 months since the previous consensus to merge, so I don't feel like I can input without an overview). Widefox; talk 11:41, 17 July 2014 (UTC)
  • Oppose I've been in favor of substing all implementation of {{Infobox OS version}}, leaving nothing but a redirect behind. When Dmitrij protested, I deferred, because his course of action was harmless. IMHO, the problem of some people reverting the change from |family= to |os version= was because of not pushing forward. A link to the TfD in the edit summary was a must. Best regards, Codename Lisa (talk) 14:36, 17 July 2014 (UTC)
    • How exactly would substitution or link to TfD help with naming clash? — Dmitrij D. Czarkoff (talktrack) 14:40, 17 July 2014 (UTC)
      • Along with a subst, it prevents revert. Good faith erroneous reverts occur because of lack of knowledge. When sufficient context and reason is provided, the good-faith reviewer does not revert. Golden rule of editing Wikipedia: The best editor is the one writes the best edit summary. Best regards, Codename Lisa (talk) 14:44, 17 July 2014 (UTC)
        • Although I don't agree, you definitely have a point: my edit summary was far from perfect. — Dmitrij D. Czarkoff (talktrack) 15:43, 17 July 2014 (UTC)
  • Oppose: This change is still very new, if after six months there still seems to be a major confusion among editors then it may be good to discuss it. I think it is just a matter of people needing time to adapt. — {{U|Technical 13}} (etc) 15:38, 17 July 2014 (UTC)
  • Mixed I don't really see any distinct difference between the two parameters' meanings, so what's the big fuss about it? I haven't really seen an OS version that is in an OS family but is not a specific version of that OS, nor have I seen it the other way around. Longbyte1 (talk) 23:19, 17 July 2014 (UTC)
    • @Longbyte1: Mac OS X Lion is version of OS X, but belongs to Unix-like family. Android L is a version of Android (operating system), but belongs to Unix-like family. Windows Phone 8 is version of Windows Phone, but belongs to Microsoft Windows family. One would argue that OS family (what |family= parameter of this infobox is talking about) is a property of operating systems, not of their releases/versions. — Dmitrij D. Czarkoff (talktrack) 09:35, 18 July 2014 (UTC)
      • I partially agree. "Family" is a lose metaphor, not a technical jargon with definition. Unix-like not a family because its members are not developed by one developer. It is a trait, like "operating systems with GUI" or "x86 operating systems". My proposal for creating |version of= was to strike a compromise with User:Netoholic about the location and style of the text, not to cause a schism. Best regards, Codename Lisa (talk) 13:23, 18 July 2014 (UTC)
        • I agree. Any category that lumps Mac OS X Lion and Android L together is so broad as to be almost meaningless. I also wonder if the "family" designation on individual articles is backed up by a reliable external source that identifies that, or if this is a designation that Wikipedia authors have come up with. If "Version_of" is the "parent", "family" should be the "grandparent", not the great-great-great-great-grandparent. Android's "family" then should be something like Linux for mobile devices, which I think there is a lot more reliable sourcing for. To keep "family" relevant, you need to define it better and put it in the template documentation. -- Netoholic @ 16:19, 18 July 2014 (UTC)
          • Family applies to all immediate relatives, so the families of Windows XP, Android L and OS X are Windows NT, Android and OS X. Windows is a super-family. Try searching for the word "family" in Ars Technica, CNET and Softpedia News. You'll see what I mean. Seriously, isn't it obvious? Windows XP is the predecessor of Windows Vista, then these two are from a family. Best regards, Codename Lisa (talk) 16:46, 18 July 2014 (UTC)
            • @Codename Lisa: there are two different, unrelated sets of termins, which share some words. Windows Phone 8 is part of Windows Phone family, which is family of Windows Phone releases. In this sense Windows Phone itself belongs to the family of mobile OSs by Microsoft. Same is true for Ubuntu 10.10, Ubuntu and GNU/linux, or for OS X 10.5, OS X and MacOS. There is another, completely unrelated term family, which defines groups of operating systems from CS point of view. In this sense classic MacOS and MacOS X don't belong to the same family, while Android and OS X do; all systems from Microsoft with the word "Windows", together with ReactOS, belong to the same family as well. That is the root of problem here: if you speak of the former meaning, there is indeed no family "Unix-like", and "Windows" is a family that only includes some of MS's OSes up to Windows ME. If you speak of the latter, there is no family "Android" or "OS X". This ambiguity always allows to clump everything together, but the result would be completely meaningless.
              @Netoholic: OS X and Android have more in common, then OS X and classic MacOS. They even share more source code. — Dmitrij D. Czarkoff (talktrack) 18:35, 18 July 2014 (UTC)
  • Weak oppose: Temporary templates should be discouraged. Dogmaticeclectic (talk) 00:23, 26 July 2014 (UTC)

Split OS versions back[edit]

Now that merge (per outcome of TfD discussion) of {{infobox OS}} and {{infobox OS version}} is mostly complete, I want to start discussion about splitting them back. The problem here is that these templates are largerly incompatible. I am not talking here about minor editorial issues (styling, sectioning, parameter name clashes, parameter naming convention, etc.), but rather about much more fundamental differences:

  1. The set of dates to be covered is very different between operating systems and their versions:
    • Released to manufacturing applies only to OS versions. For example, each Microsoft Windows release was released to manufacturing at some point.
    • General availability is tied to target audience of operating system, which may differ significantly from release to release. For example, First release of Plan 9 from Bell Labs was targetted at universities; Second release – at business users; Third release – at mass consumption (first gratis release); Fourth release – at developers (first "free software" release); Fifth release didn't happen yet. That is: target group changed with every release, denoting every release as date of general availability for some users.
    • Initial release is clear for operating system (first time developer published the system) but is problematic for releases: ambiguous between RTM and GA dates.
    • Latest stable/preview releases for OSes are clear, but for OS versions are mostly meaningless. Most OS versions don't progress through versions once released; those that do don't require expensive (in terms of server load) processing of external versioning templates, because this information is mostly local to the article.
  2. The due weight considerations for latest releases of OSes and versions are also very different: for OSes this information is rather important and belongs to top or middle position within infobox; for OS versions this information is rather obscure, and even if there is something to list, it is the least important aspect.
  3. Working state: OSes mostly are either Active or Discontinued, while OS versions are either Supported or Unsupported. These are not exactly incompatible, but require completely separate documentation. Joining them facilitates erroneous editing decisions with consequent unnecessary discussions, cosmetic and/or misinformed edits and edit warring.
  4. Support status is different for each release, and may be quite complicated even for individual releases. Provided the available detail for support status of Microsoft Windows releases, the inclusion of this field to the infobox of Microsoft Windows will most likely lead to regular disputes about the level of detail to be covered in the infobox. At the same time, this field is natural and appropriate in infoboxes of OS versions.
  5. Predcessor/successor information:
    • It has different due weight and different optimal representation with infobox. While this information is critical for OS versions, it is of arguable worth for OSes (not so many systems were officially deprecated in favor of another OS).
    • It appears natural to use {{succession box}}-like presentation of OS versions, similarily to the way {{infobox former country}} implements that. But for OSes, which rarely have predcessor or successor such approach is impractical and damaging, just like for {{infobox country}}.
  6. Finally, here goes the "family" problem, which is lately recieving excessive attention at several different locations throught Wikipedia. This word has different meanings in context of OSes (where it denotes the range of several closely related operating systems) and OS versions (where it is alias of "operating system"). Linux Mint 10 is a release within "Linux Mint" family of OS releases, but it belongs to "Unix-like" family of operating systems. Currently these are disambiguated within this template between |family= and |version of= respective parameters, but I can bet that amount of errors will be excessive for both parameters. ({{infobox OS|name=Fedora|version of=Linux|family=Unix-like}} anyone?) This problem is saturated by the fact that drive-by editors from RFCs, WP:3O, WP:DRN and similar avenues will simply not notice the inconsistency between "{{infobox OS|name=MacOS X Lion|family=MacOS X}}" and "{{infobox OS|name=MacOS 7|family=MacOS}}", leaving passionate knowledgable editors frustrated. If this looks like overstatement to you, please see this discussion and this followup. Yes, these things are important to some of us.

Based on all of this, I suggest splitting these templates back. — Dmitrij D. Czarkoff (talktrack) 15:27, 13 July 2014 (UTC)

I wonder if the root of the problem lies a little deeper. Maybe we need a template for "OS family" and one for "OS family member". Jeh (talk) 22:17, 13 July 2014 (UTC)

The decision was merge. Find a way for Infobox_OS_version to use Infobox_OS. -- Netoholic @ 03:28, 14 July 2014 (UTC)

WP:Consensus can change, and this is shaping up to be a very good example of that. Perhaps we shouldn't merge after all. I might even oppose merge from this point forward. Perhaps a new discussion should be called with all previous participants in the CfD as well as those here as well as those in associated WikiProjects. Elizium23 (talk) 03:51, 14 July 2014 (UTC)
No, this is game-playing. There is no technical or logical reason that all operating systems can't use the same template. You can even define completely different sets of parameters, if you want. What seems to be happening is a rift between the "old-tech" and "new-tech" guys that think their stuff is so different that it can't work. Its bullocks. -- Netoholic @ 03:56, 14 July 2014 (UTC)
Ahem. "Consensus can change" is part of the Wikipedia policy on consensus. Not a guideline, not an essay. Policy. That isn't "gameplaying." To ignore this, to fall back on a year-old decision that did not involve the vast majority of users of the template (OS page maintainers), is to ignore one of Wikipedia's key principles. WP is supposed to be edited collaboratively. A "service organization" like TFD should not even be interested in forcing its decisions on users who disagree with them.
On topic: an operating system family isn't at all the same thing as an operating system (i.e. a family member). And "version" or "release" can be a different thing yet again. Why should the people who need to use a template have to puzzle over a bunch of parameters that have nothing to do with their subject? Jeh (talk) 06:45, 14 July 2014 (UTC)
@Elizium23, Netoholic: templates are merged now. I left a wrapper at {{infobox OS version}} just to catch misuse of |family= parameter. template talk:infobox OS version is already redirected here, as well as template:infobox OS version/doc. {{infobox OS version}} may also be redirected any second, although a grace period for people to get used to |version of= vs. |family= is required.
Netoholic, I am fed up with your bad faith assumption. As demonstrated by the merge there is no technical reason making use of this template impossible for both operating systems and operating system releases. There are multiple editorial issues that make it impractical, particularily provided that these two sets are not homogenous as you are trying to present. — Dmitrij D. Czarkoff (talktrack) 08:42, 14 July 2014 (UTC)
  • This is indeed GAMING because CCC says proposing to change a recent consensus can be disruptive. This merge consensus is barely a few days old and has just been completed, proposing that CCC that quickly is disruptive and I urge you to drop the stick and give it 4-6 months to see if it really works or not. — {{U|Technical 13}} (etc) 15:49, 17 July 2014 (UTC)
  • The consensus you are talking about is a TfD discussion from August 24, 2013 (about eleven months ago). I was not aware of that discussion, did not participate there, was not notified of it and never had a chance of voicing my opinion, so there is no slightest sight of WP:GAMING here. At any rate, I have no problems with giving the merged template a go for some time. — Dmitrij D. Czarkoff (talktrack) 22:50, 17 July 2014 (UTC)

From someone that's worked through a lot of these kinds of merges, some suggestions for post-merge priorities:

  • All decisions related to Template:Infobox OS now have to take into consideration that it is being used on all operating system articles and any versions thereof.
  • The vast majority of existing label/data rows are suited fine for any article using this template, but a few parameter names are complex, redundant, and unclear (in particular, the handling of release dates could be done with several parameters, and any that don't apply can just be left blank, hiding the rows).
    1. Decide what data fields you want to see in infoboxes. You can even say what fields you want only in versions or only in broader OS articles, but don't make that automatic assumption... try to commonize where possible.
    2. Establish what the best label is for each particular type of data.
    3. Place a parameter name in the template that matches and put that into the documentation (ex. if Initial release is an important bit of data, then you should use |initial release=). This helps people not have to refer to the template documentation, they can add parameters on the fly.
  • As people work on articles, they will over time convert them to the standard parameters for you. You could even flag any (OS or OS_version alike) that uses deprecated parameters the same way they do with citation templates - categories and CSS-hidden warning text.

Lastly, take note of what labels/data and parameters they use in Template:Infobox software and stay in sync where possible. If I had to guess, a merger of between Infobox_OS and that one has potential to be suggested at some point, that's more likely than this one being split back up. --Netoholic @ 04:45, 14 July 2014 (UTC)

  • Oppose splitting them back apart. While I acknowledge that CCC, it doesn't happen that quickly and this proposal is disruptive. — {{U|Technical 13}} (etc) 15:49, 17 July 2014 (UTC)
    Comment You're mistaken. The consensus to merge is from a discussion at TFD that happened about a year ago. In which time virtually no one moved away from the "OS versions" template, suggesting a grossly unpopular decision made without sufficient input from the template's users. It is TFDs forcing of this old, improper decision on a clearly disapproving user community that is disruptive. What is happening now is not a recently-formed consensus deriving from a proper discussion, it is going along with the path of least resistance, for now. STILL without input from the vast majority of the template's users. Jeh (talk) 17:42, 17 July 2014 (UTC)
    • It doesn't matter when the consensus happened. What matters is that the consensus was just carried out and no-one has had time to see how the change will work. I disagree that it taking a year for someone technically minded enough to properly merge the templates over a year to do so has any bearing on how much or little of a consensus there was. It was just the lack of a volunteer capable of carrying out the work. Please, don't confuse the two. — {{U|Technical 13}} (etc) 20:54, 18 July 2014 (UTC)
  • Comment: User:czarkoff, would you mind elaborating on your arguments above? Specifically, I would like to know which - if any - of your points you feel could not reasonably be fixed so that one template could cover both situations. Dogmaticeclectic (talk) 00:35, 26 July 2014 (UTC)
    • The problem here is not that they can't coexist – they can, and do so right now. The problem is that OS and OS release are distinct topics with different terminology and different weight of individual pieces of information, so the encyclopedic coverage of both sets would benefit from separate templates. — Dmitrij D. Czarkoff (talktrack) 03:50, 26 July 2014 (UTC)