We have no objections to this from a legal perspective. Unless I am mistaken, this appears to be primarily a technical change to provide users with an option to do so. Thanks, Zhou

I thought the easiest way for Tool Labs tools to expose their source code would have been a "Fork me on Gerrit" ribbon...

So problems with Gerrit are:

1. No self-serve repo creation / forking
2. The UI is... somewhat new user hostile
3. The workflow is optimized for large projects, and is quite painful if you are a one / two person project

Also,

4. Some people just do not care about version control - consider it too much pain for too little gain. They are wrong, of course (:P) but we should accomodate those people in some form too, maybe.

Would this task be a good topic for the Wikimedia-Developer-Summit (2017) ? If so, the deadline to submit new proposals is next Monday, October 31: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/Call_for_participation

In T102081#1404736, @yuvipanda wrote:

So problems with Gerrit are:

1. No self-serve repo creation / forking
2. The UI is... somewhat new user hostile
3. The workflow is optimized for large projects, and is quite painful if you are a one / two person project

I believe with the combination of striker + diffusion, none of these concerns are as applicable. (#2 is partly true due to the split across striker and diffusion but eh).

Is not requiring the usage of git still a requirement for this task?

In T102081#2998382, @Legoktm wrote:

Is not requiring the usage of git still a requirement for this task?

If it is, then I think we would have to close it as WONTFIX honestly. I do still sort of feel that there could be more end-user friendly tools than gerrit/diffusion. An easy way to fork an existing project is still conspicuously missing in our current setup. We may get lucky and get more features that would help here as a by-product of T136264: Evaluate Kubernetes based workflow replacement options for SGE. The PaaS products I have used in the past provided good tools for separating secrets from code which is really the biggest blocker to just setting up something that rsyncs tool code to a place where anyone can browse and copy from it. A "Heroku-like" still would not enforce secret separation, but it would at least provide clear best practices for secret management.

Well the original premise of this task that @yuvipanda created was "A way that does not require using git". @yuvipanda, could you describe what kind of system you were imagining?

All of the things I was thinking of and can think of now seem terrible and seem to enable our current set of terrible practices. I'll leave it to the current stewards of tools to figure out what to do :) I do agree that enforcing a vcs seems best possible option.