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
PS Sorry this is late
My apologies I'm submitting this idea late ... I was on vacation!
more integration ...
I just had some more ideas how a native QA could be integrated into D.O.: Let project maintainers select QA that get pulled into a special "FAQ" view/page linked to the project (this one seems low effort and would be such a win).
I think it would behoove the
I think it would behoove the overall objective to improve the issue-queue / patch etc experience than to just shift off to GitHub - it will create more problems than it solves.
Backdrop's issue queue
The new D8 fork by quicksketch, Backdrop, uses github. You'll note that they had to set up duplicate projects to manage the project's issues "because of Github restrictions on the use of labels and issue assignment". Food for thought.
Open-source options
Redmine does too, if we'd like to self-host. I'm not sure if GitLab has this feature.
Redmine FTW!
Here's another reason to go with Redmine then. ;)
I'm not sure if Gitlab has this feature as I haven't looked at it too closely yet.
Great Dialog
I love this idea too. We would need an opt-in for each project so as not to embarrass folks whose modules may not make the grade. It's encouraging to see us talking about standards, issue queue maintenance and more. Here's a graph that may be interesting: http://topshelfmodules.com/2-graph-of-drupalorg-module-health.
And yes, the algorithm can be tricky. We could beta test it on Drupal 8 releases. There are only a couple hundred of those...
Addressing the Root Cause
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.
@MJOC: Exactly, the metrics
@MJOC: Exactly, the metrics are what makes sense. Some might even include 3 'variables' relating bugs, users and commits.
As you say, a project with 10,000 users and 3 bugs with 1 commit/month is in fine shape -- it's down to choosing some mathematics that mirror what D.org wants to improve.
I'd argue it's the projects that are popular that have been left for a while that need most help -- the ones where the maintainer(s) are busy doing something else or MIA -- or the D6 branch is festering but still has >5,000 installs. In these cases we WANT the community to step in and offer help, or pester the maintainers to allow more co-maintainers to get things moving again.
I worry that Drupal will die a slow, bloated death if it continues having so many great projects fade away, getting to beta 4 but never a 1.0, or lots of RTBC issues hanging around... And what message does it send to new or existing legacy users if (for example) as soon as D8 is out the million+ D6 sites are just left to it? We need a way to get projects and people together.
The theme doesn't have to be
The theme doesn't have to be released under the GPL for collaborative bug fixing to take place... Why not stick it in a repo under a proprietary license or under a CC license - something which maintains DA/Dries ownership but allows it to be downloaded and have bugs fixed with all contributors agreeing that contributions back to the Bluecheese repo become the sole property of the Drupal Assoc?
Seems to me that it would remove the legal issue and allow the Drupal community to do what it does better than anyone else and collaboratively fix the problems with our 'home'?
I think this may stifle
I think this may stifle collaborative development where having a full project makes it easier for Drupal users at large to get involved with projects... There seems to be less involvement with Sandbox projects from the community at large...
Love this idea!
Love this idea!
But we should be careful about exposing unhelpful information to users. Just because a module has 1 commit per month doesn't make it an unhealthy module. It could be perfectly stable but have reached a point where there aren't logically new features to add and the module has no known issues. Showing that as unhealthy wouldn't be accurate.
Perhaps commits in relation to open bugs?
Love this idea!
Love this idea!
GitHub DOES have this
GitHub DOES have this functionality - it shows an XXX referenced this issue post where the issue number is referenced in another issue.
No,Sorry for the blunt
No,
Sorry for the blunt starting point there but there are those of us here who run businesses and when we have time we contribute back modules that we have spent time and money developing and reviewing. Having to spend time reviewing other code to get these modules on Drupal.org is not going to be appropriate.
It would certainly discourage my business from contributing back to Drupal.org (Currently maintain 6 modules and 1 theme with no major issues on any project and all projects meet coding standards) and would increase fragmentation and I'm pretty convinced that other business contributors would take a similar view. Drupal has procedures to address poorly written or maintained modules - namely people don't use them and they eventually die. I'm not convinced that adding to the workload of project reviewing teams and complicating the workflow of people who may have been writing Drupal modules since Drupal 1, 2, 3 etc.
Sure, it could clean up Drupal.org but it's actually more likely to hurt in the long run, Drupal's advantage is that modules and themes are in one place not fragmented across the web. I'd rather keep that advantage, including the badly coded modules, than loose it and have Drupal end up resembling Wordpress with modules spread across various sites of widely varying code quality - that's not a Drupal I want to see.
There's enough work for module developers with coding and testing their modules without additional administrative overhead, if you want to make code quality better on Drupal.org - get involved, write issues, take maintainership of modules where the author won't fix problems instead of standing on the sidelines (that's an assumption on my part, some of the commenters in favour may be valued contributors but it doesn't seem evident in the tone of the original proposal) and lamenting the lack of 'decent' modules.
But all those "extra steps"
But all those "extra steps" (which are really condensed to a git push) end up with cleaner lineage. All too often, patches end up on d.o and never get merged by the maintainer to dev branches, let alone releases.
Swarming is possible with PRs
Swarming is possible with PRs as long as the issue is associated to a branch any any authenticated user can pull and push to.
I agree. Drupal.org wins
I agree. Drupal.org wins hands down. But this does not preclude a move to Core; it just means that some work needs to get done first to integrate GitHub with the Drupal.org issue tracker.
Yeah, but new contributors
Yeah, but new contributors are already pretty much shut out from the process anyway (it's a culture thing). Those contributors can just do a regular pull request and it will still be an improvement over the current status.
I thought this whole argument was about getting the core devs happy with a process. If you're really interested in getting those new contributors up and running, then GitHub wins hands down. But that's not what I'm hearing from the anti GitHub move proponents.
This is a completely flawed
This is a completely flawed premise for one major reason:
There are no trusted devs. I have to go about 100+ names down http://ericduran.github.io/drupalcores to find someone I don't know well enough to give write access to from the start. And new contributors would be completely shut out from that, preventing them from participating in exciting or major issues.
If I hadn't been able to jump into an issue with a small tweak or improvement or addition at any time without someone's permission, I wouldn't be the developer I am today, and I especially wouldn't be involved in core.