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
@lisarex. I'm not arguing
@lisarex. I'm not arguing against that, but those users are already well versed about Drupal. They probably been in the community for some time and many most likely have developed a passion for it.
What I talk about is mainly new users and those who use Drupal to build sites with. They have not the same level of community belonging, nor passion and nor have they the same familiarity of things.
Maybe we need to have a discussion about the scope of user support that drupal.org should have as goal to provide. Where should we draw the line and give third party sites the opportunity to step in and complement.
However, this needs to be done right. Drupal.org needs to at least provide some basic beginner and user support. I think it is important that we will help guide new user taking their first steps with Drupal. To at least get enough good taste of it to want to continue.
Lets not also forget that the issue queue support is valuable to triage if there might be a bug involved or not as well. Or in many cases highlight the need for improvements.
Google is the weapon of choice
tsvenson, I think it's the other way around. From my UX research with developers, nearly all of them use Google to research and troubleshoot their Drupal issues, so they'll see SE as much as d.o. ... and they'll see the value of SE and won't hesitate to sign up.
I don't think that changes anything
Just because we're already doing something, doesn't mean it's a good idea.
I actually really dislike going to a module page and seeing that the code is elsewhere, like github.
I can see that it might make sense for non-module things like dreditor and drush, but for modules I find it very annoying.
Even worse are the ones that don't even have releases on the drupal.org project page.
I find it gives a very incohesive experience.
I think it is much easier if everything is in the same place, wherever that place may be.
Yes of course. UX is always
Yes of course. UX is always involved when you do something, no matter what it is.
But, you also need to understand how UX is involved. In this case users will come to drupal.org and be faced with its unique UX. They would click around trying to figure where they will find what they need and so on. Then, when they finally find the support stuff, they we be pointed off-site and be told they have to get exposed to yet another UX. An UX that that both require them to create an account on a non drupal site and spend time learning how that tool work.
While the SE UX is pretty good if you are already technically savvy, it is vastly different to anything Drupal offers. Also, the UX they face is not only how the site works, but how the users there us it.
I remember when the first time I made an attempt to test building a site with Wordpress. Sure it was no problem finding plugins, but the user generated info on wordpress.org was completely useless and outdated. Instead I was pointed to the plugin developers preferred choice, if any, for where to find that. In many cases that was their own sites.
While I don't question a redirect like this would make many choose SE for their project support, it will at the same time open up for a big possibility that many opts for something else. Maybe they see it as an opportunity to help promoting their own personal blog, corporate site and so on. Nothing would prevent them from moving the support there.
And then the UX fragmentation begins...
Define consensus
I freely admit a bias here, but I don't recall any strong voices against doing this other than you and sun. sun's concerns (the airplane switch) have been addressed upstream.
The big blocker isn't consensus, it's the ability of the infrastructure to even do it. That's what this thread is asking be done (which does fall to the DA or a working group therein). Once there's no technical barrier to "doing it right", I think consensus around that will be a lot easier to achieve.
We already switch between systems...
We're already switching between GitHub and D.O for contributions and issues on several projects. Some projects just push to D.O as a secondary remote.
Consistency
I think it's already annoying enough for users to have to switch systems.
Making it so that users have to be across two systems and switch between them depending on what project they want to contribute to would be more confusing and annoying to users who are trying to help out.
It's all about UX, right? ;)
It's all about UX, right? ;) SE has a better UX than d.o forums (right now, at least).
I'm sure a good copywriter can craft a good message to explain why registration is worthwhile and why this is not about shunting people away but about giving them the best answer on the best platform for answers.
Why all or nothing?
Why should the only two options for the repositories be moving to GitHub or keeping them in D.O? (I'm including changing to self-hosted GitLab and similar ideas hosted on Drupal.org in the latter group.)
Why not allow project maintainers to choose where their repository is hosted and their preferred workflow for their project? For the project page, they'd just need to tell Drupal.org where the repository is hosted (and perhaps even what branch applies to what Drupal major version).
Content, Tools, Infrastructure...
A huge amount of Drupal.org is text and images written by humans for other humans -- and in that sense, I think of it as content.
The DCWG's charter means that we're primarily focused on certain kinds of content on Drupal.org -- the documentation section, the issue queues, and bits like that -- are outside our domain. The issue queues are an interesting example: they're full of content, but it's user-generated content outside the purview of drupal.org editorial process. The act of working in the issue queue is much more complex than (say) reading a case study, and its UX needs more and different attention on the software side.
But the content itself is tangled up in the 'UX' of using Drupal.org, just as the software that drives it is mixed into the act of reading and maintaining the content. The DCWG definitely has its hands full at the moment, and I don't want to suggest that we should be tackling anything more, but I'd hate to see a UX strategy and a content strategy emerge in isolation. If there are conversations coming together I'd love to set up lines of communication to make sure we share useful information and insights.
@chx I know you aren't, and
@chx
I know you aren't, and many with you. But to learn that takes time. For a potential new Drupal user there are many obstacles on d.o to overcome before stuff begins to make sense.
To then be booted of to a completely different site, that requires both a separate account and time to get to understand, will in many cases don't give a good first impression.
In short, this isn't about us having the best intentions for new users, it is about the message we send to new users and how they might interpret it.
Now..
We aren't, there are a lot of really high profile developers answering on drupal.SE (including me) it's just that I know my time creates much more value if I answer there.
Hard to identify the right answers
There are some issues that have multiple solutions to a problem, sometimes even improper answers. The voting in SE really helps with this issue and identifies, by the community, what is the most proper solution or in some cases multiple solutions that can achieve the same result. I am very in favor of shutting down or sunsetting the support forums and pointing to SE.
Changing the way Drupal core
Changing the way Drupal core is packaged is not something that the DA can or should be willing to touch with a 100-foot pole unless there was consensus reached, or a directive from Dries, on the "parent" core discussion at https://drupal.org/node/1475510.
However, making testbot more flexible sounds like a great task for core developers interested in at least opening the doors for this flexibility.
Do this, and I'm done with
Do this, and I'm done with posting code to drupal.org.
+1 for both phing and behat
+1 for both phing and behat
This fits with or desire to
This fits with or desire to look at using behat for functional tests
Also phing is worth looking at for testbot builds, so then you can replicate the build locally
Drush Composer
As far as I know, the Testbot has Drush installed. If downloading composer.phar is not an option, it could in theory, use the Drush Composer wrapper. Drush Composer is simply a Drush component, allowing you to run any Composer commands through Drush.
The following commands accomplish the same thing:
composer.phar installdrush composer install
Either method is an option for the testbot!
Some thoughts about how I imagine to use Drupal.org in 2017
greater visibility outside of the Drupal community
One of the benefits of moving to Github is to increase the visibility of Drupal outside the current community. Most web developers are used to using Github and many leading open source projects are already there. Being where those developers are might just spike their interest in Drupal. And using a tool they already use might mean they are more likely to play around with Drupal and eventually contribute.