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
There are also numerous
I would be part of this group. Stack Exchange has helped me a million times when I've been googling for solutions, and is a great resource. But for me, it's not my preference for either giving or receiving support.
I also think that the Drupal.org forums are important for a few more reasons:
1) They are a good demonstration of how a Drupal forum can be fully integrated with a website. There is no need to create new accounts in order to use the forums. If I was a new user coming to look at Drupal as a solution, I would wonder why they are using an external service for support, when Drupal core comes built in with a forum software.
2) Searches on Drupal.org return results from all parts of the system. Support is a major thing to have as a part of search results, and moving support off site would remove support answers from search results.
3) Variety. There is nothing wrong with having more than one place to go for answers. Some people will prefer Stack Exchange or a Stack Exchange support type system, others will prefer Drupal.org or forum format for support.
I'd rather have the team commit to either improvements to the forum part of the site potentially to integrate some of the good points of Stack Overflow. For example, a method of giving a reply the best answer, so users could mark answers they like.
gitlab
I created a new wiki to discuss to benefits of using gitlab at https://groups.drupal.org/node/313158
Neat idea! This is a great
Neat idea! This is a great example of a simple improvement that could make a big impact.
Native Dreditor as well.
Native Dreditor as well.
I downgraded this to only
I downgraded this to only "Low" difficulty; I actually think this would be fairly straight-forward. There's already some code out there at e.g. http://stats.marvil07.net/drupal-core/ and http://ericduran.github.io/drupalcores/ to parse out usernames from the commit messages, we could borrow that and throw it into a hook, populate some database table somewhere, ta-da. :)
Make sure whatever concerns
Make sure whatever concerns you have about this proposal are reflected in the "What are the risks?" section of the wiki page. We want people to be able to come into these discussions and glean the pros/cons without reading all X comments.
Yeah, definitely a separate
Yeah, definitely a separate suggestion.
What's suggested here would just be a few lines of code on hook_comment_submit() or whatever. Per-issue repos are a whole 'nother ball of wax. :)
Thank you webchick
I was not sure if I should do it myself or wait for the proposal author or the poll organizer.
I just added links from/to each similar proposal.
I went ahead and did this,
I went ahead and did this, but anyone else can do that too. These are wiki pages. :)
That's a great datapoint;
That's a great datapoint; added to the summary.
See plugins.query.com for an
See http://plugins.jquery.com/ for an example of community using GitHub to host contributions, while still providing a central plugins registry.
See http://plugins.jquery.com
See http://plugins.jquery.com for an example of community using GitHub to host contributions, while still providing a central "plugins repository" user interface/experience.
I did a quick test using
I did a quick test using gitlab and I must say I'm impressed, I tested it using http://bitnami.com/launch/gitlab (free for one hour)
Edit: I installed gitlab on my dev machine and did some more testing
I created a project for drupal core and for the picture module, and it took me only a couple of minutes to set up.
It looks very similar to github and will probably do a lot what the community wants:
- hosted on our own servers
- better git viewer
- integrated dreditor (comment on line level)
- inline editing of all files
- linking issues
- pull requests
- protected branches
- integrated CI server
- use something else for issue management
- private repos possible
- extensive rest api
If the intention is to simply
If the intention is to simply clone Stack Exchange I don't understand why we would bother. Providing a Q&A is the core competency for Stack Exchange and they have the resources and expertise to do it very very well (especially in the area of gamification). If we're going to devote scarce resources to reinventing what's already available for free, there has to be a compelling business case.
Side effects
Note that a move to GitHub would also include features suggested in other proposals at no cost:
- Pull Request
- Back-link commit messages on issues (if issue are also moved to GitHub)
- Improved notifications system
Drupal has, indeed, thousands
Drupal has, indeed, thousands of projects (mostly themes and modules, but not only). A move to from Drupal.org to GitHub for code hosting does not means thousands of projects owned by a single organisation. Neither does it mean the end of project pages on Drupal.org with project overview, releases, etc. But rather thousands of projects owned by thousands of organisations and users. All listed and searchable on Drupal.org as they already are.
Yes easy forking on GitHub encourage developpers to create and then forget a lot of unmaintened, outdated and dead forks. But from my little experience, Drupal projects are forked by developpers who don't want to bother learning how to contribute patches all the time. But since they lack the tool to do it quickly on Drupal.org or anywhere else, they fork on their own internal VCS (or shared file server). So, unmaintened, outdated and dead forks exist in the Drupal, we just don't see them. Switching to GitHub will neither create this problem nor solve it. But at least, it provides an easy to use tools for those who want to publicaly fork, and then maintain, a Drupal project. By providing easy to use tools, it also encourage developper needing to fork a project to do it publicaly.
As for the eficiency of submitting a patch to Drupal.org, back in the days there was talk that CVS was efficient enough, that the migration to git was unecessary from a developper engagment perspective. I would love to see the number of contributions, contributors and new projects before and after the migration to git.
For documentation, this
For documentation, this capability is desperately needed. In fact, we need something a little more sophisticated than just being able to follow an individual page. It's really important that we also have the option to get notifications on a parent page AND all the child pages (existing and future).
This would finally give us a way for people to act as a technical reviewer for a particular sections of the documentation. We need people to monitor the security documentation (as just one important example) to make sure that any changes are sane and reasonable and right now there's absolutely no mechanism to allow them to do that.
There has been quite some
There has been quite some discussion on how to properly use pull requests for multiple people collaborating within an issue.
https://groups.drupal.org/node/50438#comment-136863
Have we settled upon a strategy in that regards?
Moving to SE worked VERY well for Ubuntu
At the OpenHelp Conference this year, Jorge Castro, the Cloud Community Liaison for Canonical, gave a great talk on how moving Ubuntu support from forums to Stack Exchange has been a resounding success. Unfortunately, I don't think his talk was recorded but you can read a summary of his points here: http://siobhanmckeown.com/open-help-jorge-castro-solving-the-qa-conundru...
Basically his argument is that forums are great for open-ended discussions where there is no definitive answer (e.g. should we move Drupal forums to SE) but there are many reasons why they are totally the wrong medium for answering technical questions that have only have one (or a limited number) of right answers.
I think moving to github is
I think moving to github is mistake.
The first big difference between opensource projects on github and drupal.org is count.
On github we have PHP, Symfony, Hyphop - this is big single code base projects.
Symfony have extentions but there are about 10 of them (prof link: http://symfony.com/components)
Drupal.org have >1000 modules. So it would be more then 1000 small projects on github.
Now let's check github pull requests. PHP project on github have 980 forks and 56 pull requests, Symfony - 2500 forks / 131 pull request.
Even Rails have 6400 forks / 374 pull requests.
That means that "easy make fork" motive developers to make forks instead of pull requests. Current drupal.org workflow makes publishing patch easily then create own copy of module.
So > 1000 modules and such fork/pull request relation will slow community.
Let's think how we can reach the same goals with other tools.
For example.
Lower barrier for people to contribute and more efficient contribution workflow.
Community can provide developer infrastructure that makes development process easy and motivate developer to contribute.
To reach that goal we use does not store contribute code in project git. We store only drush make file. So contribute code have to be downloaded. But if developer find out a bug and need to fix it, he have to create patch, contribute and add to drush make file.
This is very efficient.
Other my suggestion is to remake drupal.org issue tracking. Currently patch is just attach to comment. But realy patch should be special entity, that have relation to issue, module and module version. It would allow us to make automated port patch to next version of module. Because there is a lot of small fixes on drupal.org that are ignored by maintainers.
We started to think about that for internal cases and made public project on github
https://github.com/Drupal-Omsk/patch_management_system
but it is in very early stage.