An attempt to encourage the existing community to make a decision based on facts is put aside in favor of baseless claims about contributors who will do fixes on a project with millions of lines of code *on the phone* *on a bus* is far from helpful.
You saying it's baseless doesn't mean it is. Mind you, it has happened to me several times to make GitHub edits on the phone, in a bus. And those contributions were accepted by the project. Yet another anecdote for sure, but definitely not baseless.
There must be more to this exercise apart from the *fork on Github* culture to attract new people. A contribution to a complex software system is not encouraged or hindered by the location of the Github Repository. It's encouraged or discouraged by the way we communicate with each other, how other opinions are valued and how we deliver feedback on ideas and expressed thoughts.
Although that's true communication is important, one can contribute to GitHub without knowing anything about the culture of the project; just by applying a workflow that's standard. Then the contributor face the culture during reviews and so on. The location and initial workflow is more important than anything else for a new contributor, it's the very 1st thing they face and have to deal with, before receiving any communication.
Too often I've seen tickets being ignored or comments being made of the shape: Go on, debug yourself (in the same spirit as the subtext in "I don't think the Platform as a project has prevented anyone interested from promoting Oomph" which to me reads as "Go on, write the contribution guide yourself") .
You read the subtext well. And what should be the answer then? "Yes sire, I'll do whatever you want and change my priorities just for you despite the fact that neither I or my employer are not a all interested in it and that you're totally capable of doing the change yourself and aware that it's totally allowed to you as a committer"? At some point, it's too easy to put the responsibility on some people not doing things when one has all the capabilities of doing it themselves. People who want thing to change one way or the other have to invest in making this happen. It's how community open-source works and the only way it scales.
While we discuss community growth, then so be it.
Ed, Sebastian, please improve the contribution guide, please create the 1-click Oomph provisioning... Why didn't you as committers/contributors do it already? Go figure...
(I hope you realize how annoying that sounds - that's an intentional emotion experiment, not the style I really like to write, but the style I read too often to remain patient)
I'm not saying that I have a solution for the underlying problems either. So instead of putting effort into a large migration of builds etc just because, we should analyse the status quo and figure out, how we want to work in the future and the impact of that workflow on the values of Eclipse open source community (trustworthiness, IP checked, etc).
That's again something that the Eclipse Foundation itself has clarified: developing Eclipse projects on GitHub allows to keep the same level of conformance to the Eclipse Development Process as running it on Gerrit. So it's not about "values", this was clarified, it's really a matter of deciding which subset of the software development world we want to target as potential contributors.
To add a little grain of constructive feedback here and picking up Rolfs remarks:
Just looking at the readme on
https://github.com/eclipse/eclipse.platform.runtime - the descrption "How to contribute" is awefully complex compared to a single Oomph Setup link. Maybe, just maybe a rework of that one and a few of the other suggestions Rolf made, would be more bang for the buck in the short term and give enough time to prepare processes, tools and the like for a potential move to Github or Gitlab or whatever.
Good idea. I'm sorry I have to write it although it looks like those are forbidden words, but maybe you can contribute this improvement?
