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
No one would like this more
No one would like this more than me, but just to give some background on why this isn't public...
https://association.drupal.org/about/copyright explains the DA's position wrt Drupal's trademark:
(emphasis mine)
Both the "Drupal" wordmark and the look and feel of the Drupal.org website are integral to the Drupal "brand" and, at least as I have been told by people who understand copyright/trademark law, if the DA were to give these away freely under the GPL, this would be the opposite of protecting the trademark of Drupal. Someone could then slap the Drupal logo/branding on some seedy site that distributes spyware-laden Drupal modules or whatever and tarnish the trademark of Drupal.
This is not an unusual position; Firefox is an open source project, but the Debian fork of it is called "Iceweasel" and uses different logo/branding.
So unfortunately, I don't see this happening. :( Unless of course you happen to be a lawyer with sufficient background on copyright/trademark law who could advise the DA on how we could meet both goals. :)
maybe .. maybe not
Symfony works really well but there are a few observations:
1) all discussions happen inside tickets/PRs which are quite simplistic and we do not create bigger design documents there. note the github wiki is also very simplistic. that being said, discussions close to the code and inside the diff tend to keep discussions more technical and has severe reduced bikeshedding
2) there are only a handful of people with push rights to the main repository and only these people can add tags, close/reopen tickets etc. to get more granularity you need split things up into sub-repositories
3) it might be possible to layer a UI on top of github using their API to handle the deficiencies while still benefitting from their infrastructure, tools and 3rd party tools (like travis-ci.org, prose.io etc). Doctrine has also created some integration with Github and Jira.
4) I am sure you could contact github and discuss them whatever you feel is missing and whatever advise they have to offer given your very special existing setup.
i think this would be awesome
to have pull requests in drupal. there have been many times when i just wanted to submit a fix to a module...but didnt bother with pulling the repo...making an issue, making a patch, waiting for the maintainer to test the patch...etc.etc.etc.etc.
id much rather, make the change and it get directly submitted to the maintainer. i agree, the barrier to entry would go down significantly.
I'm pretty -1 on github for
I'm pretty -1 on github for Drupal. We use it for our work repos, and it's "ok" for that, but not much better than "ok".
PR's a great for one-off small contributions, but I don't think they are nearly as useful when several people are trying to contribute to a change.
While the grass may look greener, I would expect massive community disruption and fragmentation and I don't have any sense that it's worth the aggravation and loss of control we'd have.
set up two push targets on
set up two push targets on the desired remote - it'll push to both d.o and github with one command.
General observations
Something I'm seeing here, which you're free to correct me on, is that it almost feels like GitHub would work better for contrib than core. That is, GitHub works really well for "small team of first-tier people with commit, plus assorted drive-by contributors". That's the typical contrib process, and I think it would work extremely well.
Core is the odd ball (and a few very high-tier modules like Views, when it was still in contrib). We have an extremely small number of committers, which on GitHub means they're the only ones that can do meaningful issue farming. We rely very heavily on issue categorization and curation and shuffling and tagging and so on, and on crowdsourcing that. We have an extra tier of people that get extra management/curation powers but don't get commit. We have issues that tend to come from lots of people rather than just one.
Also, I've seen cases where GitHub has a lot of trouble when a project has a bazillion forks. It becomes hard to setup PRs to the right repo if it's not to the main one. That's an issue that would affect, mostly, core.
Which is a really odd conclusion to come to. :-) Contrib would benefit from GitHub, but GitHub's issue management can't really scale to core.
To which my question then is 2 fold:
1) Could we vary our core process to still work with that tool? Given that many other large projects work quite well there I don't think this is an un-achieveable goal.
2) Could we pressure GitHub to improve the issue management tools to meet our needs? Given that we'd be the largest PHP project there by far, I don't think that's unreasonable to ask.
I'm +1 on this. Anything we
I'm +1 on this. Anything we can do to reduce the barrier to entry with contributing to d.o is a good thing especially with how much is involved with the D7 upgrade.
Call a spade a spade
What is being proposed here is uninstalling Forum module from d.o in effect deleting all of the forum content. We are advocating removing the #2 suggestion we tell people to use on our support page https://drupal.org/support and basically saying we're not doing a good job providing support so go look somewhere else for it.
I'm ok with that if that is what we are trying to say. I just want to be clear what impression this may convey. Also if you review the reasons they wanted to take down the Ubuntu forums is because they had fantastic Google PR but were returning outdated results. I think this could have been resolved with better forum pruning.
In addition you will note that Ubuntu has forums again (although hosted by a well integrated 3rd party) and it is listed higher on their list of ways to get support than AskUbuntu. http://www.ubuntu.com/support/community/
I do think we should absolutely add http://drupal.stackexchange.com/ to the support page on d.o though.
Ubuntu is different software.
Ubuntu is different software. Drupal is website development software. So, we can not compare with Ubuntu.
If we think that our Drupal is best CMS in the world then we should build website drupal.org in a way that everybody will attract to use this software. If we you can not build our own website by our own software, then how will client get confident on drupal?
_
Same post given above. Sorry for re-post.
URL path in drupal.org
But why can't we improve our SEO in drupal.org instead of going to other site for help? We are in a website development software. If we can not improve our SEO or software or our website by Drupal, then how we will assure our client that their website will come first in search engine ranking if made in Drupal.
I think if we change the node/numbers of drupal.org URL path to something understandable by pathauto module then it may improve drupal.org SEO in Google.
I am strictly against going to Stack Exchange. I know that some people outside Drupal, they said that - one thing bad in drupal is that many external links are given in the support forum than internal links. Drupal already has good documentation.
I understand this because of Drupal lack of SEO, people found answer more easily in external website than drupal.org. Anyhow we should improve SEO and search capability.
If we can not it will be very bad for us, because we are in a website development software.
Sounds like a great idea! In
Sounds like a great idea! In theory you wouldn't need a “was this helpful?” button. If they click on the suggestion then it's useful. This wouldn't be too difficult to implement depending how smart you wanted the suggestions to be. They could be manually maintained and tweaked.
We already have a package
We already have a package system, adding a few more small (non-critical) features is hardly worth a new proposal.
Also, personally I'm trying to avoid proposing anything I'm not willing to work on myself.
We can get inspiration from
We can get inspiration from Stack Exchange and improve our drupal,org site. What they implementing we can also implement those things. It will be not good if we move to SE.
Also it will be shame for drupal, because drupal is a software by which we are developing website. So is it TRUE that by Drupal we can not develop powerful website like Stack Exchange?
Do not compare this Drupal software or website with Ubuntu in this respect. Ubuntu is not a website making software. We are in a website developing software, so our website should be advance than any other website. For example - does Adobe or Microsoft will think that they will move to Stack Exchange. Adobe and Microsoft also make website development software. May be they are commercial organization, but if you want to compete with large organization in website development we should improve our services instead of moving to others help. I think Drupal CMS has more user and advance than Microsoft or Adobe CMS. So, why don't we can't impove our drupal.org website?
I have posted an update to the risk section.
If we did that today, Drupal
Please elaborate on that. Today, as I explain in http://www.tsvenson.com/blog/2013/08/dogfooding-our-drupalorg-infrastruc..., the community is managing three major versions of Drupal Core. This change would effectively take that down to two and thus free up quite a bit of resources.
I didn't join the Drupal community until after D6 was out so I can't say much about how things worked before that. However, I am quite sure we have much more resources available today, as well as a lot more experience about project management at our hands.
Then factor in the transformation the Drupal Association has gone through only the last year. Including taking a much more active and resourceful role around drupal.org.
See for example https://association.drupal.org/node/17983 where a team lead by DA staff ported the project and issue queue modules to D7. The post says they rewrote roughly 90% of those two modules. Not a small task.
Instead of just flatly blank this idea, I think it is worth at least exploring it further. At least to better understand where our limited resources are used today, especially in regards to d.o and Drupal 6, the cost of upgrading it to Drupal 7 etc. Then look at how much of all those efforts that is helping to improve Drupal core and contrib projects.
Maybe we get surprised and find out that those resources can be used more smartly and at the same time help driving Drupal and the community forward. Or as I say in my post:
"This would in itself change focus from maintaining the past to pushing the future!"
While the post you're
While the post you're referring to does state that, the author of said post is just one the four moderators of Drupal Answers. He does not work for StackExchange, nor does he speak for them.
As for his statement that Drupal Answers cannot replace the support forums – he's entitled to his opinion, but since he doesn't argue the point, its kinda hard to refute.
However, Ubuntu very successfully replace their forums with Stack Exchange some years back (with great success). You can find the new site at http://askubuntu.com/
Ahh, didn't know that. Its
Ahh, didn't know that. Its definitely a thing that should be moved to the IQ module...
The core release cycle is
The thing is that I have today no idea which developers does use those guidelines for what projects. Over time I have been able to learn which developers/project I know I can trust more than others, but that is not an easy task for everyone. Especially not for new ones.
No, but this group was created for brainstorming ideas for d.o and this is an idea I wanted to get some feedback on.
I am fully aware that to be able to implement it a complete proposal draft is need to be made, as well as changes to d.o and relevant modules to be able to both display the badge as well as be able to take it away for projects that doesn't follow through.
Maybe there even need to be a review process or crowd generated process to earn the badge?!
There might even be valuable to explore if there should be more than one badge level and maybe even badges for other things. For example a badge for following the Drupal user interface standards https://drupal.org/ui-standards.
As I mention in my idea post I believe there are many benefits with this, including but not limited to:
I also believe that if this is done right, then it will be motivating project maintainers to aspire to get these badges.
Or how about having badges to show that a module provides an API, uses a third part library and so on.
For me visual guides such as badges helps to get a quick check on what something provides and with 20k+ contrib projects I believe that a carefully selected number of badges can be a valuable addition on d.o.
Yes this idea is nice
Yes this idea is nice
I posted an update to the
I posted an update to the risks section in the issue summary that the moderators at StackExchange do not appear to want to be a replacement for our support forums. That does not sound very encouraging to use them as an outsource for our current forums.