Talk:Debian

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Good article Debian has been listed as one of the Engineering and technology good articles under the good article criteria. If you can improve it further, please do so. If it no longer meets these criteria, you can reassess it.
          This article is of interest to the following WikiProjects:
WikiProject Linux (Rated GA-class, Top-importance)
WikiProject icon This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of Linux 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.
 GA  This article has been rated as GA-Class on the project's quality scale.
 Top  This article has been rated as Top-importance on the project's importance scale.
 
WikiProject Free Software / Software / Computing  (Rated GA-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Free Software, a collaborative effort to improve the coverage of free 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.
 GA  This article has been rated as GA-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software (marked as Mid-importance).
Taskforce icon
This article is supported by WikiProject Computing (marked as Low-importance).
 
WikiProject Open (Rated GA-class, Mid-importance)
WikiProject icon Debian is within the scope of WikiProject Open, a collaborative attempt at improving Wikimedia content with the help of openly licensed materials and improving Wikipedia articles related to openness (including open access publishing, open educational resources, etc.). If you would like to participate, visit the project page for more information.
 GA  This article has been rated as GA-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
 

FA preparation[edit]

Since the DYK process is over, let us continue. There is no A-class in this article's WikiProjects, so the next goal is the FA-class. These are the criteria.

Compliance[edit]

Feel free to overwrite this status to reflect the discussion.

    1. well-written:
    2. comprehensive:
    3. well-researched:
    4. neutral:
    5. stable:
    1. a lead:
    2. appropriate structure:
    3. consistent citations:
  1. Media:
  2. Length:

Discussion[edit]

Regarding "well-written", this should be left to a professional writer when all the other criteria have been dealt with.

About "comprehensive", I really feel that major facts are missing: e.g. Debian Women. Although modern literature like "The Debian Administrator's Handbook" barely mentions Debian Women (Krafft wrote more in 2005), it is an important part of Debian. Besides the diversity statement, female ratio, financial support, etc, incidents like this one eventually happen. I will not go further with this issue, but someone else should give the "comprehensive" OK.

Concerning "well-researched", I will check once more that claims are verifiable. There are some sentences that do not sound neutral; verification will help with this.

The article looks stable, with a good lead, appropriate structure, consistent citations and enough media. Citations could be improved a bit more.

I am not sure whether the article stays focused. I will leave this assessment to another editor. 84.127.80.114 (talk) 23:03, 30 June 2014 (UTC)

To the best of my knowledge, the "well-researched" criterion is met. The article was fairly neutral already and the information is presented without bias; the "neutral" criterion is met too. Although other featured articles have shorter tables of contents, I do not find this one overwhelming.

The next goal should be "length". The article is more focused but another opinion is needed. I will wait one week before doing a first pass for this criterion and then ask for a review, unless another editor wants to take over. 84.127.80.114 (talk) 00:43, 6 August 2014 (UTC)

A little help opening the peer review would be appreciated ("Engineering and technology" link at the top of the page). 84.127.80.114 (talk) 22:07, 25 August 2014 (UTC)

Because of events that have led to this edit, I will refrain from working in this article for one week, unless the Peer review or the FAC process (which I cannot initiate either) start. I hope that the article gets improved in the meantime. 84.127.80.114 (talk) 22:54, 29 September 2014 (UTC)

Despite this edit, I am sure that GamerPro64 has nothing against Debian. May the user review this article or open the peer review at the PR list as intended? The peer review has not been advertised. 84.127.80.114 (talk) 21:36, 13 October 2014 (UTC)

Featured article tools[edit]

Toolbox

It be helpful to run the Featured article tools. Lentower (talk) 03:02, 1 July 2014 (UTC)

Expected information[edit]

This section is meant to receive feedback from Wikipedia users that have been selected randomly. The purpose is to make the article useful to different types of readers. Of course, users are not expected to read the whole article. The question is: what else do you want to know about Debian?

Review by GamerPro64[edit]

GamerPro64 is reviewing the article; the review should continue in this page. I should clarify that the article is not prepared, e.g., the "well-written" pass is missing. The review was meant to check the "length" criterion and a couple of questions. Nevertheless, GamerPro64's input is more than welcome.

Regarding the use of Debian Wiki as a source, I agree that it is unreliable if used "as is".[1] However, this is no ordinary wiki, because many Debian members are contributors. A claim should be reliable if the information was added by a confirmed Debian member (diff) and it is uncontested. This is equivalent to an email sent by a Debian member.

I will revise the Debian Wiki references. 84.127.80.114 (talk) 23:57, 14 October 2014 (UTC)

Done. GamerPro64 may continue with the review, if he wants to. 84.127.80.114 (talk) 08:32, 18 October 2014 (UTC)

Length review[edit]

The purpose of the peer review is to check the "length" FA criterion. Also, an answer to the following questions would be appreciated:

  • Does the table of contents look overwhelming?
  • Does the section Architecture ports look disruptive to the flow of text?
  • As a reader not used to articles about software, which column feels more comfortable?
Jun 17, 1996 1996-06-17 17 Jun 1996
Dec 12, 1996 1996-12-12 12 Dec 1996
Jun 5, 1997 1997-06-05 5 Jun 1997
Jul 24, 1998 1998-07-24 24 Jul 1998

84.127.80.114 (talk) 08:26, 18 October 2014 (UTC)

Table usability (2)[edit]

This topic was split off from #Length review, above. 84.127.80.114 (talk) 12:38, 23 October 2014 (UTC)
Month names shouldn't be abbreviated, that's been already beaten over and over in MOS discussions. — Dsimic (talk | contribs) 21:58, 18 October 2014 (UTC)
Brevity is required.[2] 84.127.80.114 (talk) 03:25, 19 October 2014 (UTC)
Why is it required? — Dsimic (talk | contribs) 03:58, 19 October 2014 (UTC)
It is an accessibility issue, that is why I made the change regarding the date format. Relocating references is another technique towards that goal. Regular edits also help, such as removing redundancy.
Although the manual reads "Only where brevity is required ... tables", it is not required to use the abbreviated format in tables. Abbreviation is just one option to reduce width. There are alternatives, such as removing the "≈" signs and dropping one feature in Squeeze, but I needed someone else to suggest those changes first.
Dsimic made a good decision then; that table was completely different. I have not forgotten that Dsimic prefers MDY dates and Derianus needs ISO 8601 for some reason; both users represent a type of reader. The #dateformat function could help solving this divergence, but I am not sure about the default format. However, abbreviation does make a difference; does Dsimic find the abbreviated MDY unacceptable? 84.127.80.114 (talk) 06:19, 19 October 2014 (UTC)
To me, abbreviating the month names brings more disadvantages than benefits. From one side, it is simply less readable; on the other hand, it somehow reflects the "I have no desire to do this properly, so just let me slap something really quickly" attitude, which is common to many abbreviations in general.
As I've already explained, this is 2014 and really small screens are not so common. Also, let's just have a look at the timeline graphs in Debian § Timeline section – how are those supposed to fit and still be readable on screens that small so the releases table requires substantial compactions? To me, that turns the compaction of dates into a moot point. — Dsimic (talk | contribs) 06:46, 19 October 2014 (UTC)
If abbreviated months are not acceptable, then I guess that only one format is possible. Would {{abbr}} (Dec 12, 1996) solve this perception of laziness?
Now that the timeline graphs are in the discussion, I also notice that they may be too wide. The manual recommends the 1024×768 resolution. The reason I have not reduced the graph width is because some horizontal scrolling is allowed and graphs do fit in the mobile view. I would certainly support a graph width reduction. 84.127.80.114 (talk) 02:00, 20 October 2014 (UTC)
Well, I'm still against month name abbreviations and pretty much all other "pinching" in 2014, so I'd guess that we should hear opinions from other editors. — Dsimic (talk | contribs) 03:50, 20 October 2014 (UTC)
Is Dsimic against the 1024×768 resolution guideline? 84.127.80.114 (talk) 06:08, 21 October 2014 (UTC)
Hm, 84.127.80.114, why do you refer to me in third person? :) Regarding the 1024×768 resolution guideline, I'd say that using |upright= parameter for images makes much more sense. — Dsimic (talk | contribs) 19:35, 21 October 2014 (UTC)
About persons; odd sound it does?
I mentioned letter-spacing; font-size is another option. However, resizing does not address accessibility for a lower resolution, but for a bigger one, otherwise scrolling would be unnecessary; we should not try to fit 4096×2160 into an unreadable 1024×768. Resizing would be a sign that the table contains too much information to be useful. If MDY without abbreviation is chosen, other information should go elsewhere. 84.127.80.114 (talk) 06:19, 22 October 2014 (UTC)
Sorry, but I really don't get your third-person riddles. What's it about, as there's nothing about it in WP:OWNTALK you've referred to? Is it about distantiating yourself?
Also, don't you think that putting the width of a table above its content is actually going to hurt what's most important, and that's the content? — Dsimic (talk | contribs) 16:29, 22 October 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── "No personal attacks are intended."[3] Let us focus on the subject.

Strictly answering the question, sacrificing content merely because of width minimization is harmful for the article. The article is the most important, the understanding of the subject, major facts and key details.

That said, tables should present information in a useful way. Tables with too many details are less useful and they are not a substitute for prose. Concerning content, no relevant information has been discarded because of my decisions on accessibility, although my criteria about what is relevant may be questioned (and has been questioned). 84.127.80.114 (talk) 12:38, 23 October 2014 (UTC)

The content is most important, in the end that's what the articles are about. Also, I agree that too much information in tables makes them less readable. However, I'm still against the concept of making tables more readable by not using MDY dates. As we're proposing pretty much different approaches, I'd say that going back and forth isn't productive; thus, let's hear opinions from other editors, if you agree. Maybe even starting an RfC would be an option? — Dsimic (talk | contribs) 14:13, 23 October 2014 (UTC)
Of course, an article is made of content, but not every content can be in the main article. Dsimic prefers MDY dates without abbreviation; in that new table, what other information should be moved? 84.127.80.114 (talk) 02:38, 24 October 2014 (UTC)
I would like Dsimic to make a first suggestion. While he is absolutely right regarding this edit, we should focus our efforts on this issue; some reasons are:
  • That content will eventually get revised around November 5.
  • The table is already a mess.
  • Perfection is not required; we are still preparing this article.
  • We work in the open, under constant good faith mistakes and vandalism.
