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
for some reason Berkshelf
for some reason Berkshelf immediately jumped to mind when you mentioned this. The packaging system is adaptable enough to pull from multiple sources, not just a single feed. I've seen those sources be things like the chef community pages for their version of "modules" as well as github projects. Maybe something like that could be considered if a change were to happen. It almost seems like that would be necessary if travis-ci starts becoming a regular topic.
We could change the colours
We could change the colours to anything as long as they aren't d.o colours. I think that would only serve to encourage others to install it on their sites, this isn't really something we are aiming for. If the contributed theme has poor accessibility or usability then it doesn't really affect our intended aim which is to fix d.o issues unless the usability is so poor that it's hard for developers to find their way around the site :). Maybe links is a good example.
We do need some color for the
We do need some color for the links.
Good work here. Just one
Good work here.
Just one thing... any reason to remove the gradients in buttons and top header ? It will be nice to keep them in grayscale, but that pure #000 looks excesive.
Keeping the gradient in the header area will fix accessibility issue Shyamala reported.
First impressions theme looks
First impressions theme looks lovely. So good to know we will have bluecheese as a contributed theme soon.
Some thoughts:
1) Have we tested the colours for Accessibility? If not we should - the White text on Grey on the top banner will not pass.
2) Will we be introducing a logo, the drupllicon that's licensed in GPL?
---These are possibly details for the implementations.
UPDATE: Share thoughts on the Intended Blue Cheese Public Repo
Huge thanks to Lewis, Tatiana and Melissa. We have a version of a publicly available BlueCheese theme to take a look at. You can read more details here:
https://groups.drupal.org/node/390728
But keep discussions/comments in this thread for now. Thanks for your patience!
This post, in general, was
This post, in general, was relatively motivating for me. I put together an example of what I think this would start to look like. Essentially, if you want to run a "best practices" drupal 7 or 8 site you simply run a single command similar to
bash <(curl https://drupal.org/setup).From there a couple of basic requirement and configuration checks are run and then the user has a fully functional drupal 7 or 8 site running (public core or private repo). The entire configuration is defined in a json file (yes, yaml would be fine to) the user gets a diff of the configuration file to see how it was changed to meet their use case.
My first attempt was with chef and virtualbox but should be expanded to properly interact with the communities of vmware, parallels, chef, puppet, ansible, salt, cfengine, whatever schmancy new tool you want to name here. I feel like the DA should sponsor and become maintainers of each of the provisioning/configuration modules in each of the communities so that they can structure what best practices should be.
This starts with an all in one drupal lamp stack but the key is the recipes/modules/cookbooks. I feel this entire concept should be planned and executed in such a way that you begin to address the other server types in an enterprise infrastructure ... and you do the same thing. Provide a similar one liner that will run a load balancer that works with 2 webs and 2 databases in a master master configuration, for example.
Each new server class becomes officially supported in some capacity and the most vital recipes/modules are focused on with the communities effort guided by the enterprise experience of groups like d.o. infra and possibly LSD.
There's a lot of talk these days about a new CTO for the Association ... I hope whoever is chosen has the foresight to understand the unique position they are in to help redefine the complexity associated with drupal delivery from development to production. I'm generally over enthusiastic about this field, but it seems like the DA is in a unique position to help change this industry in a way that can move beyond Drupal rapidly.
The difference with this approach is that everything is done in the open and you become a shepard of open source principals by bucking the trend that this kind of work is too valuable, proprietary, security focused or whatever you want to use to justify not doing it right and not sharing.
I mean, can you imagine a world where Drupal removed this barrier to entry with such efficiency that it is realistic to deliver 10% of the webs traffic because drupal developers and site builders are able to focus on their message with the infrastructure kind of just works.
Here's a mostly working example that really developed steam after this post https://gist.github.com/cyberswat/1aa175f7a72c543adf8f ... obviously a first attempt at this but it "WFM" and illustrated to me that everything I outline above is possible.
Important point!
This needs to be part of the discussion. In case the switch happens we need a fallback strategy BEFORE we move.
Gitlab Webhooks and API
We're working on a series of modules to integrate the API layer in Gitlab with Drupal using Services and WSData.
You can find the first of these here.
https://drupal.org/project/gitlab_webhooks
These could potentially help quite a bit in the process of switching to Gitlab. As we complete further API modules I'll post back.
git.drupalcode.org is not a drupalism
It appear to actually be basically the old gitweb package ( https://git.wiki.kernel.org/index.php/Gitweb ) with some tweaking.
FWIW, I added a feature
FWIW, I added a feature suggestion to enhance GitLab issues with similar parameters provided on the d.o. issue tracker: http://feedback.gitlab.com/forums/176466-general/suggestions/5083989-mor...
We're using self-hosted GitLab on a project I'm currently working on, and I'm happy with it so far, besides for pretty crumby issue queue. However, the GitLab core development team is very responsive, so I'm sure they'd be open to enhancements.
I've been familiarizing myself with the GitLab codebase, so I may just start working on this and see what they think.
// Jason
greggles++
greggles++
CertifiedToRock is dead, long live CTR
http://certifiedtorock.com/node/82792
Gerrit
Did anybody tried https://code.google.com/p/gerrit/ with drupal. I really like fisheye (https://www.atlassian.com/software/fisheye/overview), but i am looking for an open source alternative.
If someone wants to follow
If someone wants to follow this up with the "current groupies", they
arewere:coltrane - https://drupal.org/user/91990
greggles - https://drupal.org/user/36762
c4rl - https://drupal.org/user/235047
lisarex - https://drupal.org/user/485222
ezra-g - https://drupal.org/user/69959
Please be diplomatic with any emails :)
I had time back in 2011, but sadly not anymore.
I wonder if the site runs via a spider based process that pulls out the data, which would probably explain the overheads and inability to easily update. So a collaboration with d.o. which allows that sites maintainers access to a raw db dump would probably make data mining much easier.
Although, currently between 2600000 and 2700000 users on drupal.org, which would be a months worth of processing if each user took 1 minute to process...
I think the issue here is
I think the issue here is those who used to maintain it have other priorities and there hasn't been any demand from the community for it/to update it.
If you are interested in seeing it updated, perhaps consider contacting the original authors and offering to assist?
But someone at Acquia could
But someone at Acquia could take one minute to talk to someone who is taking the lead in GVS projects to see if they could find out maybe? Bottom line the person that is (not) looking after the ctr project is unresponsive.
As per the comment above,
As per the comment above, Acquia has no control over the CTR site ... nor, for that matter, does the Drupal Association.
Disclaimer
Could someone who's in touch with Acquia get them to at least post a disclaimer on that site stating that the data is old?
That would be a fantastic short-term solution.
I actually find it slightly
I actually find it slightly irresponsible that they've left CTR online for the past few years without updating it. I've seen people asking for a user's CTR score to be submitted when replying to job offerings. But they have not updated the site in over a year and a half, so anyone who may have dropped out of the community in the meantime still shows up as high, and any work people have done in the meantime is not counted.