May I request to keep the component library hosted in github? So the contribution path is easy, Project is discoverable and hosted in a familiar place for rest of the world to submit issues, fork and submit pull requests and so on?

In T253364#6157467, @santhosh wrote:

May I request to keep the component library hosted in github? So the contribution path is easy, Project is discoverable and hosted in a familiar place for rest of the world to submit issues, fork and submit pull requests and so on?

That would make this similar to T252463: Determine how to host Chameleon skin and Bootstrap extension in gerrit while primary development happens in github. (Mirroring from Gerrit to Github would provide the same "discoverability". @santhosh: Is there any data that there are more contributions when the canonical hosting happens in Github instead of Gerrit?)

In T253364#6157751, @Aklapper wrote:

In T253364#6157467, @santhosh wrote:

May I request to keep the component library hosted in github? So the contribution path is easy, Project is discoverable and hosted in a familiar place for rest of the world to submit issues, fork and submit pull requests and so on?

That would make this similar to T252463: Determine how to host Chameleon skin and Bootstrap extension in gerrit while primary development happens in github. (Mirroring from Gerrit to Github would provide the same "discoverability". @santhosh: Is there any data that there are more contributions when the canonical hosting happens in Github instead of Gerrit?)

No, I am not asking to mirror in gerrit or github. Instead, just have the development, issue tracker, release management and CI in github. We are talking about a foundational UI library for Wikimedia and its wider ecosystem based on our learning from OOUI which was developed in gerrit+phabricator and ended up as a uique library used only by Wikimedia. Just trying to avoid that mistake again.

Also, this is only about the UI library. Not about the new search implementation using that library.

@santhosh: Correlation does not imply causation. If OOUI had no marketing that's what happens, no matter where you host it.

In T253364#6157467, @santhosh wrote:

May I request to keep the component library hosted in github? So the contribution path is easy, Project is discoverable and hosted in a familiar place for rest of the world to submit issues, fork and submit pull requests and so on?

I wholly empathize with this sentiment. Gerrit hosting is a deterrent for non-wiki.edians to explore the project and to contribute. This and the development culture are probably both reasons for why there's almost no open-source community around MediaWiki.

However, interest in using this library and in return contributing to it depends on whether the provided components give something new and universal - the provided value matters, not the marketing. Looking at the current list of components (code, storybook) I don't see anything that wouldn't be available in an established and more universal library.

IMO the only users of this library will be MediaWiki related projects: third-party skins, extensions, gadgets that want to follow the same style. I wonder how many contributors can be expected from that segment. Enough, so GitHub hosting would have visible benefits? Unfortunately I have no information about that.

Mirroring or having the canonical on Github really isn't any different in visibility

In T253364#6157911, @Demian wrote:

In T253364#6157467, @santhosh wrote:

May I request to keep the component library hosted in github? So the contribution path is easy, Project is discoverable and hosted in a familiar place for rest of the world to submit issues, fork and submit pull requests and so on?

I wholly empathize with this sentiment. Gerrit hosting is a deterrent for non-wiki.edians to explore the project and to contribute. This and the development culture are probably both reasons for why there's almost no open-source community around MediaWiki.

{{cn}}

