Welcome
Welcome to the brainstorming group for the 2014 Drupal.org roadmap! This group is to help the Drupal.org Software Working Group gather community input into the 2014 budget and plans for Drupal.org improvements. Please read the announcement for more background/details.
Latest ideas Most popular Recent Comments
To participate:
- Review the list of submitted proposals and "vote up" and/or comment on ones that speak to you.
- If you don't see your idea reflected, propose your own ideas using the idea template.
- While we want to hear about everything that's on your mind, we're especially interested in small, but impactful ideas.
- Proposals are wiki pages, so feel free to provide additional details in other peoples' proposals; think of them as "issue summaries" for ideas, so keep them neutral.
Voting/feedback will considered until 00:00 GMT on September 6, 2013, in order to give us ample time to make a proposal (which the results here will be a part of) for the Drupal Association Board Retreat prior to DrupalCon Prague. Thanks for participating!
Subscribe with RSS 
Recent comments
I'm not sure about this one
I'm not sure about this one anymore, TBH... because of the extreme lag between when the community was excited about this originally and when it would actually be feasible to implement, http://drupal.stackexchange.com/ seems to have gained a lot of momentum (about 13,000 users and 30,000 questions).
It'd be interesting to hear from some folks who provide Drupal.org forum support though on whether or not these tools would be helpful to them.
Expanded the title...
I expanded the title slightly here, as I'm not sure people outside of the implementation issue for this would know what this meant at a glance.
Projects already have a few
Projects already have a few of these already, but they're all over the project page:
(I could've sworn there was something that indicated whether a project passed Coder review, but I don't see it now.)
Perhaps if these types of indicators were aggregated into one spot and made more prominent? I could see the calculated rating working, too: it'd essentially be a CTR score for projects.
More objective module health
More objective module health indicators could work really well: I like your idea above a lot.
The extremist side of me
The extremist side of me would like drupal.org to be a wrapper on top of github but the realist in me doesn't think that will ever happen.
@Mark Trapp I think that all
@Mark Trapp
I think that all of your feedback is completely valid. Using ratings and reviews will introduce a number of problems.
However, the stated goal of this idea is "to help site builders determine quality of projects on drupal.org site by adding various indicators to project (module/theme) pages."
How do you feel about using other, less-subjective indicators to generate an aggregate indicator for module health? Clearly, the method for this aggregate indicator would need to be well-thought out, and have a significant degree of community buy-in.
Also, I agree that the 'like' system would be much friendlier.
I agree that this is a major
I agree that this is a major UX issue and would really help to push Drupal into the hands of the more mainstream, novice users. I built the Project Browser contrib module (https://drupal.org/project/project_browser) as well as the server module (https://drupal.org/project/project_browser_server) and pushed for inclusion in Drupal 8 Core, but there we weren't able to get the server module up on D.O in time to see much progress. I was also finishing my school finals during that time and so wasn't able to spend as much time as I had hoped on it. I'm still very interested in seeing this see the light of day, and will again pledge my support to getting this done!
Backlinking issues, too?
I'd love to see this for referencing issues, as well: Github does both (example) and this type of stuff definitely makes it easier to follow along.
There's a lot more risk
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).
UX studies have confirmed
UX studies have confirmed that the lack of an in-app project browser in Drupal is a major impediment to new users. This is an extremely important issue to focus on. Once we have project browser information available from D.O, we can get traction on the contrib side and make progress towards introducing a browser in to the next version of core. I can't support this enough!
Move all of issue tracking and SCM to GitHub
Really I think Drupal could benefit by moving all of the issue tracking and SCM over to GitHub. It seems like a barrier to that would be packaging releases and automated testing. It looks like the team at PreviousNext has figured out the testing problems http://previousnext.com.au/blog/automated-drupal-testing-github-pull-req... and I don't think it would be too tough to get the release manager to look to GitHub for generating releases. We could then dedicate fewer resources to maintaining to maintaining a project management system and spend more time on other improvements to d.o. Man other open source projects have moved to GitHub so it may even reduce the barrier to entry to contributing to Drupal.
"The goal is to help site
"The goal is to help site builders determine quality of projects on drupal.org site by adding various indicators to project (module/theme) pages."
Absolutely agree. There are a few types of indications that we can add. A simple rating would be helpful, but I'd also like to add a more comprehensive indicator: module health.
The module health rating should be a calculated rating, that uses an algorithm based on existing criteria to determine module health. E.g., maintenance status, open bugs in issue queue, last commit, installations, active issues, etc. This indicator (and also a rating) could be used with the proposed project browser to help new Drupal users make good module selection decisions.
Great idea -- pull requests are a superior workflow
I tried to make the drupal.org workflow better with the Drush Issue Queue extension; while this tool has made it much easier to create patches, interdiffs and new releases on drupal.org, it still falls short of the pull request workflow. Also, when drupal.org is ported to Drupal 7, drush_iq will break, and probably will not be updated. Most of my work in the issue queue has been in the Drush queue; Drush is on Github now, and Github has the 'hub' cli. The pull request workflow is a really big improvement.
Another thing to consider is whether all drupal.org projects should be migrated to GitHub. There is a big advantage to having all of the Drupal modules within the purview of drupal.org. Drush isn't as tightly integrated with the rest of Drupal as contrib modules are; there would be a cost to just migrating contrib out. However, it is also hugely complicated to integrate a large website like drupal.org with a git workflow. Porting project project to Drupal 7 added a lot of extra work to the d7 upgrade for drupal.org -- and it will have to all be done again for d8.
GitHub has an API; perhaps an easy way to provide pull requests on drupal.org would be to utilize that API, and find a way that drupal.org project pages could be integrated with the GitHub repository they are associated with.
Regardless of what means are used to achieve it, it would be great to have the pull request workflow on drupal.org.