Please try to isolate from that noise and look at this table. 84.127.82.127 (talk) 06:54, 29 October 2014 (UTC)
Well, here's what I'd suggest to be done:
  • Bring the MDY dates back, as they look and read way better.
  • Merge the "Timeline description" table into primary "Timeline" table; that way, a lot of content would be deduplicated.
After that I'd call it a day. — Dsimic (talk | contribs) 20:35, 29 October 2014 (UTC)
So, we have Derianus that wants YYYY-MM-DD, regardless of accessibility. We have Dsimic that wants MDY, regardless of accessibility too. I seem to be the only one who cares about accessibility. Therefore, let us use the #dateformat function and we will address accessibility later. The default should be the format produced by five tildes (16:12, 30 October 2014 (UTC)), i.e., DMY. Will Derianus be able to copy dates using an account?
Example: 30 October 2014
84.127.82.127 (talk) 16:12, 30 October 2014 (UTC)
"wants YYYY-MM-DD, regardless of accessibility" - any source for the latter part? Also, DMY uses even more space and it will not go towards date format consistency for tables across different articles. Otherwise, the reasoning to use the date format produced by four tildes (i.e. the English Wikipedia software default format), looks wise. Derianus (talk) 03:35, 31 October 2014 (UTC)
At the same time, it isn't that I don't care about accessibility. Instead, I just find that trading readability for a dozen or two of pixels doesn't make much sense. Readability, in general, is also a form of accessibility, if you agree. — Dsimic (talk | contribs) 04:05, 31 October 2014 (UTC)
I will wait until consensus is reached in the WikiProject discussion. 84.127.82.127 (talk) 19:07, 31 October 2014 (UTC)

Review by GamerPro64 (2)[edit]

This topic was split off. 84.127.80.114 (talk) 12:38, 23 October 2014 (UTC)
  • I'll be adding this article to my watchlist so you don't have to ping me anymore. Now for the next thing that needs to be worked on are the images. The image of Buzz Lightyear has to go. Doesn't add anything to the article. As well the source for File:Debian-cd-cover1.png redirects to itself. Might raise a few alarms. Just overall get them looked at to see if they can pass a Image Review. GamerPro64 22:35, 19 October 2014 (UTC)
The swirl in Buzz Lightyear's chin is relevant, specially to the "Code names" subsection. Pixar's influence in Debian's history is notable. Some people believe that this influence was acknowledged at Pixar, including project leader Stefano Zacchiroli;[4] with Bruce Perens working at Pixar, this is plausible. I would not reliably affirm that this is the Debian swirl, but this detail in the chin of the first named Debian release character is an interesting fact. 84.127.80.114 (talk) 03:00, 20 October 2014 (UTC)
Can you at least mention that into the actual article instead of it being only mentioned in the image's caption? GamerPro64 03:10, 20 October 2014 (UTC)

