On Jan 6, 2015, at 2:44 PM, Guido van Rossum <guido@python.org> wrote:

On Tue, Jan 6, 2015 at 11:39 AM, Skip Montanaro <skip.montanaro@gmail.com> wrote:


On Tue, Jan 6, 2015 at 1:31 PM, Guido van Rossum <guido@python.org> wrote:
it is how to deal with the entire wiki gradually getting out of date due to page "owners" losing interest or topics becoming irrelevant.

Even if you can recruit lots of gardeners, you need a few master gardeners to lay things out (define the structure of the garden). Otherwise you wind up with just a bag of pages. Pushing the gardening metaphor to its limit: no planning means the lettuce is always shaded by the corn.

Nice one, and agreed. I don't see anyone with a serious wish to be a master gardener for wiki.python.org in this sense though. :-( Perhaps we should advertise the position? It's a volunteer role, but will require a lot of motivation. Ideally the master gardener team should be allowed to select the tool suite and be given permission to switch to a new suite pretty aggressively. The team should also be responsible for deciding on the policy for edit access. This seems more workable than having an open-ended discussion on python-ideas.

I have very little opinion on what the wiki is or does but I wanted to just say if at some point we do switch software then with my infrastructure team hat on I would ask for two properties to exist in the software (not really specific to the wiki tbh):

1. Configuration that is able to be handled via config management like salt/chef/puppet etc. Typically this just means that the configuration is handled via a text file and the software itself doesn’t attempt to write to the configuration as part of it’s normal execution.

2. State does not need to be stored on the local file system and instead can be stored in something like a database (preferably PostgreSQL) or an object store (preferably cloudfiles). This allows us to treat the servers running the software as emphereal with all of the state stored elsewhere. This makes it easier to manage the servers, makes it easier to recover from security issues on a server, makes it easier to upgrade the server, and makes it easier to scale the service in general.

Of the two, the first property is the most important, but the second one is a really good idea too.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA