That was a very sad read for me. 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.
To put more anecdotal evidence on the table: The Eclipse Xtext project moved a very long time ago as one of the first Eclipse projects to Github to encourage new contributions with the very same motivation as described in this thread again and again. After all, Github is where the cool kids play. What could possibly go wrong? The success was ... questionable. It turned out that putting hundreds of thousands of lines of code from hoster a to b (Github) doesn't make contributions easier per se. 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. The mere location of the Git repository that is to be cloned, is only a sideshow in that entire dance. I can only second what Rolf already said: 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") . Does anyone really believe that this would be more encouraging if the issue was filed on Github instead of Bugzilla? Community growth does not come from changing source links from eclipse.org to github. I don't want to say that Github or Gitlab or whatever hosting is good or bad compared to what we have. But I want everyone who is participating in this discussion to consider, if blindly making the existing mirrors on Github the primary git repo will change *anything* when it comes to growing the ecosystem and attracting new members to this community. Just from looking at https://github.com/eclipse/eclipse.platform.runtime and its 16 stars and 30something forks should tell us that the source hosting itself is not the reason why people do or do not contribute to open source. 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). 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. Kind regards Sebastian On Thu, Mar 18, 2021 at 12:00 PM Mickael Istria <mist...@redhat.com> wrote: > > > On Thu, Mar 18, 2021 at 10:22 AM Ed Merks <ed.me...@gmail.com> wrote: > >> I'm not sure many of us are convinced that GitHub itself is a magic >> bullet despite anecdotes to the contrary. >> > > I have the impression that the majority of committers who also happen to > use GitHub for other (Eclipse or not) projects do agree that GitHub is an > enhancement for the project community at large over Gerrit. > People who are not familiar with GitHub seem more driven by fear of change. > > Surely no one will be contributing to any part >> of the platform without using Eclipse, or am I missing something? >> > > You're missing that many quick-fixes (labels, typos, documentation, releng > change...) are actually not requiring the Eclipse IDE to be implemented > easily. In some cases, those quick-fixes can be produced via GitHub editor, > even on a phone in a bus. That brings the highest ROI to contributors and > requires 0 extra workflow learning to contribute. > Then the CI stack pops-in to perform the automated validation (as users > don't use "stronger" tools, there contribution are more likely to cause > errors so this validation phase becomes more important). > > My sense continues to be that the platform team's own "not invented >> here, or not invented by us" aversion is the primary problem of a missed >> opportunity here. Folks just don't feel a need or desire to promote >> something that's simple and works well, nor to contribute to >> improvements if it doesn't 100% suit the ideals. > > > If this comment is about Oomph, then Oomph is mentioned/promoted in > https://wiki.eclipse.org/Platform/How_to_Contribute . And I don't think > Platform as a project has prevented anyone interested from promoting Oomph > in other documentation, talks or whatever. So unless I missed something > here, your comment seems lacking substance. > > >> Instead I see notes >> about "one click cloning a repo" being really cool when we have "one >> click provision an entirely functional IDE ready for contribution" >> already available for a long time. Why is that I wonder? >> > > If you're referencing > https://github.com/mickaelistria/redirctToEclipseIDECloneCommand/ , then > it's a pity you fail at seeing the difference: this one is supposed to work > for any GitHub project without *any* Eclipse/Oomph specific file addition > and maintenance. This difference is major in the scope and goals of clone > link vs Oomph. > However, as mentioned earlier when I sent a note about 1-click link clone, > the link approach would be totally viable for Oomph as well: if some Oomph > contributor were interested, it would be totally possible to generate an > Eclipse link command as well to import a Oomph profile and open the wizard > to provision it in the IDE. It's just a matter of someone interested in > doing it. Once this is possible, such link would be a great addition to > Eclipse Platform project documentation pages. And this can already work > independently of Gerrit/GitHub, so there is no barrier preventing it. > > What's to learn? Most users are already familiar with using it via the >> installer. > > > People I've seen using the installer basically stick to the product > selection page and apply stuff. It's good, but I don't think those people > get a sense that the installer does more than an installation and that the > underlying Oomph can do full provisioning. > > >> In any case, by implication, apparently what people really >> care to do is learn how to install and then use Eclipse (the right one >> with PDE) as well as EGit to clone the correct URLs. Then they know to >> magically import the correct and only appropriate projects into the >> workspace from that clone, without reading anything. Then these highly >> motivated users know to set up a proper API baseline from their >> ethereal knowledge. When faced with the sea of red errors, they continue >> to try to figure out (without reading anything), how to make them go >> away before they can make their first attempt at a contribution. (Oh >> yes, and don't forget to copy/renamed the SWT .classpath file manually, >> without having read something to describe that tiny but fundamental step.) >> > > See comment above about many interesting changes not requiring all those > tools and better handled by GitHub online editor. > > >> This whole premise seems beyond questionable to me. Instead, let's >> focus on moving to GitHub as a magic bullet, with no technical >> discussion about the merit of that because it's a social decision not a >> technical decision and the conclusion is foregone... >> > > Many technical aspects were discussed, blocker concerns raised, tickets > open to EMO or GitHub... You're neglecting those part of the discussions > were/are happening; but it's been there and it's still open. > Moving to GitHub is indeed entirely a social decision; it's about > community growth. Once the technical concerns are mitigated, it becomes > really a decision of "do we want the project stay in our hands of Eclipse > old-timers or passionate/paid Eclipse contributors" or "do we want to make > the project open to a wider world". To me, sticking to marginal > contribution workflow is going to hurt severly the Eclipse project > contributor diversity in the next ~5 years and put the project at risk of > becoming unstaffed and irrelevant; only the later approach can make the > Eclipse Platform project sustainable for a longer time; so, selfishly, it's > also the approach that will guarantee me -and I think others- more paid > years working for Eclipse IDE. > -- > Mickael Istria > Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/> > developer, for Red Hat Developers <https://developers.redhat.com/> > _______________________________________________ > 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
