Move Git repositories to Github

Of course I can be wrong, but personally I think that the efforts of Drupal should focus on drupal and Dev itself (project management, development, ...). Whatever you do not in this scope out is slowing the evolution as a tool/framework.

I see benefits in both options, but since github as tons of extras for developers, I think we - as a community - should really consider moving the code to github, or something similar. The other option is that we speed up the development for the D7 migration, but I think to be able to do this we probably will need (a lot of) resources/funding.

For the issues we might consider using rest api to integrate into d.o. and I think meta issues should stay on d.o.

AFAIK the integration with the packaging and the testbots should be pretty straight forward, for testbot we might considers using Travis.

PS an alternative might be https://enterprise.github.com or maybe http://blog.gitlab.org/gitlab-6-dot-0-released/ they have comparable features, but a different pricing :-)

I'm really up for hosting repositories on GH or any other provider that offers similar quality of services.

Though, I'm not sold d.o is good for issue discussion. Discussion viewing code as in GH is a great feature.

I think GitHub is a great service. GitHub also offers an API, so we can still create d.o project pages, based on the data in GitHub. There is already a Drupal mirror on GitHub (github.com/drupal/drupal), so 1) you can see what the code browser is like and 2) we might consider accepting GitHub PRs for a while, just to see what happens.

See http://plugins.jquery.com/ for an example of community using GitHub to host contributions, while still providing a central plugins registry.

It really would be great!

Would you be able to provide more justification for why you think we should move only the code repos to Github and not also the issue tracker?

Since one of the stated benefits of this proposal is "Lower barrier for people to contribute" (which I agree with), it's odd to me that we would then choose a non-standard collaboration method for those repos, and thus largely negate that benefit.

In other words, people who use Github use the whole enchilada: the code repos, the issue tracker, the wiki pages, etc. They're used to collaborating on other projects on Github that way. If they had to do something different for Drupal, and go get a separate login in some other site and fill out forms they've never used before, etc... don't we lose a lot of the advantages of doing this in the first place?

I mentioned this in the issue summary but let me elaborate

So, the way github works, an issue is opened, you decide to work on it, create a branch in your fork, hack on it, PR it back.

This is a Perfectionist Pat workflow. This is a workflow that also works well when you work on a dayjob and you are assigned tickets and you are resolving them.

This is not a community-based workflow, however. If I post a patch to the issue queue, there are a large amount of people who have a chance to see it -- anyone subscribing to that issue, looking at the queue for that component, etc. If I push a commit to my own fork, that's more of a "If a tree falls in a forest and no one is around to hear it, does it make a sound?" kind of problem.

I have emailed github roughly outling a solution where one fork/branch from an issue and the created, related branch will automatically get a PR and that PR is linked from the issue. Now, visibility is back.

However, until the visibility issue is solved I will maintain that this is a hype-induced, not-well thought out idea which will, in one deft move, fragment any collaborative Drupal development beyond any repair.

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.

I may be an oddball, but when I contribute to core, this is my current workflow:

1. Create a branch for the issue, if I haven't worked on this issue before. (I have exactly one copy of Drupal for dev; this might change soon)
2. Apply and commit the current patch (or interdiff), if any.
3. Hack
4. Commit my changes.
5. git diff HEAD^1 > interdiff.txt
6. git diff 8.x > node.fix_stuff.12346677.5.patch
7. Post to d.o.

Here is the github workflow, with hub (a backwards-compatible wrapper around git) installed:

• First time I contribute:
  1. alias git=hub
  2. git clone drupal/drupal
  3. cd drupal
  4. git fork
  5. Hub asks for my GitHub login. It converts it to a set of API keys, and remembers them.
• New PR:
  1. git checkout -b smash_poll_module
  2. Hack
  3. Git add/commit.
  4. git push --set-upstream Gaelan smash_poll_module
  5. git pull-request
  6. Hub asks me for PR description. If I include "fix #5" in my PR description, these things will happen:
  7. My PR be linked to in issue #5.
  8. #5 will be auto linked in my PR description.
  9. When my PR gets merged (one click operation for maintainer), #5 will automatically get closed.
