Option 3 sounds complicated and gain is unclear to me. What's the advantage of option 2 compared to option 1? Just to be on the Wikimedia umbrella on paper?

In T248708#6008513, @Aklapper wrote:

Option 3 sounds complicated and gain is unclear to me. What's the advantage of option 2 compared to option 1? Just to be on the Wikimedia umbrella on paper?

Options 2 and 3 would at least in theory make it easier to share merge rights more widely. Under the wikimedia org account anyone with org-wide admin rights can add/remove folks with merge rights as we like. Under the wpvipcom org account we have a smaller number of folks with admin rights to do those add/remove changes, but we still have control. In practice the difference between option 1 and option 2 may be negligible.

There would still be a more restrictive "deploy" step of merging to the master branch of https://github.com/wpcomvip/wikimedia-techblog needed in any of the 3 options to actually get code changes running on the production blog. This is something we could automate if it turns out to be a bottleneck.

Option 2 is where I'm leaning for the initial workflow. We can always revisit these decisions as needed within reason.

Is option 1 the only option that won't require some additional code that glues the moving parts together? That is, is a merge into master of the origin repo a deployment without any additional glue needed?

I don't see the public members of the wpcomvip project -- is it correct that with option 1 there will be folks outside the wikimedia org account who can add/remove folks?

Is there some restriction on the number of admins for option 1?

The advantage of option 3 is that is allows Wikimedia developers who necessarily have a gerrit to not have to have a github. In reality that's probably a very small number of folks. I also don't see a reason to enforce a gerrit workflow since this all runs outside of production.

Option 2 and 3, to me, seem to give the most control, but there's probably a similar amount of fiddling needed to get each of those options working well.

In T248708#6012833, @thcipriani wrote:

Is option 1 the only option that won't require some additional code that glues the moving parts together? That is, is a merge into master of the origin repo a deployment without any additional glue needed?

Yes. The merge to master of https://github.com/wpcomvip/wikimedia-techblog is the trigger for whatever push to deploy magic Auttomatic has running on the backend.

I don't see the public members of the wpcomvip project -- is it correct that with option 1 there will be folks outside the wikimedia org account who can add/remove folks?

Yes, the account management team at WPVIP "own" that org and have org level owner rights to add/remove folks from the repo. Today the Foundation members on that repo are myself, @Reedy, and @srodlund. I would be happy to add more folks as needed to increase the bus lottery factor.

Is there some restriction on the number of admins for option 1?

Nope.

The advantage of option 3 is that is allows Wikimedia developers who necessarily have a gerrit to not have to have a github. In reality that's probably a very small number of folks. I also don't see a reason to enforce a gerrit workflow since this all runs outside of production.

Option 2 and 3, to me, seem to give the most control, but there's probably a similar amount of fiddling needed to get each of those options working well.

I think a reasonable first iteration of 2 would be to make the PR upstream to the "real" master repo a manual deployment process. We could invest in automation, but only if it turns out that the steps are performed often enough to justify the investment in tooling (https://xkcd.com/1205/).