Images[edit]

There are copyright problems with File:Debian Installer graphical etch.png, uploader BorgHunter, and with File:Debian Etch-ja.png, uploader Green from Commons. Regarding the History section, my choice of screenshots would be:

  • Birth (1993–1998): Debian 0.91
  • Leader election (1999–2005): Slink
  • Sarge release (2005–present): Sarge and Squeeze

Unfortunately, image uploads are out of my reach. 84.127.115.190 (talk) 18:15, 4 November 2014 (UTC)

Table usability[edit]

I have reverted this recent edit to Debian. "People have small screens" does not seem a valid reason because "Release date" is longer than those dates. Furthermore, the timeline image below has a width of 860 pixels, wider than the table. Could Derianus provide more details about the display device on the article's talk page? 84.127.80.114 (talk) 06:50, 20 September 2014 (UTC)

@"People have small screens" does not seem a valid reason because "Release date" is longer than those dates. - But "Release date" has a space in the middle which enables display software to insert a new line. The old format is more concise. The table has seven columns, so it takes up a lot of space already.

Wikipedia:Manual of Style/Dates and numbers#Dates and years allows this format for tables. The object containing the dates in question is a table. Derianus (talk) 09:56, 20 September 2014 (UTC)

I advise Derianus to familiarize with the WP:BOLD, revert, discuss cycle and leave the status quo up, i.e., revert to the previous version. I would also recommend WP:Edit warring, given the activity in Regions of Ukraine.
Derianus is not addressing my concerns. Is the editor actually seeing the alleged problem? "Release date" is inside <span class="nowrap">. Inserting a new line means ignoring the CSS and that would mean ignoring <span style="white-space:nowrap;"> for the dates too.
The editor may have noticed the "Supported until" column. There are dates which cannot follow the yyyy-mm-dd format. What is Derianus' suggestion to solve the format inconsistency in the table?
(By the way, using the "Engineering and technology" link at the top of this page would really improve this article.) 84.127.80.114 (talk) 01:39, 21 September 2014 (UTC)
Why handing out advises to others that you don't follow yourself? I simply reverted to the ISO 8601 format. Derianus (talk) 04:10, 23 September 2014 (UTC)
Derianus is refusing to address my concerns. There is consensus for the mdy format: the bold edit using words was not disputed or reverted by subsequent edits; I revised that edit later in the good article review without dispute, reaching a new consensus; I have revised the date format specifically.
There is no evidence of consensus change. The other editors are not participating or reverting, but given that they are not answering my calls to improve this article either, I do not find silence to be a valid reason. They are busy and maybe they trust the current effort, which Derianus is invited to join in.
I repeat, what is Derianus' suggestion to solve the format inconsistency in the table? 84.127.80.114 (talk) 00:22, 24 September 2014 (UTC)
"I do not find silence to be a valid reason" - you take silence as you like. E.g. when it was changed in the direction you prefer you take it as evidence for new consensus. Now, you do exactly the opposite. Derianus (talk) 20:21, 26 September 2014 (UTC)
Well, at least I am disputing Derianus' edit; silence is definitely not a valid reason now. I do not remember using only silence to support the word-based date format, which is also supported by consensus through editing.
I would like to note that Derianus' arguments are focused on my reasoning consistency exclusively. I do not mind being in question, but some words concerning the table would be appreciated. 84.127.80.114 (talk) 23:26, 26 September 2014 (UTC)
"I do not remember using only silence" - did anyone claim that? "I would like to note that Derianus' arguments are focused on my reasoning consistency exclusively." - That is blatant misrepresentation of facts. Derianus (talk) 21:06, 28 September 2014 (UTC)
WP:SILENCE does not apply to this as an editor has opposed both sets of changes - a new consensus is only reached when a new undisputed version of the article is created.
Table: It is inconsistent to have one style of date in one column and one in another. If there is a policy regarding the use of one particular format in a column, then IMO both should use that format otherwise it would be based on preference. MOS:DATEFORMAT shows both are acceptable in tables. It is a stylistic issue rather than a major problem and I would select the template, dts, abbreviated date - testing on a 5" screen shows that neither format results in more columns/text being displayed. To get more displayed the nowrap on "Release date" would need to be removed - then the new format would be better justified.
mthinkcpp (talk) 12:55, 28 September 2014 (UTC)
"It is inconsistent to have one style of date in one column and one in another." - Maybe you can play the magician and add exact dates to the table where they are missing? As long as you cannot, the inconsistency cannot be removed without replacing exact days with month values in the other column. Derianus (talk) 21:06, 28 September 2014 (UTC)
Since Derianus cannot solve the inconsistency without discarding information, the user should revert to the mdy format until the missing exact dates are provided. The mdy and month-year formats are both word-based. 84.127.80.114 (talk) 21:39, 28 September 2014 (UTC)
LOL. The other format had the inconsistency too. Are you trolling? Derianus (talk) 21:45, 28 September 2014 (UTC)

