You're not a bad person. Actually, I like that you question your decision, though that's probably confirmation bias because I use the exact opposite of your heuristic.
As I view it, any project has finite resources. You can spend them on your presentation or you can spend them on the product. Every hour that you're spending fixing typos on the website is an hour that you're not patching bugs in the code. Thus, when I encounter a beautiful, well written, well designed site, I mentally note that they've taken a lot of resources away from the product and caution myself accordingly.
Obviously my heuristic has a significant flaw - it assume that all projects have equal resources. A project with less resources can have lousy presentation and lousy code while a project with abundant resources can be exemplary in both categories. That's why I don't use it as my ONLY method of advising decisions.
However, your method also has a fatal flaw. Imagine that you're right and that the source base is an incoherent mess. It's pretty cheap to hire a couple of grad students to clean up the text on the page. They haven't done a damn thing to fix the mess in the code, but your heuristic now gives them an all clear.
> Obviously my heuristic has a significant flaw - it assume that
> all projects have equal resources.
Indeed. Perhaps my heuristic works for open-source projects because, if a project is "important" enough, some nutcase like me will come along and either complain about or fix their webpage. If the first sentence of their webpage has an obvious typo, that's a signal that maybe there aren't enough people who care about the project.
As I view it, any project has finite resources. You can spend them on your presentation or you can spend them on the product. Every hour that you're spending fixing typos on the website is an hour that you're not patching bugs in the code. Thus, when I encounter a beautiful, well written, well designed site, I mentally note that they've taken a lot of resources away from the product and caution myself accordingly.
Obviously my heuristic has a significant flaw - it assume that all projects have equal resources. A project with less resources can have lousy presentation and lousy code while a project with abundant resources can be exemplary in both categories. That's why I don't use it as my ONLY method of advising decisions.
However, your method also has a fatal flaw. Imagine that you're right and that the source base is an incoherent mess. It's pretty cheap to hire a couple of grad students to clean up the text on the page. They haven't done a damn thing to fix the mess in the code, but your heuristic now gives them an all clear.