[...] You never -- never -- EVER deliver bug reports insultingly, or even with a sense of entitlement. It's just "This doesn't work. Here's how you reproduce it. Here's diagnostic information to help you track down the problem. Maybe even here's a patch to fix it, depending on the community this is." Your attitude in the posts (albeit not in the actual bug reports) was "This doesn't work. You fucking retard. Never let us hear from you again until you've fixed it.

If there is a claim that the software works, then the context is different. It's one thing for software to mostly work but have a few bugs, and another for it to not even run at all no matter what the circumstances; that's not just a bug. One could get technical and say that the software is still running, which is true: the code is always doing something, perhaps just sitting in an infinite loop due to it being defective. Along these lines, *any* collection of random bytes is a NES program (a completely relocatable one, at that).

It's kind of like Microsoft saying that their software has no bugs, that users only need to upgrade to new versions if they want new features. Then a bug report is justified in having an angry tone.

I think one of the biggest dangers to any console development community is a lack of distinction between accurate and inaccurate information (and programs). If one wants to do console development but can't figure out what the correct information is, one is going to be frustrated. If a person spends time putting together some information but makes unwarranted claims about its accuracy, he might justifiably receive criticism. That he spent time on the information is irrelevant; what's relevant is that he "diluted" the purity of available information. Properly labeled information preserves purity, even incorrect information, or pure guesses; it simply needs to be labeled as such.

This is a really important issue, having certainty about things. In programming, if one is uncertain of something, code might grow and grow around this, based on all the things the programmer imagines and tries to deal with. I think it's really important to work on having correct information that people trust and take full advantage of. For example, adding CLD in NES startup code might be entirely redundant, but people put it there because they're not sure. Uncertainty and speculation are fine where it can't be tested, but where they can they cause needless complexity and lack of clarity.

As an example, I'm putting up NES APU documentation on the NesDevWiki; I haven't yet put clear notices that the information is my interpretation of tests I've done, rather than a known-correct description of the hardware (unlike my APU Reference, which has a clear disclaimer). It might be correct, but I can't make that claim. Without this disclaimer, I'm diluting the purity of NES information. I could add a section with the code I've run and the raw data, so anyone could draw their own conclusions. In this case the raw data is distinct from my conclusions (which may be wrong). If the NesDevWiki weren't still under construction, criticism of the lack of disclaimer on the APU information would be warranted.

The notion of "dilution" I'm using here is similar to trademarks: if the company allows other companies to use the trade name, the name loses its meaning for the customer. It once meant it was from company X, and if they had good products it could be depended on, but now it isn't an indicator of this. When the distinctions between words are blurred, the ability to communicate clear information is reduced.

We clearly have irreconcilable differences involving the moral stature of people who write buggy code to standards only dimly understood, and that through reverse engineering. I'm going to keep cutting them slack, but aim to get them accurate information so that they can produce stuff that works.

I think the standard being applied is one anyone can meet: accurate representation and a clear distinction between the NES platform and the environments that NES emulators provide.

And to repeat what I said in a previous post, I don't think being overly critical is a productive approach.