I love the chaotic sorting in the timeline table (mixed legend row, TBAs, "supported until" column), although it may be my browser. It is no secret that I am in favor of providing humorous content to happy readers. I had another Easter egg proposal for Debian (not mentioned), but perhaps other users may want to contribute. How about a picture of Debian headquarters? 84.127.80.114 (talk) 17:21, 7 October 2014 (UTC)

yyyy-mm-dd limitation[edit]

I still believe Dsimic made a sensible decision. I have tried alternatives to express dates with month accuracy (c. 2000-10-01; 2000-10-??; 2000-10-00; 2000-10-); there is not a clean option. yyyy-mm is a valid ISO 8601 format, but is unacceptable as per WP:BADDATEFORMAT guideline. Word-based formats should be used.

However, this is exactly the same problem I am facing with citations in another article:

Reference date accessdate
1. Ghost in the Shell Preview September 1997
2. Ghost in the Shell 1997-12-10 2013-09-03

Access dates are exact, but source dates may be reduced to month accuracy.

No citation in the Debian article has month accuracy. If a new source about Debian appears with this accuracy, should the month information be discarded because of a style issue? Should all the other dates be converted to mdy? This consistency problem is not covered by the manual of style. A decision should be made:

  1. Ignore the style inconsistency (current state).
  2. Stick to ISO 8601 and ignore the manual of style.

I am fine with either. 84.127.80.114 (talk) 03:02, 29 September 2014 (UTC)

Hey everyone! FWIW, I prefer MDY dates in articles, and in text in general – in such "environments" MDY dates just look better and more readable to me. On the other hand, YYYY-MM-DD format is much more usable when it's about easier sorting etc., but that usually doesn't apply to articles. Also, the argument of small screens simply doesn't make sense to me, as there's little chance that a few characters more would cause readability issues. Just my $0.02. :) — Dsimic (talk | contribs) 04:08, 29 September 2014 (UTC)
Sorting isn't an issue as the dts template resolves it, showing the word format, but still sorting correctly (according to its page). mthinkcpp (talk) 17:04, 29 September 2014 (UTC)
Exactly, {{dts}} template covers that; I was referring to sorting dates in general, aside from the usage in Wiki markup language. Sorry I wasn't clear enough. — Dsimic (talk | contribs) 19:56, 29 September 2014 (UTC)
And that is why in table ISO 8601 is seen more often than in text. And the Debian article breaks easy copy-paste between other sources and the data in table. I thought Wikipedia and Debian have to do with sharing? Not their metadata? Derianus (talk) 22:38, 29 September 2014 (UTC)
Why would MDY break anything? Anyone can simply go to the page source and use ISO dates present there, if the goal is to fetch the dates formatted that way. — Dsimic (talk | contribs) 22:50, 29 September 2014 (UTC)
My position, keep all the information, but use MDY. It is reasonably clear when the day/month has been omitted. Also it is more consistent to use MDY and just omit parts than to use both YYYY-MM-DD and MDY. mthinkcpp (talk) 17:09, 29 September 2014 (UTC)

Why has this ended up in an ISO 8601 versus MDY discussion? This is not the place for such a debate and I will not participate (except for one comment). I thought that I raised a simple question: in an ISO 8601 context, how should dates with month accuracy be formatted? Removing the data does not solve the problem. I guess I will have to make the first decision: in an ISO 8601 context, the ISO 8601 format should be followed, i.e., YYYY-MM.

If Derianus is really interested in ISO 8601, then the user should know that this source is not reliable because it discourages YYYYMMDD, which is the basic format according to the standard, section 4.1.2.2. So, if width is an issue, the user should definitely push for this format.

I thought Wikipedia and Debian have to do with sharing. We have 77 localizations of the Debian article. Would it be nice if all these numerical data and timeline charts were shared across all these encyclopedias? Would it be useful if tables were moved to Commons and reused as templates, just like the media files? Could the dates be in a compact format such as YYYYMMDD and later localized in each Wikipedia?

