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
agreed
I see benefits in both options, but since github as tons of extras for developers, I think we - as a community - should really consider moving the code to github, or something similar. The other option is that we speed up the development for the D7 migration, but I think to be able to do this we probably will need (a lot of) resources/funding.
For the issues we might consider using rest api to integrate into d.o. and I think meta issues should stay on d.o.
AFAIK the integration with the packaging and the testbots should be pretty straight forward, for testbot we might considers using Travis.
PS an alternative might be https://enterprise.github.com or maybe http://blog.gitlab.org/gitlab-6-dot-0-released/ they have comparable features, but a different pricing :-)
as i'm in favor of this move,
as i'm in favor of this move, i have compiled a list of articles that discuss moving our git repositories from d.o to github.
Drush - Migration From Drupal.org (to Github)
https://github.com/drush-ops/drush/wiki/Migration-From-Drupal.org
Github for social coding" by kim.pepper with reponses from webchick, dries, ...
https://groups.drupal.org/node/48818#comment-127138
Drupal sans Github: Missed Opportunity
http://www.echoditto.com/blog/drupal-sans-github-missed-opportunity
Several reasons why I prefer Github over Drupal for Hosting my Drupal Projects.
http://berk.es/2012/03/23/several-reasons-why-i-prefer-github-over-drupa...
i think quite some of the
i think quite some of the dreditor functionality would be fixed by
Move Git repositories to Github .
Of course I can be wrong, but
Of course I can be wrong, but personally I think that the efforts of Drupal should focus on drupal and Dev itself (project management, development, ...). Whatever you do not in this scope out is slowing the evolution as a tool/framework.
Per issue repos would solve
Per issue repos would solve this problem, being able to step through the progress of an issue would be great. I'm not sure if that fits here or is a separate suggestion.
If our broken search would
If our broken search would get fixed, we wouldn't have to debate this... (https://drupal.org/node/1862196).
So I am in general for "Fix search!".
That would be so awesome but
That would be so awesome but it sounds like a sci-fi feature. If there is a proven way anywhere out there I would +1 this.
When I started I really liked
When I started I really liked drupalmodules.com and it helped me a lot. Too bad it stalled after it was purchased by iO1. It would need a visual upgrade and some maintenance but basically would make this feature irrelevant. To me not adding more load to drupal.org is always a good thing.
Perhaps the Assoc could partner up with iO9 and use the site?
I would strongly be against
I would strongly be against this proposal. I find d.o. to be miles ahead of other tools, because community modules are centralised in one place. For example, I use puppet, and wish the 'puppetforge' were as fully-featured, visible, and usable as the d.o. project pages. I also notice that puppet modules are strewn randomly across github, with no real centralisation, and no reporting mechanism to track their usage.
I see the appeal of GitHub over d.o. in several key features:
1. Pull requests. This, a million times this.
2. This also implies forking. We have 'sandbox' repos, but I suspect they're not used much, because the process of creating a sandbox has a number of steps, and may not be obvious.
3. Simple creation of new repos ('sandboxes'). GH only needs the name of repo…and for sandboxes, we don't necessarily need all the project information that's currently requested.
Right now, GitHub is a much better code-management system, but I would prefer to see the tools on d.o. improved, than for us to migrate to GitHub.
it doesn't necessarily have
I agree that forking the whole repository is not necessary, but if you did not have that capability, you'd at least need to commit to a branch in order for the web button to be able to access the code to make the change. That, in my mind, would be equivalent to a pull request. Without a branch to commit to, where would the web button (pull-request equivalent) get the code from?
As for auto-generating and auto-posting patches from your local system to drupal.org today, as an interim step, you should really try the drush_iq project. That's what it does. It's gone largely unnoticed, but it's fairly slick. Not quite as good as pull requests, but still pretty fun to use. It even makes interdiffs. And posts releases, with release notes (using the grn project). From the command line. Yup.
Improve the content/layout of g.d.o. emails
The current notification template isn't well-suited to the type of content that's created on g.d.o.
I made an initial iteration on improving the template - see https://groups.drupal.org/node/287278 - which is a step forward in improved readability.
Stepping back from this a
Stepping back from this a bit, I remember the idea which maybe the way to go for the d.o. There was a lot of talk about per issue repositories which mean that many people can work on and edit as they do not, but push directly into an issue.
Then it would not be a big step to do an interface to be able to edit text on d.o and push it in.
It actually sounds like the
It actually sounds like the feature being requested here is being able to edit files and submit changes to the project maintainer through the UI in a couple of clicks. If this were to be implemented, it doesn't necessarily have to be done via pull request on the back-end; it could also auto-generate and auto-post patches, for that matter... at least as an interim step.
If this idea is in fact about Github-style pull requests, where you fork repos into your own sandbox and then submit branches for consideration, etc. etc. then it might be best to split the two into separate submissions, IMO.
However, "Move Drupal.org development to Github" is definitely a separate proposal. ;)
Agreed, the "do-not-test"
Agreed, the "do-not-test" feature is seldom used and probably not worth the clutter. I revised my original post and removed that part.
While I'm less sure of "Also,
While I'm less sure of "Also, add a check box to specify if a patch is to be marked with "do-not-test"" (we don't really need to clutter that interface more than it already is, IMO; this is like a 1% use case.. maybe something for Dreditor?), the rest (auto-naming and auto-interdiffs) would certainly eliminate an awful lot of busy work from the Drupal core queue, as well as make reviewing patches much easier.
I'm still debating whether to
I'm still debating whether to vote for this or not. On the one hand, it would be AWESOME if it worked! On the other hand, it feels like if we don't spend a lot of intimate time tweaking our search index and testing and re-tweaking and re-testing, it won't actually work. :(
Has anyone successfully implemented feature on a Drupal site, and can speak to the difficulty of returning useful results on a site with a content base the size of ours?
Here are the edits I made:
https://groups.drupal.org/node/313018/revisions/view/656433/656508
Feel free to clarify further if those are incorrect.
Oops, nope, I see I misread...
...and it is indeed about a totally redesigned theme. Clarified that in the title.
It sounds like you're
It sounds like you're proposing "Make the Drupal.org theme responsive" rather than "Redesign the theme entirely" — am I reading that correctly? It might not hurt to clarify that in the title.
Also, I'd personally prefer to see reference to specific implementation removed (the 'Foundation 4.x' bits)... You've made your preference known, but let's look at the goal first; if this makes it to the roadmap, then we can consider the implementation.
Though, I will say...
One extremely useful tool that I know developers would love is the ability to take an issue and move it out of the issue queue (since a lot of people post "how do I do this in Drupal?" kind of questions to the most random of queues) and into the "support system" (whatever that is) and also back again (since a lot of people report bug reports in the forum currently, not realizing the issue queue is the proper place).
It doesn't sound like this functionality would be included here, though, necessarily. More like building Stack Exchange (lite?) on Drupal.org itself?