Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#12786 closed defect (wontfix)

[SDK] Missing file extensions (*.txt)

Reported by: lazaridis_com Owned by:
Priority: high Milestone: tbd
Component: General Version: 1.6.0
Keywords: Cc:
Blocked By: Blocking:


I've downloaded the SDK, and I've noticed some missing file extensions e.g. in the files like README and LICENSE.

README and LICENSE files should become "README.TXT" and "LICENSE.TXT"

Note that this is a defect, as those files cannot be identified as text files by the Windows OS. It is very annoying when browsing the sources on a windows machine.

Change History (17)

comment:1 Changed 8 years ago by Adam Peller

Resolution: wontfix
Status: newclosed

This is common practice in open source projects, even though it's probably a Unix convention.

comment:2 in reply to:  1 Changed 8 years ago by lazaridis_com

Resolution: wontfix
Status: closedreopened

Replying to peller:

This is common practice in open source projects, even though it's probably a Unix convention.

Within any (open or closed source) project which contains the target OS "Windows", omitting the *.txt suffix for text-files is a concrete defect.

Subjecting Ticket Processing:

Please avoid closing defect reports that quick with a "wontfix", as this can be conceived as rude by the reporting individual. Additionally it can reflects negative on the projects openness.

comment:3 Changed 8 years ago by Adam Peller

Ok, feel free to discuss on list (perhaps dojo-interest would be appropriate), but this sort of bikeshedding thing shouldn't take up resources on trac. If you can find committers who feel otherwise, we'll make the change, otherwise we try not to keep issues like this open. Sometimes that means respectfully disagreeing and closing tickets.

comment:4 Changed 8 years ago by lazaridis_com

I understand your suggestions, but I really do not want to move to the discussion-list and invest more time. I'm sure someone of the team (especially one who uses windows machines) will understand the severity of this "*.txt" issue.

Remember: "It is very annoying when browsing the sources on a windows machine. ".

comment:5 Changed 8 years ago by dylan

Given that github and other tools support markdown, perhaps our readme files should be switched to markdown format, changed to, etc with the .md extension?

comment:6 Changed 8 years ago by Adam Peller

I think renaming and reformatting the files will only create more confusion. I'd really like to close this. Trac is simply not the place for this sort of discussion.

comment:7 Changed 8 years ago by lazaridis_com


I was referring to the downloadable SDK. Markdown is nice, but not for offline material.


You may wan't to update this information, which has invited me in a very friendly manner to file issues: And I restrain myself, as filing issues costs energy and time. Otherwise I would have filed much more until now. If you personally don't like windows, it's ok. I don't like it, too. But that does not mean that I ignore the users of those machines.

Recreation of defect:

  • pick a windows machine (e.g. an laptop)
  • visit, get excited and download the SDK
  • extract the files, take a pot of coffee and start exploring the files with the windows file explorer.
  • try to open a README file or a LICENSE file with a double-click (keeping the coffee in the other hand).

It is really that simple.

I understand that you're currently working on 1.6.1 (if I remember right). It's one thing to say "yes, it is a defect, but will be taken care later, after 1.6.1". And it's another thing to simply ignore this defect (and thus reality) and to close the ticket.

comment:8 Changed 8 years ago by Adam Peller

Resolution: wontfix
Status: reopenedclosed

wontfix doesn't mean it's not a valid defect or that your input is not appreciated, it just means we're choosing not to address it. Thank you for your suggestion, and we can reconsider this at some time in the future.

comment:9 in reply to:  8 Changed 8 years ago by lazaridis_com

Resolution: wontfix
Status: closedreopened

Replying to peller:

![...]we're choosing not to address it.![...]

I have seen several tickets from other users, which were closed in a quite abrupt way by different team members. The users had sometimes a point.

The foundation knows that being "open" is not just talking about openness:

May I ask you friendly to clarify (in the name of openness) how and from whom the decision was taken ("we're choosing not to address it")?

I simply cannot believe that the team of a product of such scale ignores such an indisputable defect in that way.

Feel free to place the ticket on milestone "future", but please refrain from closing it again, at least not if it's not an open team decision. I have to insist on this.

comment:10 Changed 8 years ago by bill

Resolution: wontfix
Status: reopenedclosed

May I ask you friendly to clarify (in the name of openness) how and from whom the decision was taken ("we're choosing not to address it")?

Many of the committers monitor all tickets. We didn't have a special meeting to discuss this particular ticket.

We committers understand your position and that you find us rude. But do not reopen this ticket.

comment:11 Changed 8 years ago by Adam Peller

@lazaridis_com, we're not trying to be rude, we've just made a decision and we disagree. Your objections are noted. Please feel free to take this up on the mailing list if you wish to gauge support from others in the community or convince committers otherwise. The project is open, and this ticket is available for all to view, but decisions are made by committers. As a matter of policy we try to avoid lengthy debates in trac. trac is for quickly moving patches and tracking defects which committers agree to handle. Moving tickets to 'future' or hosting debates here creates a backlog so as a matter of policy try choose to keep trac tickets short lived.