Not taking a position in favour of any of options (especially I am not a developer working on this component so I don't even consider having a say here), just sharing something we have learned at WMDE some time ago.

One possible aspect to consider in this context is that Github web UI is arguably more user-friendly/easy to use for the non-developer crowd. This might be relevant here if more-frequent-than-occasional involvement of UX/Design people is intended/predicted/etc.

In one of the first Vue projects at WMDE we had a privilege to have our UX/Design colleague work closely with developers. As long as the codebase was on Github, she was able (via website UI) to e.g. upload assets (SVG files) herself, without redundant relay over developers (e.g. sending asset files via email, requesting particular CSS changes in the conversation etc). This stopped to be a case when the code base was moved to Gerrit, as it is UI was not simple/rich enough to allow submitting changes without using git. I am not be able to provide peer-reviewed research results on this, but from the little data sample we've gathered at WMDE, UX/Design colleagues are eager to be involved in, or at least try out, collaboration with developers on Github, whereas it has been significantly less susccessful when Gerrit is the primary code location.

In T253364#6157467, @santhosh wrote:

May I request to keep the component library hosted in github? So the contribution path is easy, Project is discoverable and hosted in a familiar place for rest of the world to submit issues, fork and submit pull requests and so on?

I disagree, first of all, having repo in github doesn't mean easy contribution and it's not correct to assume everyone in github provide easy contribution path:

• here's an example: In Oracle, You need to sign OCA: https://www.oracle.com/technetwork/community/oca-486395.html by downloading it, physically print it (who has printer nowdays?), fill the form, scan it and email it, once it's approved then you can contribute
• Google automatically rejects your PR if you haven't signed their CLA yet: https://github.com/google/flax/pull/275

I think using gerrit is much easier than physically printing a form, scan it, email it and waiting until it gets approved by someone in Oracle. Also, Chromium uses gerrit too and it still has tons of volunteer developers.

The other reason is the connection with the whole technical development infrastructure. I'm currently using github in my project while the issues are being tracked in phabricator. I need to manually connect these two all the time while using gerrit, everything is handled automatically. Not to mention connection of github issues with phabricator, etc.

The third reason for me is security, it's not that gerrit is more secure than github or the other way around but having everything in one place under one account, reduces the attack vector, there's a double chance if either github or gerrit accounts have an account with bad password, no 2fa, etc.

Also I want to say as a person who constantly jumps between gerrit and github, gerrit is not harder, it's just people don't know it. I quite dislike the "Squash and Merge" system of commits in a pull request in Github, instead of that, you can amend a commit over and over again and lose every note and change in between. Gerrit has much better UX (while having ugly UI)

In T253364#6164838, @Ladsgroup wrote:

I think using gerrit is much easier than physically printing a form, scan it, email it and waiting until it gets approved by someone in Oracle.

It's the owner's choice how and whether to sign a contributor agreement. Not having to sign a contributor agreement (as done in MediaWiki) is a choice independent from the hosting solution. How is Oracle's flawed (outdated) signing procedure relevant?

Deploying to production requires hosting on gerrit. There are myriad gerrit-specific workflows used for production. Multiple canonical code hosts causes confusion for folks thinking about security, integration, CI, deployments, etc. Mirroring code to github is totally possible to keep a presence there.

In T253364#6166758, @thcipriani wrote:

Deploying to production requires hosting on gerrit. There are myriad gerrit-specific workflows used for production.

Good point.
Vue requires a build step, which AFAIK is not yet ready in CI: T199004: RFC: Add a frontend build step to skins/extensions to our deploy process
I'd consider doing development in one repo and committing the built library into another. Development being done in GitHub, actions build and commit to gerrit and the usual CI pipeline takes over from there.
I haven't gone into the depth to evaluate the feasibility of this approach, but conceptually I find it possible.

In T253364#6166758, @thcipriani wrote:

Deploying to production requires hosting on gerrit. There are myriad gerrit-specific workflows used for production. Multiple canonical code hosts causes confusion for folks thinking about security, integration, CI, deployments, etc. Mirroring code to github is totally possible to keep a presence there.

This is only about the frontend library - not mediawiki specific code that need our gerrit workflow. As we know, WMF developed many opensource libraries in github as primary repo and used its CI. These libraries then published to packagist or npm. The frontend library is one such libray and hence my proposal.

Also, apologies if my comment was interpreted as moving Vuejs based search developement to github. I only meant the UI library that will eventually power vuejs based search and other components. More specifically keeping https://github.com/wikimedia/mw-vue-components at github.

In T253364#6168833, @santhosh wrote:

In T253364#6166758, @thcipriani wrote:

Deploying to production requires hosting on gerrit. There are myriad gerrit-specific workflows used for production. Multiple canonical code hosts causes confusion for folks thinking about security, integration, CI, deployments, etc. Mirroring code to github is totally possible to keep a presence there.

This is only about the frontend library - not mediawiki specific code that need our gerrit workflow. As we know, WMF developed many opensource libraries in github as primary repo and used its CI. These libraries then published to packagist or npm. The frontend library is one such libray and hence my proposal.

Also, apologies if my comment was interpreted as moving Vuejs based search developement to github. I only meant the UI library that will eventually power vuejs based search and other components. More specifically keeping https://github.com/wikimedia/mw-vue-components at github.

ah, no worries, I misunderstood :)

It is true that there are many repos developed in github -- at least to some degree; however, everything that is in production is still (nominally at least) reviewed in gerrit by a human -- even if (in reality) it's generated code where only egregious errors are spotted easily. Maybe only sha1 hashes are checked in some cases. In any event: deploying code anywhere in the stack that is developed in github to gerrit requires human effort (often by the folks who are overwhelmed handling all the other strange edge-cases) that it would be nice to minimize.

My hope is that by moving this project into gerrit we can eliminate some toil.

I wanted to note here that @nnikkhoui will be working on this task specifically to enable PipelineLib and CI infrastructure integration. It's been great to see strong engagement from multiple folks and read different perspectives on how to enable practical and welcoming contribution paths. This is a critical concern but there's as yet no consensus on approach as far as I can see so I kindly ask that champions for those efforts open new tickets to focus those discussions. I will be very interested to participate in them as well!

Is there a particular directory anyone thinks the repo should live under in gerrit? or should this be a top-level repo just named wvui?

@nnikkhoui Exactly second one, top-level repo named wvui. Thanks.

thanks for clarifying @Volker_E !