Slightly late comment on the goal. The goal is to facilitate contributors and get more contributions. I guess that we can agree on the goal.
Then you can start thinking about how to reach that goal, and moving to GitHub could be an option and part of the solution. 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. Surely there are some things in the workflow that can be optimized, but those can be changed regardless of a move. But also keep in mind the possible drawbacks of the move, not only the effort of the move, but also the dependence on the policies of an external company. 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? 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. Personally I think that the following topics have a bigger impact than 'just' the way how patches are submitted, many people will not even reach the point of submitting code: * 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? * 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. * 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. * 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. * Total ignorance on bugs submitted by the community, e.g. https://bugs.eclipse.org/bugs/buglist.cgi?cmdtype=runnamed&list_id=20462834&namedcmd=Platform%20-%20External%20no-comments * And even if people reach to point of submitting code: The backlog of reviews on submitted issues in Gerrit 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? But who am I, never earned any penny with my work on Eclipse, I can freely spend my spare time on any topic I like, without being hindered by any companies policies/expectations. Best Regards, Rolf Op di 16 mrt. 2021 om 13:25 schreef Mickael Istria <mist...@redhat.com>: > The goal is not just to change tools for the sake of changing tools, as > there is a relative consensus that the current tools we have (BZ and > Gerrit) are pleasant enough to work with. > The goal is to facilitate contributions and get more contributors, this is > one of the key factors the sustainability of any OSS project. So it's not > really about GitLab vs GitHub; it's more about exposing code and > contribution process on whatever.eclipse.org vs GitHub. GitHub is the > platform where most of OSS projects and contributors are, and that's not a > temporary thing now, it's been so for many years and has only grown in size > and quality. It's global, bigger than eclipse.org has ever and will ever > be, and it's now the main driver of OSS development practices (contributor > agreement and license check bots are basically providing a good enough > plug-and-play governance). IMO, the real question is not really about > whether to move some process to GitHub, as it will sooner or later be a > requirement for project sustainability; it's more about how and when to > move code and processes GitHub. > _______________________________________________ > platform-dev mailing list > platform-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev >
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
