> On Mon, Dec 18, 2006 at 06:22:57PM -0500, Andrew K. Bressen wrote:
>> We should have a design that looks as good as the genocide content.
>> And people who know how to maintain the design, and have access to do so.

ahn at orion.netrek.org (Dave Ahn) writes:
> And who would this be?  And who would replace such persons when they
> inevitably move on?

That's my point. Maintaining the HTML/PHP design is a more common
skill than maintaining a wiki design. Keeping those human slots filled
should be easier. 

>> Do we have the sysadmin resources for that when a simple 
>> restore took months?
> I think if it were a simple restore, it wouldn't have taken months.

Not to knock anyone, but if it wasn't a simple restore, then that may
well point to insufficient sysadmin resources. Restores should be
simple. If we can't manage decent backups for an HTML/PHP config,
could we deal with a complicated beast like a database-backed wiki
going toes-up?

>> We'll also need admins to do lockouts and reverts of vandalism. 
> And again, who would this be?

Again, exactly my point. Wikis are more complicated here, and thus
likely more work. 

See, either way we need to issue and revoke accounts/passwords 
for access and be able to roll back vandalized content. But, with 
everything in darcs, we only need to know and administer one
system for doing these tasks. 

With a wiki, we not only need wiki accounts for editors and wiki
editors to do rollbacks, we also still need an infrastructure to deal
with the non-web-accessible wiki design elements as well as any
non-wiki parts of the site; two sets of passwords/accounts and
backout procedures, not one. And if there's a seperate set of
database accounts needed for the wiki, that's a third set (albeit
a small one). 

> I fail to see how using darcs to version control a custom PHP based web
> site is any simpler or easier to maintain than any publicly available
> content management system, whether that is a Wiki, Zope, or some other
> software.  

It's simpler because it is fewer components.
Either way there's an httpd to configure.
Both will need version control, either for the html/php or for
the wiki config stuff. 
But with a wiki, there's also a wiki to configure and its database.

It's easier to maintain because it's fewer software updates,
more common skills,
and fewer admin interfaces.  

>... Ultimately, someone or several people must have shell access
> and a test environment, maintain the software updates, and administrate
> the web site.

And HTML/PHP/darcs needs fewer people with shell access,
  (I suspect pretty much everything could be done with only darcs access)
a far simpler test environment 
  (constantly refreshing a duplicate wiki db is probably not trivial; I could
  put up an entire duplicate HTML/PHP config on my desktop in under an 
far less testing 
  (since the design is already done)
far fewer updates
  (HTML and PHP are mature and stable)
simpler administration using easy backups
  (no database dumps)
fewer parts to administrate
  (no database and no wiki to know how to use and manage)
more commonly available skills
  (HTML and PHP are common; no single wiki or CMS comes close to the
   amount of expertise out there already, and even someone who hasn't
   touched HTML or PHP in five years could just start using them again, 
   while someone five years rusty on a CMS will need to first learn
   everything that's changed about the CMS)

I'll reiterate here that I'm not inherently anti-wiki; I've edited at
least two dozen wikipedia articles. I'm happy we have a dev wiki;
it's the right tool for its job. 

But if the geno content was in darcs, I could have spent the over four
hours I've worked on these posts on editing content. And I would have
done some content editing back in september when I did a wget and a
darcs pull and found I couldn't touch the actual content.

Now, if there was a great looking wiki already set up and ready to go
(and with good backups) I'd be making far less noise; I'd probably
just go shove stuff in there, because it would be shortest path to
having a good site online. But we're not there, and I'll be rather
surprised if we're there six weeks from now. In the meantime, we've
got mac users downloading clients and very limited online info for