We want to experiment with a more official workflow for landing GitHub pull requests directly into the Firefox repo. Per discussion with Coop, enabling this for contributing to the in-tree Sphinx docs makes a lot of sense: * It is a new "product" and few are adversely impacted from GitHub integration not working * Docs are easy to contribute to and therefore there's probably a significant audience willing to contribute to them * With MDN de-emphasizing non-web docs, more docs will likely move in-tree and losing the ease of updating docs via your browser is annoying. GitHub's web-based editing can recover some of that lost convenient workflow. * Changes to just .rst files can skip all Firefox CI except docs tasks * Docs aren't too simple (files from all over the repo) and will represent a more complicated scenario that we'll need to support for GitHub integration Tentative plan: * Export a subset of mozilla-central to a Git repo and publish on GitHub * Listen for pull requests against GitHub repo and kick off TaskCluster CI via Firefox's TaskCluster credentials (this likely involves "integrating" the PR into Mercurial and pushing to Try) * Ability to "land" a GitHub PR into the autoland repo. Open issues: * What to publish to Git[Hub]. If we limit to RST, we don't have to worry about changes to .py and .js files, which we don't want reviewed outside of Firefox's standard workflow. * Where to conduct code review and how to flag people. I think we should focus on "GitHub first." But not all modules may want their docs reviewed on GitHub. Perhaps we need a list of which docs to export to GitHub and are suitable for change there. But if we convert PR to Bugzilla/Phabricator and do review there, this problem may go away (although it introduces other problems like syncing). * How to trigger landing. Probably going to go with the Bors model where a GitHub comment by a trusted individual can initiate. Then Autoland or some other VCS "Sync" service can come along and do its thing.