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
Groups provide not the best
Groups provide not the best interface for this kind of section. E.g you can't filter by geo location or type of job, see which job postings are still relevant, signup for email notifications of specific type of job postings in specific area, etc.
Additionally lot of people are unhappy with job postings on g.d.o, as they often spam unrelated groups.
Proposed section will replace jobs area on g.d.o. It will be located in Marketplace section on Drupal.org, next to Drupal Services and Training listings. And it will allow to do all of that stuff I mentioned above.
Bluecheese is maintained in
Bluecheese is maintained in bzr. Not git.
Wow, this is great!! Please
Wow, this is great!!
Please make your intention to provide resources around this known by editing the wiki page. I think your approach sounds very sensible; not sure how long it would take to put something like that together.
We indeed should focus on this
So you said moving to git has probably kept people on the mothership. While that's likely true, I still do no think it was the best fit. But, fitness for a single task is apparently not enough when people use a tool day in and day out they don't care enough to use the best tool for the job. If Drupal did not force git on hobbyists, some other project, job etc would do.
Similarly, as the world moved to git and then to github, we will move to github. Not because any particular feature but because everyone else did, plain and simple. It's equally a shitty fit but that won't stop the tide. No risk me or jthorson listed will stop this tide either. Even if we could make the best tailor fitted tool for our workflow, noone will care except a few diehards. The community as a whole wants to learn one tool and that tool is github.
Acknowledging this is perhaps our best bet and then focus on how at this could actually happen and how can still keep the community together is probably the best way to spend our energies.
You're right. Bad example. My
You're right. Bad example.
My low opinion of Drupal Answers stems from the fact it doesn't seem to be doing it's job. Even though it's been around for years.
Good answers come from people who know what they are talking about. As far as I can tell on Drupal, that's usually the maintainers of various modules. When I was first learning Drupal, I spent hours browsing the forums looking for help, and hours composing the best posts I could to ask for help. I got basically nothing in response.
Eventually I learned how to ask for help in the issue queues where the people who knew what they were talking about actually spent time. That was a lot more productive.
Note, this was a few years ago when D7 was in alpha. What the forums are like now, I don't know.
Drupal Answers appears to serve the same audience as the forums did. Like the forums, I don't think enough of the people who know what they're talking about are on it.
While it has potential, I'm not sure Stack Exchange is the best place for it. Is there any way we could easily link/convert questions and issues? Does it fit Drupal culture?
There's also a lot of community issues to figure out, I just clicked on a question asked in 8/2011 with one answer from 5/2012, and another from today. None of which the asker has marked as accepted.
All in all, Drupal Answers has a long long way to go before it becomes a decent resource. I don't think it's worth it, when we could build something better on d.o. At least, that's my opinion. Anyone have any stats on how many questions there are versus accepted answers? I just saw a question posted in 2011, one answer from 2012, and one from today. I doubt the person who asked got any help from either answer.
As far as what kind of support I can expect, that is much larger question that isn't really something to get into here. But, if I can't expect an answer from Drupal Answers, then why does it even exist? The whole point of the site is to answer questions. If that doesn't happen, then the site is not doing it's job.
I think a Drupal version of the Q/A format, integrated with how projects are managed, has a much better chance of providing good support. Largely because it will be part of Drupal, where the people who know the answers already spend lots of their time. Rather than a separate, third-party, site, that they may no know even exists.
Thanks so much for your thoughts!
Just want to point out quickly (and it's likely this needs clarification in the wiki page, because it keeps coming up), no one is advocating dropping centralized project listings on Drupal.org. They're advocating moving the git-related stuff to Github. I agree with you that this is one of the biggest advantages of Drupal, but it's also not under threat from this proposal.
I've seen this argument as well, but I don't think it means "focus on core." It means "focus on more squarely Drupal-related things." If our testing tools "just worked" without ever having to futz with them (either because they actually worked, or because they were out of our hands to futz with as in the case of Github), you could be spending more of your time on sports-related modules, for example.
As someone who's probably spent the most time of anyone trying to encourage contributions to Drupal.org and documenting how to do it, I don't really resonate with the idea of casting blame onto volunteers for not volunteering hard enough and/or on the right things. Drupal.org is a top-1000 website, with hundreds of thousands of users, and is the central collaboration point of all Drupal-related projects. It should not (and realistically, cannot) fall to the shoulders of volunteers to ensure that sufficient progress is made on our tools.
I think that's probably the most lucid example of someone stating some of the large risks with this proposal. Thanks for that. Can you make sure those work their way into the "Risks" section of the wiki page in some fashion?
.
May just be a documentation issue ... http://about.travis-ci.org/docs/user/getting-started/ states "As a free community service, Travis CI limits build duration to about 20 minutes.".
Nope
Developers are desperate for hype. If they would be desperate for better tools they would be breaking down the doors to contribute to drupal.org. We are talking of capable developers, right?
With that said, I already said (and in fact, I told you months ago in person): it's inevitable we move to github. The question is only how do we mitigate this inevitable hype-driven disaster community wise? I am actually serious. For example, the step-by-step guide tab right on project pages was a great way to mitigate the disaster git was.
Wait, what? According to
Wait, what? According to http://about.travis-ci.org/docs/user/build-configuration/#Build-Timeouts, it is 50m total, or 10m with no output. Where'd you get the 20?
While we might actually be
While we might actually be able to squeeze our run down to 50 minutes, the travis-ci limit is actually 20 minutes. :)
What I find compelling about
What I find compelling about this proposal (assuming it is a whole-sale "move to Github" that includes not only repositories but also issue tracking, wiki pages for "meta" issues, etc.) is three-fold:
a) It greatly reduces friction for people who already use Github day-to-day to contribute to Drupal. This is, as of April, 3.5 million users with 6 million repositories. Compared to 28.5K users and 26.7K projects on Drupal.org; it's no contest. Technically, we could've run our own "IRC" channel with a pile of PHP code in a Drupal module. Instead, we chose to partner with Freenode, which gives us much more seamless collaboration with other open source projects. I feel that this move would bring a lot of the same benefits.
b) The biggest message I'm getting from this brainstorming exercise so far (and, granted, we're only a couple of days in) is that developers are desperate for better tools. And unlike Drupal.org, Github has a long history of delivering features that developers love, and 100 million dollars to do it with. Compared to the Drupal Association, which has more like a $150K/year budget for website improvements, and has to balance this not only with providing website features but also ongoing maintenance, improving the DrupalCon websites to allow us to fund development in the first place, etc.
c) Also coming out of that budget is upgrading the site to the new major Drupal versions from time to time, which always gets stalled for months (or in the case of Drupal 7, more than a year) on the pile of custom code (and technically contrib, but only used by Drupal.org code) that is our "dog food" repository and issue management software. It's a huge black eye to the project for our flagship website to be running a 5-year old version of Drupal, when we're about to ship a new major version most likely next year. Outsourcing that huge pile of code would eliminate this problem. (Granted, though, there are other options than Github for this; e.g. Gitlab, or splitting up the sites so "downloads" is on its own site.)
Now, there are a lot of very serious, fundamental communuty-shaking/shaping reasons not to do this, but I don't understand at all not seeing clear benefits of this proposal.
Not so fast
Travis CI docs: With our current timeouts, a build will be terminated if it's still running after 50 minutes
I'd prefer we improve the
While that sounds intuitive, the current Drupal forum module has been basically unchanged since at least Drupal 4.5. Bringing it up to the standards of modern forum software would be a massive undertaking, requiring hundreds of hours of development work.
I think that's a bit of a straw man. Stack Exchange is the single purpose of Stack Exchange, Inc., and they're quite committed to the project. Additionally, all data is open and can be freely downloaded by anyone. Even if they shut down tomorrow, we would be no worse off. We can simply import the questions and answers into a Drupal site and go on.
While there's no doubt that it would change things, I think there's a lot to be gained from unifying support attention at a single point rather than having the two compete.
Additionally, answered questions on the Stack Exchange site usually provides a useful, discoverable artefact. The standard forum, since it has no de-duplication tools, are just the same questions asked over and over, often unanswered.
Project Pages
The d.o project pages are here to stay. However, instead of being directly linked with code, people (who have passed the PA process) can click "Add Project", authorize drupal.org as an API client (so we can make sure people only add their own code, optional), see a list of their repos, select one, add some info (with defaults pulled from the project name and README, if possible), and click submit.
Removing the Testbot completely
We could potentially completely remove the testbot as we know it and just use Travis CI (which I think will be dead easy to set up).
They were removed...
... because comments with a negative comment count became kind of hidden; without that they could've stayed. At least I would have the most negative votes!
To answer your question,
To answer your question, removing the "vote down" ability was a decision made by the g.d.o leads when this became effectively a way to insult/silence people in debates like this. You can get the same info by viewing how many opposing comments are voted up, or how many votes that counter-proposals have.
Speaking for the D.o SWG, though, we're not really interested in counting votes as part of this process; they're a factor, certainly, as they help point out serious pain points that need to be factored into the roadmap, but this brainstorming process isn't a poll, and popularity is not going to win the day.
Not a lot of good arguments
I have actually collected the perceived benefits into a comment and it's hard to find a compelling argument for github except for some nice features and a lot of unfounded hype that pull requests are "better". I put the problems in https://groups.drupal.org/node/313068#comment-953938 here.
You're welcome!
You're welcome!
If we need to do the work to
If we need to do the work to integrate with Github, is there a reason we wouldn't simply perform that same integration work with our existing repositories? Having been in the guts of project_issue, PIFT, versioncontrol_project, and versioncontrol_git ... it seems to me that breaking and reimplementing the existing repository ties would introduce a significant amount of disruption and instability into the entire ecosystem; whereas (once the D7 migration is complete, very soon now) layering on the incremental workflow functionality that the community desires would be a much smaller body of work.