comment:12 Changed 8 years ago by lazaridis_com

Resolution: wontfix
Status: closedreopened

My last attempt: you cannot close this ticket, don't you understand?

The project is not "open", because you say so. And the "ticket-policy" you just wrote down is invalid, as its not published.

See, this is a defect report which affects nearly all subsystems of the project. And I do not accept that it is closed in that manner, by one individual who states nontransparent to "we made a decision".

Even if the president of the foundation decides to close this ticket in that manner, I would not accept it, as it's against of what the foundation advertises about openness. I've chosen DOJO in favor of YUI, due to "openness", partly due to a very well written invitation (which you should possibly reread):

And what is now here: It seems that this here is about personal feelings, the "I hate Windows" issue, something that would be highly unprofessional.

As a contributing user, I've asked for an open decision (= public vote) subjecting this defect (after it was closed in a "wild-west manner"). I've done so, because this defect has a critical if not blocking severity for me.

I don't think that anybody get's hurt, if that ticket remains open (as it is in reality) until it is transparently decided if and when it will be addressed.

comment:13 Changed 8 years ago by Adam Peller

Resolution: wontfix
Status: reopenedclosed

please stop. You're way off topic now. If you'd like to discuss, improve or document the policy, please do it off trac. Open does not mean that every decision is open to be overruled. Please take this to the list to discuss or propose a vote (though I don't believe we've ever held a vote on a committer closing a bug, I suppose it's something the project lead could entertain)

comment:14 Changed 8 years ago by dante

I do not see this as a defect. I can't recall a single instance of a LICENSE file having a .txt extension, or at least that i've noticed. An example, the first thing I went looking for to see how they've done it was the Apache Foundation (as we've modeled ourselves after them):

None of the plaintext files have extension. Apache is a huge open source project. Perhaps someone has filed a ticket similar to this in the past years on Apache, but the resolution clearly wasn't to rename any files. I did not verify this in their bug tracker.

As a windows user, I typically "right click" the file and select "open with..." (as it seems regardless of the file extension, I want to open the file in something other than whatever windows thinks it should default to.

Seems we are making a mountain out of a molehill here? If your windows machine blue-screens because of our README and/or LICENSE files, please reopen this ticket.

Additionally, decisions aren't typically _made_ in trac. We very seldom have a "public vote" on any matters, unless the change would actually affect our users and even then it is only in good faith. The "D" in BDFL is dictator. Most open source projects are run this way. I would gladly entertain a discussion about this on-list, but as peller has repeatedly stated: trac is not the place to have these discussions, a threaded email is.

I disagree this is a blocker or a critical issue for anyone. Leaving it open would only result in someone getting their hopes or expectations up for something that will likely not change. Please refrain from reopening this ticket until a proper discussion on the mailing list has been had.

comment:15 Changed 8 years ago by Eugene Lazutkin

Let me try it. This is the problem in a nutshell how I understood it:

  • You complain about a problem you found.
    • It is a not technical problem, not JS, not CSS, does not affect speed, nor functionality of the toolkit, but loosely related to docs.
    • You inform committers about the problem by opening a ticket, which is exactly how it is supposed to be.
  • One of committers acknowledges the problem, yet closes a ticket as "wontfix".
    • Why did he do it?
  • You disagree.
    • What is your recourse?

If it were up to me, I would close this ticket just like Adam did. And I can explain why: I deem it insignificant.

Why does it look like that to me? I have two reasons:

  1. Because to date you are the only one to complain about it. That's why I agree with Adam and Bill.
  2. Because there are tickets, which are more important, affect the toolkit code, and provably bad. To rephrase it: time to go over all text files can be spend more efficiently on other bugs in the light of our limited resources.

Now, we are "open" regardless of what you think. Being "open" doesn't mean that any human being on Earth can hijack us and force to do something. Openness and freedom do not equate to anarchy. Please think about it.

So the best you can do is to raise this question in a public forum (use the mailing list, not a bug tracker for that) and gauge the interest. I am sure that given enough public support, the decision will be changed.

comment:16 Changed 8 years ago by Eugene Lazutkin

Almost forgot. The reported already posted this link: --- I hope he read the IRC section. We do have weekly IRC meetings, and the day is today! I think we can make an exception and actually ask committers to vote on this particular bug report.

@lazaridis_com: if you promise to be civil, you can come and address committers and contributors directly.

comment:17 Changed 8 years ago by Adam Peller

...admittedly, #dojo-meeting is at a horrible time for Europeans. Failing that, I'd encourage using dojo-interest for clarifying the term 'open'. It sounds like the website could use some clarification. I think it's one of the most overused and misunderstood marketing terms in the industry. lazaridis_com, we're not trying to shut you down, just move to the right forum.

Note: See TracTickets for help on using tickets.