Change Details

Wiki creation is quite an involved process, [[https://wikitech.wikimedia.org/wiki/Add_a_wiki|documented on wikitech]]. I think, at least for certain common cases, the task could be almost completely automated. For uncomplicated creation of new language editions under existing projects, with default configuration, the following tasks need to be done, none of which require complex human decision-making: * Reconfigure many services by pushing configuration changes to Gerrit, and deploy those commits ** mediawiki-config: wikiversions, *.dblist ** WikimediaMessages ** DNS ** RESTBase ** Parsoid ** Analytics refinery ** cxserver ** Labs dnsrecursor * Run addWiki.php. This script aims to automate all tasks which can be executed with the privileges of a MW maintenance script. * Run Wikidata's populateSitesTable.php. It should probably be incorporated into addWiki.php. * Run labsdb maintain-views * Update wikistats labs So at a minimum, you need to write and deploy commits to 8 different projects, run three scripts, and manually insert some rows into a DB in a labs instance. Despite there being no human decision making in this process, the documentation requires that you involve people from approximately four different teams (services, ops, wikidata, analytics). In my opinion, something is going wrong here in terms of development policy. The problem is getting progressively worse. In July 2004, I fully automated wiki creation and provided a web interface allowing people to create wikis. Now, it is unthinkable. Obviously services are the main culprits. Is it possible for in-house services to follow pybal's example, by polling a central HTTP configuration service for their wiki lists? As with pybal, the service could just be a collection of static files on a webserver. Even MediaWiki could profitably use such a central service for its dblists, with APC caching. So let's suppose we could get the procedure down to: # Commit/review/deploy the DNS update # Commit/review/deploy a configuration change to the new central config service. # Run addWiki.php Labs instances needing to know about the change would either poll the config service, or be notified by addWiki.php. WikimediaMessages could be updated in advance via translatewiki.net. (Thanks to Milos Rancic for raising this issue with me.)

Wiki creation is quite an involved process, [[https://wikitech.wikimedia.org/wiki/Add_a_wiki|documented on wikitech]]. I think, at least for certain common cases, the task could be almost completely automated. For uncomplicated creation of new language editions under existing projects, with default configuration, the following tasks need to be done, none of which require complex human decision-making: * Reconfigure many services by pushing configuration changes to Gerrit, and deploy those commits ** mediawiki-config: wikiversions, *.dblist ** WikimediaMessages ** DNS ** RESTBase ** Parsoid ** Analytics refinery ** cxserver ** Labs dnsrecursor * Run addWiki.php. This script aims to automate all tasks which can be executed with the privileges of a MW maintenance script. * Run Wikidata's populateSitesTable.php. It should probably be incorporated into addWiki.php. * Run labsdb maintain-views * Update wikistats labs So at a minimum, you need to write and deploy commits to 8 different projects, run three scripts, and manually insert some rows into a DB in a labs instance. Despite there being no human decision making in this process, the documentation requires that you involve people from approximately four different teams (services, ops, wikidata, analytics). In my opinion, something is going wrong here in terms of development policy. The problem is getting progressively worse. In July 2004, I fully automated wiki creation and provided a web interface allowing people to create wikis. Now, it is unthinkable. Obviously services are the main culprits. Is it possible for in-house services to follow pybal's example, by polling a central HTTP configuration service for their wiki lists? As with pybal, the service could just be ~~a collection of static files on a webserver~~ etcd. Even MediaWiki could profitably use such a central service for its dblists, with APC caching. So let's suppose we could get the procedure down to: # Commit/review/deploy the DNS update # Commit/review/deploy a configuration change to the new central config service. # Run addWiki.php Labs instances needing to know about the change would either poll the config service, or be notified by addWiki.php. WikimediaMessages could be updated in advance via translatewiki.net. (Thanks to Milos Rancic for raising this issue with me.)

Wiki creation is quite an involved process, [[https://wikitech.wikimedia.org/wiki/Add_a_wiki|documented on wikitech]]. I think, at least for certain common cases, the task could be almost completely automated. For uncomplicated creation of new language editions under existing projects, with default configuration, the following tasks need to be done, none of which require complex human decision-making: * Reconfigure many services by pushing configuration changes to Gerrit, and deploy those commits ** mediawiki-config: wikiversions, *.dblist ** WikimediaMessages ** DNS ** RESTBase ** Parsoid ** Analytics refinery ** cxserver ** Labs dnsrecursor * Run addWiki.php. This script aims to automate all tasks which can be executed with the privileges of a MW maintenance script. * Run Wikidata's populateSitesTable.php. It should probably be incorporated into addWiki.php. * Run labsdb maintain-views * Update wikistats labs So at a minimum, you need to write and deploy commits to 8 different projects, run three scripts, and manually insert some rows into a DB in a labs instance. Despite there being no human decision making in this process, the documentation requires that you involve people from approximately four different teams (services, ops, wikidata, analytics). In my opinion, something is going wrong here in terms of development policy. The problem is getting progressively worse. In July 2004, I fully automated wiki creation and provided a web interface allowing people to create wikis. Now, it is unthinkable. Obviously services are the main culprits. Is it possible for in-house services to follow pybal's example, by polling a central HTTP configuration service for their wiki lists? As with pybal, the service could just be ~~a collection of static files on a webserver~~ etcd. Even MediaWiki could profitably use such a central service for its dblists, with APC caching. So let's suppose we could get the procedure down to: # Commit/review/deploy the DNS update # Commit/review/deploy a configuration change to the new central config service. # Run addWiki.php Labs instances needing to know about the change would either poll the config service, or be notified by addWiki.php. WikimediaMessages could be updated in advance via translatewiki.net. (Thanks to Milos Rancic for raising this issue with me.)