• Improve my PR
  1. git checkout smash_poll_module
  2. Hack
  3. Git add/commit
  4. Git push
• Improve somebody else's PR (that they kindly gave me commit access to (yeah, that requirement sucks)).
  1. git checkout http://github.com/drupal/drupal/pull/123 (this gives me a branch for their PR; first time only)
  2. Hack
  3. Git add/commit
  4. Git push

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.

I remember when I first became involved with the community. Things were confusing. This seems somewhat more confusing, and it may make it more difficult for people to get involved. I do like the idea of an evidence based approach, and I think that measuring something around increased contributions is a good idea.

I Am concerned from an accessibility point of view. Github's UI is not particularly accessible, and our community has no control over improving that today, or preventing it from getting worse tomorrow.

After reading through this whole thread I clearly get the impression that the proposal stems from issues with the current code production and collaboration workflow. While that is a very important part of development, there are a lot more that needs to be taken into count.

One of the aspect of the Drupal community I love the most, is that it is fairly easy for almost anyone, including with no coding skills, to start participate through the issue queue.

@webchick had good arguments, https://groups.drupal.org/node/313068#comment-953633, that moving to github isn't about picking parts we like there and keep the rest on existing features on d.o - "In other words, people who use Github use the whole enchilada"

That would mean moving the issue queue too. What features would we then lose? Take moving issues between projects as an example. It is a feature that greatly improves the collaboration UX between developers and projects on d.o. Someone pointed out that is not equally easy on github.

@chx pointed to the patch workflow, https://groups.drupal.org/node/313068#comment-953888, and specifically that the current one is community based and that will probably be lost on github.

For me being able to quickly spin up a Drupal instance with a patch on simplytest.me has been the best productivity improvements since I first joined the community. Its also the best improvement ever been added for non-coders to help testing things incredible easy.

From my point of view, it isn't the repository that drives development of Drupal - it is the issue queue!

The IQ is also where the strength of our community lies, its where users of all roles can meet, discuss and collaborate on things.

Michael Keara, with a little help from me, presented a session at DrupalCon Portland about the "Love and hate in the Issue Queue garden". Or, as I called it "Our Drupal Workplace: The Issue Queue" http://www.tsvenson.com/blog/2013/05/our-drupal-workplace-the-issue-queue.

Maybe moving to github solves some short term problems for code production. But, from what I have read in this discussion I have a bad feeling a lot of the current cross role collaboration might be lost, resulting in the risk that developers will become more isolated from non developers.

Is that really what we want?

Localize.drupal.org is currently dependent on the release tarball system to extract and parse out translatable text. Decentralising that would be an issue, but sounds like that is not the proposal here. Just wanted to make that point so its considered for similar ideas.

Some common d.org issue queue workflows:

• user files an issue core, but it's a contrib problem. Maintainer moves the issue to the right queue.
• what appears to be a code bug is in fact missing or erroneous documentation. Maintainer or reporter reassigns the issue's component.

How do we do things like this on github?

Seems like discussion has now shifted to the level of individual features. This is great, but I can't keep up with all the discussion here, and there's not really space for it in the issue summary.

I made this spreadsheet https://docs.google.com/spreadsheet/ccc?key=0AusehVccVSq2dEtuWm1JQ1ZSV1Z... to capture this information. I made an attempt at filling out some things, but it's open to all to edit, so please help fill it out!

I'll add this to the proposal summary too.

Mail from GitHub:

Gaelan,

I haven't heard of anyone doing quite what you say here [referring to my "Druplicon sees the world" idea], but something that definitely does happen all the time are pull requests from fork to fork. So rather than just editing someone else's pull, you just make a pull request from your fork to their branch. Unfortunately, it requires a little more know-how to target a network branch than to just update a d.org issue as they are today, but this is absolutely something people do.

Something else to consider, and what I'd probably suggest, is that you can make a pull request from a branch to master in the same repository. Many, many open-source projects work this way. The core maintainers work on branches in the main repository day-to-day, and occasional or drive-by contributions are handled with forks.

