There's been heavy discussion of the various options surrounding the pages for the Sponge wiki. At the time of writing, the current contenders for implementation are:
- MediaWiki
- DokuWiki
- GitHub Wiki
- GitHub Pages/Jekyll
- A homebrew option
I (prophile) am personally heavily in favour of the GitHub Pages & Jekyll approach, and I hope to cover the major reasons why in this document.
Jekyll is a static site generator. Taking HTML templates and Markdown as input, it produces static site content. The benefits of static site content are manifold: good caching behaviour, small attack surface, fast content serving. Jekyll can be run anywhere (this author uses it on his own server for his website), but GitHub opted for Jekyll for their GitHub Pages service.
GitHub Pages allows one to publish a Jekyll site through GitHub. This brings two major advantages, both of which I will cover later:
- the normal GitHub ecosystem for repositories, including Pull Requests and Issues;
- GitHub's provision of hosting.
GitHub's ecosystem for large open-source projects revolves largely around Pull Requests. In stark contrast to systems in which the unit of access is the user (where some set of people have "commit/push access"), pull requests allow the unit of access to be the individual contribution, removing the politics and focusing on the merits of individual changes while keeping control over what goes into a repository.
This works very well for website contents. It means that any member of the public can submit changes to any part of the website (including even the design), which means that bugs and out-of-date content can be fixed very quickly by anyone who is interested, while maintaining—and perhaps even enhancing—the level of review that one would expect from traditional CMS publishing systems.
In contrast to a wiki, it means that individual contributions are subject to the review process as well, before being made generally available. This guarantees some basic level of authenticity to information published on the website, and provides quality control for wiki contributions, as well as making it more difficult for spam infestations to arise.
Additionally, the normal git mechanisms (which come "for free" under this system) apply—it is possible to work on large-scale website changes in a branch and be able to merge them in one go, with others able to contribute.
As a final note, the Sponge project is (presumably) already using the GitHub ecosystem. If contributions to the main Sponge project are already accepted as GitHub pull requests then following the same procedure for the website and wiki means that they fit seamlessly into the existing workflow and mean less technology to learn as a contributor to the project.
GitHub is a very large company, and their services are generally reliable. The benefit of being able to host content directly via GitHub Pages is then fairly apparent: lower maintenance, increased availability, and reduced server load.
Moving the proverbial ball to GitHub's court means that their server power is behind it, not the Sponge team's. If the server goes down, the website will still remain up and messages will be able to be posted there; even if the server is compromised the front page will not be.
MediaWiki is an extremely complicated piece of software. This is understandable—the Wikimedia Foundation manages the largest public wikis in the world—but it is a major consideration for the Sponge project. Using it entails entirely avoidable maintenance overheads. The software has to be kept up to date since the scale of MediaWiki means the attack surface is inevitably large.
It also needs patrolling to minimise the impact of spam or malicious changes. Wikipedia is policed by an extremely large number of editors on the hunt for spam and a veritable army of utility bots. GitHub Pages projects do not face anything like the same level of maintainance: other than merging pull requests and the usual tasks involved in keeping any website up to date with current information, all the rest of the updates are managed by GitHub themselves.
The Wikimedia Foundation exists to maintain wikis. The group associated with Sponge does not: it exists to replace Bukkit with a Minecraft server API. The less work involved with maintaining peripheral concerns like the wiki, the better.
GitHub repositories have native wiki functionality. There are major projects (libGDX, for example) whose wikis are hosted directly as part of the GitHub repository. While this functionality does exist and is generally usable, it may well not be the best option for the Sponge project.
As a starting point, the style of GitHub wikis is not customisable: it looks like GitHub. It does not integrate into the rest of a website. It also is only a wiki, in the sense that it could not sensibly be used to manage the main website content as well in the same way that GitHub Pages can. Its functionality is rudimentary compared to the full generality of git being available for maintenance or entire-site rollbacks, and it lacks the innate distributed backing-up behaviour of git.
A GitHub wiki would probably be the fastest to set up of any of the options presented, but it is certainly not the best option.
GitHub Pages provide a scalable, simple, curated and low-maintenance system for managing both the website and the wiki within one unit. They fit into the existing ecosystem making it easy for developers, and provide review on all content while still being easy to edit as a result of GitHub's own continuous drive to make it easy to contribute to open source projects.
I commend it to the Sponge team.