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
Thanks for this! This is
Thanks for this! This is really helpful for people like me who don't use Github extensively to understand the differences in collaboration techniques.
It'd help a lot to have
It'd help a lot to have concrete, logical, objective reasons why you oppose this move. I know a lot of people do. I might even still be one of them; I'm pretty on the fence at this point.
But these overly vague, dramatic, emotional responses do not actually help the decision-makers here to understand what exactly the concerns are, which is dangerous because if the "pro" people are presenting non-emotional, rational responses it only serves to strengthen their argument.
Moving to Git was
Moving to Git was single-handedly the smartest thing we ever did. http://buytaert.net/drupal-contributor-statistics-2011 In fact, it's probably the only reason the community has largely stayed on the mothership this long.
Your point about more/different steps to learn is true. Though one nice thing is there is lots of documentation out there that we don't have to write and maintain about how to do it.
Don't know what you've got till it's gone ...
As a hobbyist (i.e. in my pre-"testbot cardiologist" days), I tended to float around from project to project, trying out new things one weekend to the next ... hacking on phpBB one week, menalto Gallery the next, and some sourceforge or github project the week after that. The problem is that I'd spend more time browsing through junk projects, obsolete forks, and half-completed code than I would actually hacking on the project I was working on. In the end Drupal's collaboration over competition ethos meant that there was probably only one or two modules I needed to look into, and in all likelyhood, they would actually work. And as an added bonus, they could all be found on a single site, and not mixed in with a whole litter of unrelated projects. I eventually quit wasting time sifting through google, sourceforge, and github, and have never looked back.
There is tremendous value in having everything located in one place, and the flexibility it provides ... as you shift components off to github, you dilute the overall value of drupal.org, and limit the community's ability to innovate on top of those tools. A move elsewhere adds complexity to issues like packaging, download/usage tracking, automated testing, update manager, d.o project browser, project management, security advisories, etc ... It's easy to imagine that moving to github can solve all our perceived workflow problems, but in practice, it will be magnitudes more work than the Drupal.org D7 migration ever was!
The most common argument I hear for a move to github is that we should be focusing on Drupal and not wasting resources developing/maintaining our own tools. I consider this a limited and very core-centric viewpoint, infering a presumption that everyone in the community has the same skill set and is well cut out for core development ... obviously this is not true. The community has a much higher number of drupal users and implementers than core developers; and while we do a great job of encouraging those implementors to get involved and try out core development, we actively discourage them from trying to help improve drupal.org ... through repeated disparaging comments about how slow, difficult, and impossible it is to get anything done on drupal.org, and sharing old horror stories, war wounds, and long-healed scars earned during past attempts. (Incidently, the infrastructure team has made tremendous progress in eliminating those earlier barriers to drupal.org development over the last 18 months!)
I'd argue instead that we, as a community, should be putting a much greater focus on our internal tools, using them to showcase the power and flexibility of the Drupal product ... perhaps even scheduling 'tool-upgrade' cycles in the months after a new core release and before work starts on the next major release branch. (Or maybe even before the core release ... which would guarantee that 50+ contrib projects in use on drupal.org would already be ported ahead and ready as of the core release date!)
Proponents of the github move will argue that this approach is a 'been there, tried that' dead end, as there are features we've wanted on drupal.org for years, which have never materialized ... I see these arguments incredibly ironic. For a community which prides itself on individual do-ocracy, and the ability to proactively re-invent Drupal 8 with a strong eye to the future, we also seem content to let ourselves dwell in the past when it comes to drupal.org, complaining that we've been waiting all this time, and "THEY" haven't built it yet.
In the end, the concept of ‘distributed versus centralized’ works in version control … but it does not work nearly as well in ‘community’. Distributed communities have a increased tendency towards fracture. Having drupal.org as the all-inclusive central hub is a large part of the glue which makes this community ... and product ... as strong as it is.
That's a catch 22
That's a catch 22 unfortunately, since the module won't work if the server module isn't on d.o
I pinged Ben Lanvender who
I pinged Ben Lanvender who contributed to Drupal in the past and now works for Github, hopefully he will be able to jump in this thread. If you contact Github support, make sure to mention his name (@bhuga).
Another advantage of GitHub
Another advantage of GitHub is existence of mobile applications.
Not all questions will get answers on any system
I'm not voting for or against.
I think that drupal issues, forum, and answers/overflow are all good sources of information, and I use them all to get answers to question I might have, however I don't think it is fair to say that the quality of drupal answers is not great becuase your questions have not been answered to your satisfaction.
There are unanswered and poorly answered questions on there (some of them even have flat out wrong answers), but that is also the case with the drupal support forum and the drupal issue queues, and any other support forum I have ever seen.
Unless you are paying for support you can never expect all questions to be answered in a satisfactory way (or even at all).
This feels like the right direction to me
This feels like the right direction to me. Another plausible alternative is continue with the current drupal / git based infrastructure and enhance it to have pull requests and other desired features.
It feels right enough to me that I would contribute some resources to it, in terms of money and whatever time I have available (not much). Maybe there's something that could be done to prove the concept and move it down the road quickly.
What I have in mind is some sort of plan to:
1) Set up a gitlab that mirrors the d.o repos, or maybe just a few of the more popular modules
2) Have it pull some issues from the feeds so that it is actually useful for trying things
3) People won't actually try it in any meaningful way if work they do gets stranded there (with out manual effort). So we'd need something, maybe an extension of Dreditor or another greasemonkey script like it, that allow one-click generation of a patch & comment back to the home d.o issue.
It seems like a lot of work in glue code that will be eventually thrown away, but that's they way these types of integration projects go, I guess. Also, instead of the gitlab, I'd be willing to entertain an alternative of a Drupal Project with a lot of enhancements, but I fear that would not get us a good PoC very quickly.
When I say I'm willing to put in resources, I'm thinking from $1,000 to $5,000 and recruiting other money. Maybe one of the crowdsourcing systems out there could be used for it. I'm willing to put in that much, because I see Drupal as worth much more than that to my career, I see that it needs better infrastructure so that I can make money off of all those other contributors shared work, and I think the github solution won't cut it in the long term.
private repos possible - we
http://dgo.to/bluecheese
We have this solved, though.
If I go click edit on a repo I can't commit to, GitHub makes a fork for me. Also, forking is a one-click operation.
Ripping out a huge chunk of code (some of which will be replaced by code that generates project pages from the API) that we have to maintain/port to D7 and beyond.
EDIT: No killer feature, but GitHub's notification emails are better, for two reasons.
1. I don't get emailed for my own comments.
2. I can reply to a notification email I got, and it will be posted as a new comment.
Searching issues...
Searching issues queues can be hard, but not so bad when using google.
I think the difficulty in searching comes from the massive number of issues that are being searched and possibly not knowing exactly what you are searching for. These things are platform independent.
When you are comparing to searching other platforms, do they have the same quantity of issues?
If we have the same number of issues in github instead, is it really going to make searching any easier?
What are the benefits?
Build-in features:
Aside from the inline editing what is the killer feature that would make such a move justified...?
Not having an option to down vote is a bit strange
With all these ideas I find it a bit funny that you can't down vote.
We can see that 33 people think it is a good idea, but for all we know there are 300 that think it isn't. Or maybe there is only 1, we can't know for sure.
The only way we kind of know is by people commenting, but not all people with an opinion will comment and it is not so easy to compare comments against a number.
Is there a reason for this voting system?
Workflows
I may be an oddball, but when I contribute to core, this is my current workflow:
git diff HEAD^1 > interdiff.txtgit diff 8.x > node.fix_stuff.12346677.5.patchHere is the github workflow, with hub (a backwards-compatible wrapper around git) installed:
alias git=hubgit clone drupal/drupalcd drupalgit forkgit checkout -b smash_poll_modulegit push --set-upstream Gaelan smash_poll_modulegit pull-requestgit checkout smash_poll_modulegit checkout http://github.com/drupal/drupal/pull/123(this gives me a branch for their PR; first time only)Oh I have no doubt
I have no doubt that as git hype have moved us to git, the hype moving us to github is inevitable. It'll hurt the community a lot but the hurrah over the perceived easiness of fixing a single character typo (can be done from the browser! fantastic) will be much, much louder than the quiet of those who leave.
Nothing stops...
... someone from learning git either and yet it's something we forced on people with the git migration. I maintain that was a mistake: most contribs don't need more than a central repo and a checkout (or bound branch). Accidentally, that's the only feature git does not have.
... someone from learning all the abstracted stuff we added to Drupal 8. Yet, it's something most people will find at least hard to do.
... someone from learning even more just to contribute to core. Currently you have an issue with a comment form at the bottom and an attach button. You write a comment and post your patch. Now, you will need to create a new branch, figure out the art of writing good commit messages, create a PR, link it back to the issue. Also, the issue will need to link to the PRs. Nothing stop you from doing it, it's just a lot more work and more concepts to learn (compared to current core at least: branch, commit, pull request)
There is going to be pain
There is going to be pain associated with moving to GitHub, and timing will be tricky.
Do we move now, in the heat of d8 battle, or wait until d8 is released? If we push long enough, we might be in position of the couple who divorced after 75 years of marriage because they wanted to wait until the children sere dead.
I am sure that there are folks in the Drupal dev community that never touch GitHub, and I am sure that it is a small number. I don't know anyone in the community who doesn't use GitHub for something. I do know there are many projects that are dual-homed in d.o and GitHub, and this is a PITA for the folks who have to do this.
My experience is that d.o seems to be at its limits. Searching the issue queues can be very tedious, and sometimes fails entirely. We can't afford the resilience that GitHub offers.
While I hope that GitHub doesn't change its T&Cs to something we can't live with, there will always be other choices, if that comes to pass. The mere possibility does not seem like a blocker.
I think that we should cry havoc and let slip the dogs of GitHub.
I'm generally against this
On the other hand, I am enthusiasitically in favor of improving our current setup, perhaps by using gitlab as proposed elsewhere.
My objections generally run in line with the others, particularly on trusting a third party with something like this when we don't have to. I like github, I use it, and I think it is has been a huge boon to open source and software development in general. I loved the "Brewing Github" talk at DrupalCamp Austin, and the other talks githubbers give about their managerless culture, using git repos for company policy and other non-code stuff, etc. I'm really interested in various attempts to draft legislation via github, for example.
But one of the trends of the computer revolution, is that things that required a big centralized organization swiftly become codified and can be set up by anyone. This isn't to trivialize the task, as I suspect it could be similar in scope and disruption to The Great Git Migration, but it is certainly plausible for a community with our resources to run our own GitHub, including contributing back to gitlab where needed.
The fact that a significant number of the people who contribute to Drupal and use d.o a lot support this is very important. It indicates that we are failing in our infrastructure. However, I think there is also a broad class of people out there, who complain about the d.o patch based infrastructure, but they don't contribute to any github projects either.
Suppose it takes something like 3 hours to go from reading and issue, figuring it out and googling some stuff, making the code changes, and posting a patch. Perhaps 20 to 30 minutes of that is d.o infrastructure inefficiency, and github isn't going to eliminate all of it. Most people who aren't contributing aren't contributing because of the other 2.5 hours, not the 30 minutes.
So we're not going to unleash some hidden horde of contributors with this move. We are going to incurr costs similar to setting up gitlab ourselves just in moving and integrating. There would be definite immediate benefits, but I think the costs and risks are more long term and not immediately apparent, and in balance I'm against it.
This is correct. Pull
This is correct. Pull requests reference branches, not specific commits. GitHub allows people to add commits to a PR at any time. You might even argue that this is easier with GH then with the current system: All you need to do to update the PR is git push.
Quoted back to them.
Quoted back to them.