With this setup, you get all of the same pull request goodness without any of the fork friction. The only thing that would be a real change from d.org's current workflow is that it would be harder for a core contrib to jump in and fix a new contributor's pull request without something like what you've said. The usual core contributors could all edit each other's branches as they can now.

People do run into this, and what usually happens is that the core contributor will check out the pull request, fix it up, and push to a branch on the core repo and merge that.

Your idea of an API that grants permission is possible. It's easy to imagine an oauth application that contributors give access to which will grant core contributors permissions on repositories named `drupal-*` or something. I'm not sure we'd exactly *recommend* it but people integrate with project management systems in lots of ways.

Hope this helps,
Ben

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 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.

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!

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

If Drupal is oriented around not re-inventing the wheel(i.e., adding symphony) then why are we doing just that with git.drupalcode.org....

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

While it seems accurate, it feels a bit skewed towards github and a bit of the grass is always greener on the other side syndrome.

The drupal security team spends a lot of time making sure things like this:

http://vel.joomla.org/articles/844-spotting-spam-code-in-malicious-exten...

don't happen

tl;dr;

Was there a way to prevent this happening?

The answer to this is 'no'. The extensions as originally submitted to the JED were fine, there was no way to pick this up. Even if they had contained the bad code it is unrealistic to expect the JED team (who are a small group of volunteers) to conduct a thorough security scan of every extension in the directory.

Drupal spends a lot of time trying to make this happen.

github is nice for developers that are targeting developers, when you are targeting people that are not developers that cannot be expected to test all the code they download, it falls woefully short.

One note is that the linux kernel does not accept patches generated by github as the tools encourage bad patches.

As a completely unrelated note, it is possible to use Github Pull Requests on Drupal.org's patch workflow.

1. Fork drupal/drupal: http://github.com/robloach/drupal
2. Create a new branch for the Drupal.org issue # in your repository: http://github.com/robloach/drupal/tree/2038135
3. Commit your changes to that branch: commit
4. Compare the branch to Drupal's original branch: drupal:8x...2038135
5. Append .patch to the URL and upload that .patch to the issue: 2038135.patch or 2038135.diff

Trying to file an upstream issue against symfony with Daniel. I'm further against github now.

The connection between pull requests and a specific issue is not tight and there is not real coherent view of the history and activity.

Also, my comments on the PR were erased since Daniel force-pushed changes to those lines. As much as I'd sometimes like to erase a review's comments, I don't think that's in line with our community values.

Why should the only two options for the repositories be moving to GitHub or keeping them in D.O? (I'm including changing to self-hosted GitLab and similar ideas hosted on Drupal.org in the latter group.)

Why not allow project maintainers to choose where their repository is hosted and their preferred workflow for their project? For the project page, they'd just need to tell Drupal.org where the repository is hosted (and perhaps even what branch applies to what Drupal major version).

The new D8 fork by quicksketch, Backdrop, uses github. You'll note that they had to set up duplicate projects to manage the project's issues "because of Github restrictions on the use of labels and issue assignment". Food for thought.

Free the energy of the poor people working on the project module, and better put that into integrating Github with what should be kept on d.o.

As this has a lot of votes, it might become a reality. Incredible...

Ah, yes: moving a project as big as Drupal mostly to github should allow to negotiate some favorable terms with the github team as to restrictions that would hinder our work. Leverage our project size to our advantage }:-]<

Ah, yeah, and if it turns out Github is just not right: replace Github with [other external service that is better]
To get the discussion going is the important point.

let's raise more awareness and really schedule the move, is all that people want really, no politics please!

I don't want this. I think it's a bad idea - we should be improving Drupal.org if there are problems, not moving into a 3rd party service. There are three primary reasons for this:

1) What happens if github disappears someday? It's not likely, but it wouldn't be the first time a big company crashed.
2) If/when github goes down with technical issues, we are at their mercy as to when they get the issues fixed. If they take a week, then we all have nothing to do but wait for a week, hoping that they get it fixed ASAP. For those of us who are developing with Drupal for our companies, being at the mercy of a 3rd party is not an acceptable risk.
3) Drupal related projects/issues etc should remain on Drupal.org. What kind of advertisement is it for Drupal if we cannot even build infrastructure on Drupal to handle the things it needs? It would be like going to Microsoft to download Apple updates.

