From what I remember of reading "Googled" by Ken Auletta when it came out, Larry and Sergey didn't have a business plan initially, even after getting venture funding for Google. They tried to make the best search engine they could and assumed money would somehow follow if they developed a great product. After a couple years, I believe the first idea they had was farming out their search services to places like Yahoo -- which iirc was their first deal. When that didn't keep the VCs happy, they gradually became more advertising oriented and never looked back.

So I don't think they had a plan to make money to start with, which is why I initially took issue with the original post when I read it. But I suppose it's fair to say that their original plan was selling search services to other search providers. Is this what you are referring to? (Am I misremembering part of Google's history?)

Very good. For anyone else that wanted to find the source of this, this website: http://www.skypoint.com/members/camilian/humor/SantaAnalysis.shtml claims:

"This was sent via e-mail a couple years ago, circa 1996. Therefore the author's information is unknown."

If someone has more information on the source I'd like to hear it.

I know. Don't they secure these things using NAT?

We used to use RIP, too. And later, RIPv2. RIP RIP.

Part of what I was saying, for the original asker's question anyway, is that the devs should be working with the ad hoc QA team to help them understand when they haven't given enough information. I understand that the list you gave feels like enough, but for almost any application, the devs will also most likely need the software version and the operating system you were using. For different applications, there may be other things, like a copy of the config file or command line arguments. And any other information, like if it ever worked, or if it never works and you can reproduce it every time on a fresh install (and if there are multiple install methods, tell them which one). That's the kind of feedback they should be giving so you know what they need to fix the problem.

I had an interesting experience in high school when a teacher brought in supplies to make PB&J sandwiches. This seems to be a pretty common lesson: everyone in the class had to write a procedure, and the teacher followed their procedure to try to build the sandwich -- with anything that had to be interpreted being interpreted wrongly. The instruction "open the jar", like "open app", could mean different things to different people. For a dev, opening the app could mean running it from the command line, whereas you might have a desktop link that gets installed by the app's installer (and possibly uses some arguments that the dev won't have put in when running from the command line). Naturally I don't know your software, but the take-away is to be as explicit and unambiguous as possible.

Sometimes that's because the difference between a defect and a feature request is only identified by the requirements document that was never given to QA in the first place. But yeah, it happens sometimes.

You haven't told us anything about what you've done to educate the staff about writing up defects. Have you done anything? Unless they also work as technical QAs, they almost certainly have no idea what is expected in a defect report.

I'm surprised that the primary problem doesn't have to do with listing ambiguous steps to reproduce a defect. For example, "I went to the page again" vs "I clicked the link again" vs "I closed the browser, reopened it, entered the URL, and then clicked the link on the page again."

Of the 3 things you mentioned (#1: screenshots of the YSOD that don't include the page URL, #2: scaled screenshots that are unreadable, #3: the complaint that wants to be a bug report but is still just a complaint), the first two sound like *you* are complaining -- if they're not technical people and they don't know how your system works or what you need to see in order to diagnose a problem, then the first two issues should have been expected.

How do you solve #1 and #2? If you're asking users to perform rudimentary QA, you're going to have to work with them. So, the solution to the first two problems is for you to realize you need to help out in these situations, explain what was wrong and what they can do to fix it next time. They don't know what you need in advance. Progress will be incremental but sure. And if they have to do all this in addition to their other tasks, then be nice while you're doing it.

How do you solve #3? First, if people are complaining then make sure you're not overreacting to a real usability issue and ignoring it because it's not in the format you wanted. Then mail a template with a description field, a steps to reproduce field, an expected results field, and an actual results field, with a description of what each one is. Have a meeting explaining how to use it. Give examples, especially highlighting the need for detailed and unambiguous steps to reproduce.

As bad as e-mail is for tracking issues, if this is a short term thing it may be the best approach. If you can see this going on, getting away from e-mail is a very good idea. Having recently been through a issue tracking system transition, getting everyone used to the new systems took some time even though it was handled very well (and not by me).

Perhaps this has something to do with it?

http://dilbert.com/2011-10-07/

Spam doesn't have to be unsolicited. Consider the following conversation:

The Man made a request for information ("signed up"), yet was undoubtedly spammed. And this by Vikings.

Consider further:

Imagine you receive 5 junk e-mails per day from a site you've never been to. You make a remark to your friend about receiving spam messages. He suggests that you visit the website that is sending you the spam so you can officially sign up for their mailing list. That way, he suggests, it will no longer be spam.

This isn't entirely meant to be humorous... the term "spam" doesn't become inapplicable when someone asks to be spammed.

What about GRE, IP-in-IP/IP6-in-IP, and tunnel mode AH for IPSec? These are all common tunneling mechanisms that do not use encryption, though as you said, they'd have to be supported in the software. I'm prepared to be wrong on this as I don't work with small business equipment, but I would imagine the lowest end boxes that will provide an IPSec VPN will let you do an AH-only tunnel.

Interestingly, some open source IPSec implementations will even allow "encryptionless" ESP tunnels, using "null" ciphers for the ESP encryption. The (old) setkey utility for Linux (and BSD?) allows you to set this, though other utilities will not. Not very useful for anything, but it's another example.

Is that Tolkien Ring?

God bless you, Dr. Kevorkian

God Bless You, Dr. Kevorkian

That's the way it all feels sometimes, isn't it?