Recent comments

Good point about Drupal governance and decision making power.

I don't see a consensus ever being reached within the community on whether or not the perceived benefits of this would be worth the amount of effort required to switch and the amount of perceived impact on the community.
I haven't really seen much in recent debate that hasn't already been said in previous debates, which points to time wasting like you say.

Another thing is that if professional developers are deterred from contributing to something they want to contribute to just because they don't want to learn the ways of that community (it isn't just the Drupal community that have their Drupalisms, all communities have their own ways of doing things to some extent), then I would argue they aren't much of a professional.
Working with technology means learning new things all the time.

I would say there are other areas of Drupal that are larger barriers to entry than learning the workings of Drupal git and issue queues, which really aren't that much different to what you would find anywhere else.

nice .. has nothing to do with what I was referring to about github ... but nice.

Github offered to send a team out to discuss issues like this and help us find a solution ... all the way up to the point where they offered resources to help craft and document the solution.

The only comment I'm adding to continue this thread is that as smart as everyone in this community is ... maybe we should see what they have to say. I know they would like to talk to us.

Thanks for bringing this perspective into the new discussion. A lot of the talk has been about new users. We should totally be thinking about new user experience and engaging new users. We should even be considering how better to onboard them. However as jthorson did such a good job of pointing out, we have a vibrant community.

The fact is, much of drupal.org is the codification of the community and culture that we all share. We should keep this in sharp view in this discussion because as important as new users are, they're a close number #2 to supporting the community and culture that we already have.

@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

If someone is already contributing to almost any other PHP open source project, they already have a GitHub account. If we want them to contribute to Drupal, why should we force them to create an account on Drupal.org and hand over all their data to another entity (profile, activity, etc.)?

That question cuts both ways. If we want to attract more contributors, we need to think about it from the "new user" perspective, 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.

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

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.