Reviews and ratings for projects

I think the risks here are very understated. Reviews/ratings have innumerable problems, not least of which are:

Reviews are used as stand-ins for support requests and bug reports.

It's hard enough as it is now to get useful feedback and bug reports. Anyone who develops for the App Store can tell you how frustrating it is that, instead of getting a bug report, people submit negative reviews when they encounter a problem. It doesn't matter if the developer is the most responsive in the world, it's so much easier for people to leave a negative review and walk away than it is to work with a developer to get a bug resolved.

There's no incentive for developers to care.

Unlike Amazon reviews or even App Store/Google Play reviews, there is no incentive at all for developers, only negatives, because they're not selling a product. HIgh ratings in a store = more sales, which means more revenue and profit. High ratings on Drupal.org = what? More downloads, which translates to more unnecessary support requests, more chances for clueless ratings/reviews, and more headaches.

Conversely, there's no developer accountability. What happens if a module gets a solid 1 star rating? Elsewhere, that translates to low sales, so people are incentivized to maximize their review scores. That doesn't exist on Drupal.org. If I create a module that's maybe downloaded 50 times and gets nothing but 1 star reviews, what incentive do I have to care? I could just say, "I contributed my code back, job's done." Heck, what would it matter if, say, a really popular module like Rules had a 1 star score?

What if you do care? What a morale boost it'd be to get a crappy reviews for something you contributed back, for free!

Ratings are completely subjective.

Let's say you have a five-star rating system. What's the difference between 2, 3, 4, and 5 stars? What if it's a binary rating system (good/bad)? What's the difference between a module being "good" and "bad"? If a developer doesn't implement a pet feature that only I, out of 400k people using it, need does the project reserve a bad rating? Why or why not? People's subjective opinions and personal preferences do not translate into an objective quality rating.

And that's when people grok the rating system: people confuse the top rating with the lowest rating. Go to any site that implements a rating system and note there's always people who give glowing reviews and... one star.

A rating system that isn't subject to abuse is incredibly hard to get right.

It's fairly easy to make it one account = one vote, but what about mass account creation? Vote brigading (e.g., "Hi, I'm [insert popular Drupal developer here], please go vote up [insert project here]")? What's the recourse for users who notice vote fraud?

I also think it's important to link to the issue to implement this in the Project issue queue, where there was a ton of feedback about this, echoing much of what I summarized above.

If this is ever implemented, at a minimum this must be disabled by default (i.e., projects are required to opt-in, not opt-out) and reviews should not be prominently displayed on project pages. Make it a link in the sidebar, next to things like "Read documentation" and "View repository".

Alternatively, I think a starring/liking system—a la Github—might be a better way to go. It'd have no friction, avoid being confrontational to maintainers, and provide a better indicator of popularity than site installs has today (which is passive and relies on having update enabled, something many (most?) sites in production don't do).

Force full-project application review for ALL projects, not one time only per user:
https://groups.drupal.org/node/314058

It will improve project quality, then better search results list.

Mark and others capture the delicate nature of ratings and the critical thinking of engineers that will not necessarily value mass random ratings even if implemented. Another point to consider is that ratings will/can deter new module maintainers from trying out their modules. After all, who among us wants to get critiqued and criticized for work we're coding for free? Ratings may have very unintended consequences and make becoming part of Drupal off-putting.

The Band-Aid of Rating Modules
Ratings are a cry for help as a symptom to the underlying problem. We want ratings because stabilizing modules for a project is a time-consuming black hole of researching, downloading, testing, and patching before they can be used. And if you don't have this horsepower to patch your own modules? Then you end up at the head-banging end of the line. 

I've taken over too many failed Drupal projects in past years. I can almost narrate the entire project trajectory by looking at the installed modules. Five different slideshows, dozens of this and that all in different states of enablement. I can tell how hard the developer tried to meet the project objectives and what the client requests were. This is where we fail ourselves in thousands of disappointed clients and frustrated new developers daily. This is why so many site owners, site administrators and content managers hate Drupal. We fail them. We advertise a powerful module ecosystem but we don't show them the fine print: it mostly works if you're an engineer and our modules are mostly fixer-uppers. We want ratings because the quality and stability of modules is potluck.

Why Are Modules so Variable?
Tricky bit here. In varying parts:
- I'm doing this for free.
- I'm new. Stop hurting my feelings.
- I'd love to work on this but I have to pay my bills first.
- It's the best I know how to do.
- I'm tired.
- Modules are often written for projects with their own use cases and assumptions. My client pays me to write a module, works great for their requests, I submit that module. Mostly works for anyone else but it's understood that you'll be tweaking it for your use case.
- And today: "Want it fixed, send me money" This last bit is harder to quantify but I've spoken to enough maintainers and clients who have done plenty of transactions this way. I worry this is why Drupal.org issues queue and patches have flatlined since 2011. Data welcome to the contrary.

So What Will Work?
We need a thoughtful injection of revenue that rewards good maintainership standards in a sustainable, open-source manner that doesn't compromise our open-source ethos.*

- A community who understands that building their business on free work is a failed premise. 
- Standards around documentation, UX, interoperability, accessibility and more.

Looking at the aggregated pain points that range from the heavy investment of time**, to project failures and a looming Drupal 8 launch; the landscape looks sketchy at best.

Ratings and metrics address the symptoms, I say we look at the tough, scary, complicated issues that are at cause and arrive at good solutions. This is our technical debt – we can clean it up.

-----------------------------------------------------------------------------
*We applaud GitTips and any other form of recognition to those doing the heavy lifting. However, you can see what the most famous in Drupal are earning. There are 20,000 maintainers. I don't think this sum is going to encourage them.

Annualized Chart from GitTips.com/for/drupal, the current top 12:

**The argument that these are client-billable hours is a non-starter. Would your clients NEED to pay for this if modules were better? No. Does this time benefit their project with great engineering features? No. Does this make Drupal a stellar business choice? No. Just because they WILL pay for this time doesn't mean that they SHOULD. They're paying because modules are not necessarily in a high-quality, enterprise-ready state. And there are plenty of projects that can't absorb the time actually spent. That's money taken straight out of the bottom line.

I have personally found that the general ratings given tend to mean little in practice.

The module comparison pages are far more useful, as would the "Related projects" block if it actually was doing it's job...