Recent comments

The proposal you pointed is about user reviews only.

I agree metrics would be a better way to filter crap if these metrics are based on points like:

• follow coding standards
• uses the API correctly
• has documentation (including in code)
• has not been flagged as duplicate

And maybe even more points. Having an "approved seal" to the projects that meet all these points.

Maybe making this "approved seal" optional and delivered to projects which are submitted to an quality review? (I'm feeling like changing the proposal)

Added a very significant risk, which is that the more barriers you throw in front of contributors, the less likely they are to contribute. The very real risk is that we end up with fewer contributors and less open source Drupal code if we do this. Are we sure having fewer "crap" modules is worth this risk?

FWIW, I believe we should do the exact opposite: put decent quality metrics on projects and "filter on output, not on input," just like Drupal.

Wow! You have noticed very right problem in Drupal. First documentation required better URL for SEO than issues.

Sounds good.
But we need to focus on not only approve or disaprove the module, more than this we need to make it happen.
In case the module doesn't pass the criterias, if the idea has potential of being helpful for the comunity, it could go for a "Needs work" list with some feedback.

Regarding dogfooding...

Would it be possible to base the architecture on an existing job scheduling system like Jenkins? It seems as though Jenkins was developed for exactly this purpose: automating job runs. In fact, I think it was set up for automating software builds, and running tests on every uploaded patch seems like exactly the type of thing it's set up to do.

And of course we are already using Jenkins for many other d.o infra tasks, such as cron runs, software updates, etc., so it seems as though we probably have some in-house expertise in using it.

I like the idea but PAR review is just not possible. It takes way too much time and effort and it is no fun at all if you have to read 1000 lines of code with no interest. Our PAR review team is doing their best. Now we even have PAR bot :). I think the realistic thing to do here is create a PAR bot gate for new project promotion which check for coding standards, directory structure and etc. No human can do full-project application review.

What color should the shed for the hover bikes be?

I'm comfortable leaving it wide open while we're in this brainstorming phase. It's good to check in with the community* and understand things they are/are not comfortable with, the specific features and functionality that are critical to them vs. nice to have, etc. The last time such a check-in was done was about 2 years ago, and community has doubled in size since then.

But fear not; as mentioned in the original announcement, the D.o SWG isn't just going to take the top N features and say "Yep, that's what we're doing in 2014." (For one thing, idea 2 and idea 3 are the exact opposite of each other! :D) What we are going to do is take this feedback into consideration when putting together the 2014 roadmap. We'll also have to balance other priorities, like essential maintenance, improving tools and processes to allow people with "itches to scratch" on Drupal.org to do so more easily, and business-friendly features that will actually allow us to pay for these improvements. :P Since Drupal.org has been in "feature freeze" for over a year, we're most likely going to be starting with smaller, easier-to-implement features while we perform detailed discovery/analysis on some of the thornier problems identified here to determine the best way forward.

Also, remember that we'll be doing another round of ideation in mid-2014 with a much longer lead-in. Not sure exactly what form that will take (voting or surveys or etc.), but hopefully it can be way more inclusive and representative of a larger spectrum of the full Drupal community (right now we're hearing mainly from the "insider" crowd, and mostly developers).

But yes, "What will Drupal.org be like in 2018?" is a very interesting thought exercise. If we want it to be both the centralized collaboration hub of the community, as well as a shining example of what Drupal can do, we're going to need the DA to increase revenues significantly in order to afford a team able to create improvements apace with community needs, and we're also going to need dramatically more community volunteers working on these tools than currently do. If we want it to just be a simple "brochureware" site that links to elsewhere where the community actually interacts in small, separate buckets (SE, Github, etc.), well, then we don't need either of those things. But that would definitely gut one of the main benefits of Drupal, IMO.

From my own little experience, the only questions I've seen closed on Drupal SE site were badly written ones (eg. question written as 80% rants and 20% actual question), questions barely related to Drupal (eg. how to woraournd something in Drupal using .htaccess without any PHP because "I'm not a dev."), questions that clearly show that the poster has no even tried to find a solution by him/herslef and thinking about it (eg. how do I create a page with custom PHP code), or questions requesting for (trivial) custom code istead (sometimes the poster shamlessly acknowledge they have no will to learn Drupal and how to do it him/herself).

Now some may feel that these kind of question are still valid and that someone should guide the poster to correct his/her behaviros it in order to provide complete support and get one more happy Drupal user. However, community provided support is not paid customer support where the satisfaction of a paying client is the mean ensure the goal of getting paid. I suspect only a very small part of the community want to support those who don't even care to support themsleves, are relunctant to learn and are only guided by selfish interest of getting their own things done as quickly and cheap as possible. IMHO, these kind of people are not wanted on SE sites. Nor sould they be wanted on any community support solution. They are toxic to the community.

And yes, sometimes SE moderator can be arses to wotk with. Sometimes to jump to conclusions. Sometimes they close a discussion too quickly, for the wrong reasons, without taking the time to reconsider. Just like any human being. Just like project maintainers in support queue. Just like moderators in a forum. Except they have different rules, rules that the support team from Drupal.org has not helped to define (or did they?). That's why each SE site as a meta site associated. That's why moderators on SE site are elected. And that's why the SE staff is also available to resolve issues with a the moderators.