Recent comments

"Switching to Github thus reduces a pretty major "Drupalism," which reduces the barrier of contribution for a critical mass of developers."

It's a distribution issue. Since the project would be packaged and distributed on d.o. anyway the licensing issues stay unfortunately.

so hard to stay off my soap box

one thing that would make me happy is just the idea of being able to get around the licensing issues & beeing able to use CC 3.0 graphics in our themes.

This might be a small thing but it drives me nuts that i cant use cc3.0 opensource icon libraries in a theme cause of the goddamn GPL2 on d.o

... on the other hand thats a policy issue - argh my brain is fried after reading all of these comments

...but I'm going to continue editing that comment for accuracy, so feel free to add a mail rule to ignore me. :D

First, thanks so much to everyone who has participated here, and has helped flesh out Ye Olde Spreadsheet of DOoOoOoOm. I feel like we have made a ton of progress here in identifying the actual pain points on Drupal.org, what makes Github so compelling, and what concerns are about moving our tools off-site.

Here's my current read of the discussion/research so far. Please help correct this where it is wrong; the D.o SWG has a meeting tonight and I'd like to provide an update, and I'd like to ensure that update is accurate.

Pro-Github

Github has a few key things going for it that are driving votes to this proposal. They are:

• Ubiquitousness. With a community of 3.5 million users and 6 million repositories, used by many major open source projects, etc. there's almost no developer out there who hasn't been exposed to Github in some fashion, and most use it for their day-to-day work. Switching to Github thus reduces a pretty major "Drupalism," which reduces the barrier of contribution for a critical mass of developers.
• Pull requests and amazing code review tools. Because patches are sooooo 2003. :P Pull requests integrate into the development process: Write code, run command, poof, record is there. Push more commits, poof, available to all. No need to code, diff, figure out interdiff, post, upload.

  Github also offers awesome code review tools; highlight a line, comment on it in-place, comments on outdated diffs get automatically collapsed from view, thus cutting down dramatically on 100+ reply issues. Drupal.org has Dreditor, a browser add-on which tries very hard to replicate some of this, but it's not really nearly the same.

• In-browser editing of files. This is a huge killer feature, particularly for non- or less-technical contributors. See a typo in a comment somewhere? Click 3 buttons and you've got a fix submitted. Want to change the markup of that function? Copy/paste code directly from Firebug into the Github window and submit it directly to the maintainer in a couple of clicks. For a huge class of fixes, contributors wouldn't need to know anything at all about Git in order to help! Versus right now, they need an entire ladder of tutorials in order to learn how to do this type of contribution effectively.

  The other thing I really like about this is we'd no longer need to mark things "needs work" for silly minutia like whitespace or grammar; the reviewer could just fix it up as they go. This would be a huge shot in the arm, morale-wise to core developers, and probably others.

• Not invented here. It could also kill off several thousand lines of "contrib but actually custom" code that our community is responsible for maintaining and paying for. Time/money spent on this huge chunk of code slows down our ability to keep our website up to date on the latest major Drupal releases, and would free up more resources for tackling problems that more directly relate to making Drupal a better CMS with better add-ons with a better website supporting it.

Pro-Drupal.org

While Drupal.org can feel old and crufty at times, there actually are a number of important benefits that it offers us, namely:

• Centralization / Canonicalism. Two really critical features that Drupal.org offers are: 1) one place to look for all Drupal-related code (on Github it could be literally anywhere), and 2) an easy way to denote the canonical project (http://drupal.org/project/views is obviously "the views module" and http://drupal.org/sandbox/webchick/387493 is obviously not, even if I called it "the Views module." These are absolute requirements, so that means that even if we switch development/collaboration tools to Github, Project module (the thing powering the download pages) is here to stay. (Though, potentially not also Project Issue Tracking, Project Release, Version Control API, Version Control API Git, Drupal.org Git, Drupal.org Project, Git instructions, etc. etc.)
• "Swarming" vs. Forking. Read Crell's nice comment for more details. This particularly happens in the core queue, but there's potential for it in any issue. The Drupal.org collaboration model is that a problem exists in one central place (issue), and people come around to solve it, working iteratively on the same chunk of code until it meets the proper standards. There is visibility by everyone interested in the fix at every step in the process, and all steps are in one place to go back and reference or learn from.

  By contrast, the Github collaboration model is built around individuals working in their own sandboxes, and only notifying people there are things going on when it's ready to merge. Lack of visibility into changes coming "down the pipe," as well as the risk of duplicate work happening is more likely here. It's also my understanding that people who've started PRs need to add co-collaborators one by one, which greatly works against "swarming" efforts. Because Drupal.org is great at...

• Empowering the masses. Drupal.org-style "swarm" collaboration largely happens because anyone at all can change anything at all about an issue. Fix a title, add a tag, post a patch, mark it "needs work," update the summary. This provides a lot of opportunities for lesser-known (or not known at all) community members to help with "issue queue triage" and leave the tough problems for maintainers. The "Community Tagging" feature that Drupal.org offers, in particular, is huge in empowering small groups to self-organize around particular issues and knocking them out at sprints, etc.

  My understanding is that on Github, there is no concept of "community tagging," and rather all of these types of "issue metadata" need to be managed by the repo maintainers themselves. And, because there's no way to delegate people with permissions to only update issue statuses and not also the code like there is on Drupal.org, doing so requires limiting the list of helpers to those who you trust not to commit wanton code to the repo without review (either purposely or accidentally).

• Structured issue queue metadata. We make rampant use of issue "components" (a pre-defined list of categories defined by the project maintainer to help find issues), as well as "stauses" (needs work, postponed (maintainer needs more info), reviewed and tested by the community) that put issues through a given workflow. Github offers non-structured tagging that would be a poor substitute for this, and as mentioned above, switching any of these statuses on any issue needs to be done by über-busy maintainers.

As a result in the short-fall of Github's issue queue/workflow features, this original proposal was written around the idea of only using Github for the code management, and not the issue queue. But doing this seems to negate a lot of the benefits of the proposal in the first place. :\ This is something we can likely work with Github on (especially if we become a paying customer of theirs), but it's worthy of note.

I know there are other many, many other pieces of feedback that are not reflected here, but I'm trying really hard to "bubble up" the biggest ones. Do you feel this captures them? If not, let me know!

There's something very similar (also trello-like) for GitHub.

I just wanted to point out that Github has the capability of creating releases, and if we can use it, that's great. If it doesn't make sense, that's fine too.

You have posted this point several places in this thread. My response is here: https://groups.drupal.org/node/313083#comment-955518

Thanks for the insight to how Github works for the Symfony community Lukas.

What would be interesting to know in addition is what kind of users it is that participate in the Symfony issue queues. Here on d.o for example there are just under 30k users that has configured git access, but there are almost one million active accounts. Thus we have a lot of users with other main experiences and roles than developing that are participating in the issue queues.

Yes, our issue queues are often quite noisy as a result and sometimes the discussion are, shall we say, quite passionate about things. And sure there is bikeshedding going on too.

For me that is a price well worth paying for the added value all these users, me included I hope, brings to the community. Particularly as Drupal over the years have moved to a more UI-driven sitebuilding platform feedback from and testing by users are invaluable.

There are also many users, again me included, that have discovered they also wanted to give coding a go thanks to this. While my own skills are still very basic and at novice lever, there are many others who now are respected contrib developers and project maintainers.

Thus far in this discussion I haven't yet been convinced that will be possible to retain after a move to Github. I think the risk is quite huge we will lose most of them in the move.

I notice you have been a member here on d.o for 2+ years so maybe you can shed some light into this for me. Would be greatly appreciated.