Ultimately, this whole article could be moved to Commons, automatically translated, and only the localized featured and good content would be kept, besides other bits of regional interest. Maybe I am going too fast. Any thoughts about moving the release dates to the Wikidata page and using the #property parser function? 84.127.80.114 (talk) 17:21, 7 October 2014 (UTC)

Hm, isn't the automated translation between different human languages still just a pipe dream? Btw, YYYY-MM format is, AFAIK, not allowed by the Wikipedia's guidelines as it's really confusing. — Dsimic (talk | contribs) 18:30, 7 October 2014 (UTC)
No consensus in the guidelines.[5] If the context uses ISO 8601 to express a date, it should be obvious that yyyy-mm indicates an approximate date in that context, not a year range that would need an en dash. 84.127.80.114 (talk) 03:44, 19 October 2014 (UTC)
84.127.80.114 - personal attacks aside, I agree with moving the data to WikiData. This is much better for sharing between Wikipedias and sharing with other parties. It may make it harder for non-WMF-wikis as long as they cannot use the WD-data.Derianus (talk) 22:14, 9 October 2014 (UTC)
It looks like #property is not ready for prime time. This is not the first time that interwiki solutions have been suggested.[6][7] However, I believe that we have the elements to implement a "Commons" for templates.
Nevertheless, it would help to know exactly what problem Derianus is trying to solve. What table does the user maintain? What software is using Wikipedia's rendered HTML instead of wiki markup? 84.127.80.114 (talk) 00:32, 11 October 2014 (UTC)
The problem of copying is solved (by using ISO 8601). The problem that users want to destroy the possibility to copy data in wiki code and data rendered as html remains. There are dozens?hundreds of tables in Wikipedia using ISO 8601 and that format is specifically allowed for being used in tables by MOSNUM. "yyyy-mm-dd limitation" is close to a hoax. Derianus (talk) 02:28, 11 October 2014 (UTC)
Well, MDY isn't forbidden either. Also, how often do you need to copy the dates, or how often other users report that need? — Dsimic (talk | contribs) 02:46, 11 October 2014 (UTC)
  • I already explained the section title and my initial question has been answered. I appreciate Derianus' contributions, specially this one, so I should give a warning. I do not know if Derianus is aware of the edits that has done. I do not know if the user is aware of the policies either. I do like the ISO 8601 format. However, if Derianus wants cross-article consistency, that wish might become true.
If there is some software outside of Wikipedia that depends on rendered HTML, I may be able to help. 84.127.80.114 (talk) 22:19, 11 October 2014 (UTC)

YYYY-MM-DD benefits[edit]

  • better for small screens
  • the only option for cross article consistency
  • easier sharing of data between different Wikipedia langauge editions, since ISO 8601 is an international standard
  • sortable without any extra templates or hidden javascript logic - WYSIWYG
  • easier sharing of data between table data in Wikipedia and tabular data from other sources — Preceding unsigned comment added by Derianus (talkcontribs) 22:43, 29 September 2014 (UTC)

The small screen argument has been given as one benefit. It was countered by:

  • "Also, the argument of small screens simply doesn't make sense to me"

Maybe that user never had looked at tables with several columns having a date format longer than ISO 8601 YYYY-MM-DD.

It is simple physics, more characters need more space on the screen and less need less. Derianus (talk) 22:29, 29 September 2014 (UTC)

Yeah, I've looked at Wikipedia articles on small screens. Though, if you want to deal with more complicated matter, you simply need a bigger screen, right? There's no point in trying to fit a pumpkin into something that was made for an apple, so to speak. — Dsimic (talk | contribs) 22:53, 29 September 2014 (UTC)
I've looked at that particular table, both editions and (as I said before) neither show more information. mthinkcpp (talk) 18:29, 30 September 2014 (UTC)
Despite of this, basic laws of physics hold - a place occupied by one object cannot be occupied by another. Adjust the screen so, that the date cells are exactly filled by YYYY-MM-DD. Now try to fit MDY in the same cell, without altering any table boundary nor the size of font. Derianus (talk) 22:39, 6 October 2014 (UTC)
At the same time, basic principles of economics also apply – as a result, even cellphones will soon have 4K screens. I'm not saying that having 4K screens in phones makes sense, but as a result in 2014 it's simply absurd to trade a few pixels for style and readability. — Dsimic (talk | contribs) 02:29, 7 October 2014 (UTC)
Also on 4K screens the basic laws of physics hold. Derianus (talk) 22:28, 9 October 2014 (UTC)
  • Behold the laws of physics: the time is 17:21, 7 October 2014 (UTC). We control the horizontal and the vertical. Welcome to the Wiki Limits. 84.127.80.114 (talk) 17:21, 7 October 2014 (UTC)
