Though, it could be sufficient to write a decent manual that describes the way of working within the Eclipse eco-system, targeted at people who are used to the GitHub workflow. I.e. write down the steps in the workflow and for each set make the relation to the GitHub workflow.
Variations of this has been attempted many many times, and never succeeds. Because we need to face 1 truth: most people dislike reading docs and have other priorities than learning new ways. And this "laziness" doesn't mean such people are bad developers, they'd still be valuable contributors.
Do you really want to depend on the free services of an external company, or does the project want a proper SLA (paid or free) with real guarantees?
The Eclipse Foundation has allowed usage of GitHub with some SLA provided by EF (and maybe GitHub). I think if the EF chose that, it's relatively safe to assume that GitHub is a safe host for an Eclipse Foundation project. It's not a debate that applies at project-level.
Also, there is no free lunch nor a silver bullet, just moving to GitHub will not gain (m)any contributors. People will not get magically more involved in the project, for that the community should be nurtured.
My experience with moving m2e to GitHub, or with the activity on Eclipse projects hosted at GitHub gives me an opposite impression: more people do join the discussions, new people as well. The project show more activity and "freshness" on GitHub overall.
* Eclipse RCP/IDE is not the cool-thing (anymore), it is old technology. How to market Eclipse as a cool thing? What makes it special? How make people proud to have contributed to Eclipse?
IMO, it's not something we can change. Because Eclipse Platform will never ever be again a hype technology and any strategy that assumes it can become hype again is vain. We need to surf the "not the cool thing anymore" wave, not try to push the wave in another direction.
* Having hassle free setup of the development environment. I think that the functionality provided by Oomph is a game changer here: no lengthy complex description of setting up the environment, just a few clicks and within minutes you are ready to start coding on a patch. (And Signed-off-by is automatically enabled). It would be really nice that the full submit/review cycle would be supported from within Eclipse so you never need to switch to other tools.
Gerrit vs GitHub is not changing anything on that matter.
But I think Oomph cannot be the silver-bullet of attracting new contributors: Oomph is still an Eclipse specific technology and workflow newcomers will need to learn and read about in order to become efficient. Oomph is to provisioning what Gerrit is to Code Review: maybe the best tool around, but that almost know one beyond a few dozen of people who've been working on Eclipse stuff for years will care to learn.
* From an external perspective, the project seems outdated and dying. For instance, many of the website pages and wiki pages contain outdated content (e.g.
https://www.eclipse.org/eclipse/development/ next release is 4.9?), are incomplete, describe long gone processes (bug triage process?), etc.
Again, maintaining that would be more effort for current contributors to maintain something different, that most people will never read because they're used to other -better- workflows with GitHub.
Just having this site a GitHub repo with a CONTRIBUTING.md makes all that data easier to find and maintain, more valuable.
* Total ignorance of the communication channels to the community. There are hardly any experts active on the Eclipse forum pages. Even straight forward questions get hardly any answer, let alone the more complex ones.
That's not related.
* And even if people reach to point of submitting code: The backlog of reviews on submitted issues in Gerrit
Those are definitely issues in the project that needs to be improved; with or without GitHub.
For me, moving to GitHub would not have priory. Why burn resources on that if there aren't even resources available to properly facility and support the community?
I believe that moving to GitHub will increase the amount of resources; and that it will make easier to get new committers to increase support to the community.