let me deal with your points one by one

1. it is not honest not serious to deal with what ifs in that manner. what if google disappears! yes we can be even prepared for that. we just have mirrors into other third parties? an example

2. this is typical response from an insider, not trying to insult or anything, but the propaganda of drupal sometimes get in the way, we are big, nobody will be able to handle us, we conquer the world with millions of websites, when in reality is ok, but it is not that we cannot use github normally like the rest of the planet

3. the advertisement is clear, drupal should be a CMF, be good at that, not at maintaining legacy code that deters its advancement

Again as i have been saying all along, I have dealt with those excuses and there is no grounds or case.

lol i should lower my own tone, apologizes. It is that the debate gets the best of me. Sorry. But i back up the points made.

let's stick with github because is the best for FOSS, that is subjective but it has become a defacto standard.

I am not against gitlab or any other that is sound

Gush https://github.com/gushphp/gush http://gushphp.org was born to deal with those problem via adapters. As long as they have apis is fine.

The point here is to move to a really collaborative tool that handles all programming languages repos of today and law firm documents and what not. That is github today, then create the tools and platforms to make it robust and portable so we can move easily to any other third party.

This is in programming what OO does, is call adapter pattern. You don't need to marry any implementation. not even your own

Why would I be forced to create an account on Github and hand over all my data to an external entity (obviously I am not talking about the code itself here, but about one's profile, activity, etc), when all I want is to contribute on drupal.org? If you really want to use PR, why would you need an external centralised platform, when it is actually a matter of adding a remote? (Even though I am personally fine with our current patch workflow).

If the community believes we need more specific tools, I prefer self-hosted ones like Gitlab.

Don't forget that there's nobody stopping anyone using multiple remotes on their contributed project so they can use Github for development & support, and then push to d.o for releases.

i think the reason that i do have work on github, does not emphasizes of the flow of collaboration. Only those doing strong FOSS with PR flow can attest on how this flow on git is very flexible.

So even if it is to move to gitlab self hosted, that is definitely a win compared to the current state of things.

attik the library you mention is used by Gush too

1. It should be easy for anyone to contribute to an ongoing issue without involving another human. This is absolutely paramount. There is nothing more important than this.
2. At the same time it should be easy to understand why a change was enacted in a way it was.
3. The open source world moved to github. We need to as well. This is debatable but unavoidable.

In the current github way we can do two things without involving bots:

1. Create an issue and link code changes to it. This satisifies 1. but kills 2. as the conversation becomes a two level tree where the top is the issue and the leaves are the pull requests. Reading this becomes painful fast.
2. Create a pull request and then when someone else wants to work on it, they can fork the branch the PR was opened for and link to their PR. The conversation hopefully becomes a linked list (but even that would require a bot closing the original PR the moment a new one is submitted based on it). Without a bot, this becomes a full blown tree and an incredible mess.

What we need to think on is better workflows either involving Github the company or Github APIs.

@crell, @chx is with us on this. I believe we fail to see he is up for the move, just that he is trying to warn us to just be very careful and to prepare the road before we walk on it.

@chx let's try to build a plan and perhaps launch a document where we summarize pros and cons and ways in which a possible beta flow would work on a system like github or gitlab, and with a layer of a tool like gush be it whatever or a custom one.

I agree we should first not talk about implementation details, but rather on sketching rather the current flow and how can this be improved should we move to a bottom layer to say gitlab-like platform.

for instance something like:

Flow 1:

1 It should be easy for anyone to contribute to an ongoing issue without involving another human. This is absolutely paramount. There is nothing more important than this.

Anyone can do fork, checkout branches and send PR's towards each other branch, or in particular Drupal would have cannonical branches 1 per real issue (not all issues are cannonical issues, they are say differentiated by labels and are part of a milestone in the system). So given a top layer of guidelines perhaps we can achieve more closure and agreement, this is just an example, and probably chx can help bake it, we all will be able to help bake things some more.
So anyone can submit code, and we have to have a guideline to connect their submission with the main cannonical issue. Also aided by labels or branch convention or PR title tagging convention and github features for linking PRs/Issues.

1. At the same time it should be easy to understand why a change was enacted in a way it was.

This could also be achieved by a status, more than just closed or open (green or red on github), but more something like a reference with a summary of whoever wants to be connecting their contribution to the thread. they can use gists or even patches, maybe the tool for authoring should be smart enough to pick up the patches that are in a thread and build later a consolidated PR to be lined at the bottom. Just an idea.

1. The open source world moved to github. We need to as well. This is debatable but unavoidable.

We all are agreeing here. This will come with greater strength as we start registering components from drupal in packagist or/and also in their own drupal packagist, however not making distinction is probably what will make drupal more widespread and invite further contribution. Creating any type of in house barrier will always deter a great majority of contributors who know that they can just fork and PR any repo worldwide available in github. I for instance personally find very disconcerting even to have to switch from github to gitlab just to depend on a lib. This of course is subjective and gush or others could make it a bliss or maybe a search across that will make it platform independent but it is more of an unsaid norm to be on github and packagist.

also there are currently good boots out there, proprietary but we actually also started a gush-bot-io https://github.com/gushphp/gushbot mimicking http://fabbot.io/ which does minor stuff for cs.
Having a full rest bot that communicates even with a cli like gush or other could definitely do things a bliss.

Just as a note also, Gush was made for maintainers and contributors, and i give always an example from a friend who QA a software on a mac, but had to install windows and she clicked so much the track on windows that she had to stop working for days and the doctor told her swollen elbow needed to stop working. It was pretty bad, and then we created Gush because even github interface clicking and doing this so many times is just not humane imo.

2 cents

Sorry that I didn't read all thousands of comments on this page, but I just wanted to share my experience with Drupal.org and Github.

I think it's great that Drupal is using more 'standard' frameworks/tools etc, like the Symfony core and Composer.
Just like Composer is the de facto standard for packaging packages these days (and hopefully Drupal modules too?), Github is the standard for open source projects source control and collaboration.

It might not fit the current workflow for 100%, but seeing so many projects on Github, I'm pretty sure that nothing is impossible to overcome, certainly as Github has offered help..

I understand that the issuetracker doesn't have as many features, but I think a lot can be helped by just tagging labels. The current drupal issue trackers always appears to be slow and a bit chaotic, due to all the options you have to enter/search.. Certainly compared to Github, which let's you create/respond to issues within seconds without too much hassle..

Also, the patch system is horrible. The issue tracker is often full of half-done patches where I can view the changes, but I usually just want to see the result (+ changes) in a nice way, not a text file with +/- and line numbers..
With Github, you can just view the Pull Request changes or view the fork's code entirely, good for easy testing..

And for the code itself, is it at all possible to even view the code without downloading/checking out? For many projects/forks I just want to have a quick look at the code, see the latest commits and compare versions. (EDIT: As I'm writing this, I just found http://cgit.drupalcode.org/drupal/ but that looks horrible compared to Github and is not really promoted on the website/module pages..)

I also don't know how to easily submit a patch with the webinterface, which I do with Github quite often (typos, small tweaks etc are fast to fix without checking out, fixing, pushing etc)

I really like Drupal and I love that it embraces Symfony and other tools, but PLEASE make it easier to contribute. Especially now that you use those other tools, we have more code in common with other project, so outsiders are probably more eager to contribute some code/fixes when they have a familiar interface.
Don't you want to be part of the 'PHP OS Community' instead of only the 'Drupal Community'?

(Sorry about the negativity about the drupal.org issuetracker/git interface, but I never felt inclined to actually view the code/submit a patch, in contrast to Github which makes it all soooo easy.. I love Drupal itself ;) )

Github business is to provide a friendly environment for new and diehard coders. Besides that we could have all the issue queue and workflow ensured by consuming the github api.
Github workflow (PRs) is the standard in the vast majority of Open-Source, this also would make things easier for newcomers. Also there is a community and company effort to help people with git, versioning and the workflow of contributing if we move to github.
I think we should invest in the core functionality of D.O, which is not code but people engagement, let it to someone who's core business is to make code easier.