"Cross-article consistency"- The Wikipedia Manual of Style points (mostly) to MDY. mthinkcpp (talk) 18:29, 30 September 2014 (UTC)
MOS allows DMY and MDY and it prohibits switching articles from one form to the other. Using ISO 8601 in tables therefore is the only way to achieve cross-article consistency for tables. Derianus (talk) 13:48, 2 October 2014 (UTC)
Not quite, it prohibits changing the date format without either consensus or an accepted reason mandating the change, i.e. They cannot be just changed to ISO..., MDY or DMY without consensus - although I think there is now consensus for changing to/using MDY. mthinkcpp (talk) 17:10, 7 October 2014 (UTC)
@part 1 - OK; @part 2 - no, there is no consensus. And people have not shown why ISO 8601 YYYY-MM-DD in tables should be changed to MDY or YMD. Several benefits of ISO 8601 have been shown, counter arguments were mostly attacking the advantages, but failed, and only few disadvantages had be mentioned, e.g. ~"format inconsistency within the table" - but that does not exist.
For the cross-article consistency - can you demonstrate that MDY is preferred by the MOS over DMY? Derianus (talk) 22:28, 9 October 2014 (UTC)

MDY limitations[edit]

While using ISO 8601 leads to cross article consistency for tables, and values can be copied between Wikipedias in different languages, MDY values cannot be copied nor will their usage in the Debian article lead to cross article consistency for tables.

Compare

Derianus (talk) 22:18, 29 September 2014 (UTC)

Cross-article consistency[edit]

I started a list at Wikipedia talk:WikiProject Software#Date format in release history sections of OS articles. Derianus (talk) 04:11, 31 October 2014 (UTC)

Dubious information in timeline[edit]

Some versions have a supported until date before release of the next version.

This applies only to values that are presented with month-precision. I fixed Potato. Hamm and Bo still have the dubious information.

Derianus (talk) 22:05, 28 September 2014 (UTC)

I removed

  • 2.0 "Feb 1999" and
  • 2.1 "Oct 2000 "

neither had a reference. Derianus (talk) 21:58, 29 September 2014 (UTC)

In the meantime, let me play the magician. 84.127.82.127 (talk) 00:47, 4 November 2014 (UTC)

License in infobox[edit]

The purpose of an infobox is to summarize key facts that appear in the article; the less information, the better.[8] The fact that Debian is not entirely free software is in the first sentence of the lead; the body of the article explains more about licenses and the non-free area. DFSG are notable and "DFSG-compliant" is a precise term to summarize the licensing model. 84.127.80.114 (talk) 02:37, 19 October 2014 (UTC)

May Fsandlinux state the rationale for this edit? 84.127.80.114 (talk) 03:46, 21 October 2014 (UTC)
I know very little English. These changes, Debian page, other Linux distributions made to be compatible with pages. "(Mainly the GNU GPL)" he did not remove it from the page, as this is appropriate for you?
In fact, Linux distributions licensing information ise Webconverg, Tizen pages in a similar way; "Build script", "Linux kernel, such as" I think that is subdivided.--Fsandlinux (talk) 17:27, 21 October 2014 (UTC)
Webconverg and Tizen are bad examples. These are the good guides: manual of style, good article criteria, and featured article criteria.
Infobox is for key facts: only the most important one, if possible. Also, refs should be in the article body, not in the infobox. 84.127.80.114 (talk) 07:39, 22 October 2014 (UTC)

Infobox key facts[edit]

OpenBSD may be a featured article, but this is not enough, and we have contributors that have trouble reading the guidelines. This WikiProject really needs a lighthouse: this article should become the model. When the FA preparation is finished, I encourage editors to give their best and improve it further.

I will tighten the infobox content. This means decisions such as dropping "Micro" and "unofficial". However, I would not drop "Hurd"; there are not many distributions running Hurd and this is the kind of link that improves an infobox. If someone spots a rarely supported platform, this would apply too, otherwise the text will be "x86-64, IA-32, ARM and five more" as per popularity. 84.127.80.114 (talk) 07:39, 22 October 2014 (UTC)

Support for communities[edit]

"Community support" seems ambiguous. This section should be under Features and the layout would be:

  1. Support for communities
  1. Localization
    As it is.
  2. Virtual communities
    This section would tell how Debian supports big virtual communities, such as Facebook, Tencent QQ and Skype.

I will wait one week before adding this content, just in case someone wants to give it a try. 84.127.115.190 (talk) 23:47, 6 November 2014 (UTC)

New release names[edit]

Regarding this edit, these code names have been announced. However, this kind of future event is not appropriate. Jessie is not released, but there is an actual distribution (testing). Unless distributions for Stretch and Buster exist, this information should be left for later. 84.127.115.190 (talk) 21:32, 9 November 2014 (UTC)

It looks like we have some fans excited with these names.[9][10] Let us tag this information appropriately and wait until the excitement fades away. 84.127.115.190 (talk) 00:31, 12 November 2014 (UTC)

Maybe "not appropriate" is not appropriate here. 91.9.127.47 (talk) 17:49, 13 November 2014 (UTC)

Freeze of Jessie[edit]

According to http://www.heise.de/newsticker/meldung/Freeze-fuer-Debian-8-Jessie-2443508.html?wt_mc=rss.ho.beitrag.rdf, Debian 8 "Jessie" was freezed around 2014-11-06. Unfortunately, I can't find any more information about it in the net. But I think it's time to update some timeline information. 195.141.2.242 (talk) 08:49, 13 November 2014 (UTC)

Of course, the reference in the article is not clear enough. 84.127.115.190 (talk) 01:41, 14 November 2014 (UTC)

Features, policies, variants[edit]

Current hierarchy of the following elements in the article is:

  1. Features
    1. Variants
      1. Distributions
      2. Releases
      3. Blends
    2. Derivatives
  2. Policies

What is meant by "features"? Policies are also a feature of the Debian project. If Policies are outsourced, then why are Derivatives included? I suggest something like:

  1. Software features OR Operating system features
  2. Variants and derivatives
    1. Debian branded variants
      1. Distributions
      2. Releases
      3. Blends
    2. Derivatives
  3. Project policies

91.9.127.47 (talk) 18:07, 13 November 2014 (UTC)

"Policies are also a feature of the Debian project." that is true. However, the very first sentence in the lead says: "Debian is an operating system". If 91.9.127.47 does not understand what this article is about, how can the editor make proper decisions? I am going to let 91.9.127.47 edit the article as much as wanted; I can repair it later. A warning: references that should go away do not need to be fixed. 84.127.115.190 (talk) 02:12, 14 November 2014 (UTC)
"If 91.9.127.47 does not understand what this article is about" - maybe 91.9.127.47 understood that better than 84.127.115.190? In the second sentence it says "Debian is one of the most popular Linux distributions" and under "Features" it says "Distributions". So, is it one or is it several distributions? Then, in the category section it says "Category:Free software culture and documents Category:Debian Project leaders Category:Debian people". Do Wikipedia articles restricted to software reside in the category tree for "culture and documents" or "people"? Are policies part of the OS? Was the "2008 OpenSSL vulnerability" part of the OS? Why is the latter placed under Policies? Why is Ubuntu mentioned under Policies? Can 84.127.115.190 explain the mess? 91.9.103.21 (talk) 06:43, 22 November 2014 (UTC)
If 91.9.103.21 is asking why I have not fixed every issue in this article yet, then the answer should be obvious: I am not a bot (MediaWiki asks me several times) and I have to convince people of my edits. So, one issue at a time, the WikiProject discussion being the priority. 84.127.115.190 (talk) 17:31, 22 November 2014 (UTC)
  • "Distribution" is Debian lexicon;[11] it is a bit confusing. Let us try the "branch" nomenclature. 84.127.115.190 (talk) 16:23, 23 November 2014 (UTC)

my Announcement on Debian regarding Jessie 8.0[edit]

Debian Jessie is currently frozen right now as i have googled it this week the release date for Debian Jessie is TBA --User:superusergeneric hello (talk) 01:11, 27 November 2014 (UTC)

Buzz Lightyear[edit]

The current image of Buzz Lightyear seems out of place, but I thought I would bring it up here. Is there any reason for its presence, apart from the fact that he has a swirl on his chin? — Preceding unsigned comment added by 174.17.250.246 (talk) 23:27, 8 December 2014 (UTC)

Hello! Well, one theory says that Buzz's swirl is shared with the one on Debian's logo, so having the image included should make some sense. — Dsimic (talk | contribs) 23:33, 8 December 2014 (UTC)