Forum categories
I fully agree with Tom except on two notes. First of all, I don't think there's a need for a "documentation wiki" link under the "Other Glest-based engines" category. Where would we point that? The Mandate engine is not documented on the wiki at all, and feels unbalanced to have a link to just one of the engines' documentation. If either of those boards want to link to their documentation, they can do so from their own respective boards. I would, however, keep the link in the mods board, but name it "Documentation on the wiki". If we do this before we create our own wiki, we should point this at
Modifying Glest, but later we should rename the page to "Modifying MegaGlest" and improve it.
Anyway, the second thing I'd change from Tom's example is what Ishmaru suggested. I think we should combine the mods and maps, tilesets, and scenarios board. The latter is rather low volume, anyway, and they're all really mods. It also would alleviate the need to come up with a good name for what's currently the mods board. Do we call it "Factions and Modeling"? Or "Factions, techtrees, and modeling"? I prefer "mods".
TL;DR: No wiki link in the "other engines" category and combine the mods board with the maps/tilesets/scenarios board.Annex
I love the Annex mod. It's probably the best MegaGlest mod there is. However, I have to be honest, I don't think it needs a new board. First of all, we should be aware that more boards is a bad thing. It may seem like we're being more specific, but in most cases, more boards hurts a forum and is often cited as the number one forum administration mistake. In summation, the issue is mostly that more boards divides up posts and makes the various boards less active, which contributes to a chain reaction where people hesitate to post in inactive boards because they don't expect their post to be seen. Heck, I'd love to try some cool conversations in our off topic board, but it's not active enough.
But anyway, let's disregard that for now, how active is Annex? It's probably one of the most active MegaGlest mods, but at the time of writing, I don't think I'd call it active. The last post was (at the time of writing) four days ago. That's fair enough, but the post prior to that is dated 19 January, which was 70 days ago! That's a cluster of about five posts around a one day period. Rewind another eight or nine days (over a week) and we get another two posts. And that's it for this year. We're 88 days into 2013 and the Annex project has only had nine posts. Active? Ha! It's a great mod and more active than other mods, but what on earth would it do with its own board? What do we need a new board for that can't already be done in the Annex thread? Or even another thread on the mods board (which isn't that busy anyway). Heck, projects like Dark Magic or the (possibly doomed) MegaPack refit have had multiple threads and did fine.
I suppose we could say that Annex runs standalone, which makes it different, but if you ask me, it's also a mod, and even if we consider it special, I don't see any benefit in separating it into its own board. It wouldn't even necessarily have more downloads, as people would come for MegaGlest mods and not notice Annex in its own board. We recently gave the Mandate engine its own board, which was largely because it didn't fit anywhere else, but Annex still fits as a mod, in my opinion. So I have to ask, what's the reason to give Annex its own board?
TL;DR: I do not believe Annex needs its own board.Back to forum categories
So in summation, I'd cut out the "documentation wiki" link under the "Other Glest-based engines" category, lose the Annex subforum, and combine the existing mods and maps/tilesets/scenarios boards under the name "mods".
Thus, I'm proposing our new layout be:
- MegaGlest general
- FAQ and wiki
- Announcements
- General discussion
- Feature requests
- Bug reports
- Mods
- Documentation on the wiki
- Mods
- Tools
- Other Glest-based engines
- Glest Advanced Engine
- Feature requests
- Bug reports
- Mandage Engine
- Off topic
- Archives
- Vanilla Glest
- Multiplayer
- Linux and other ports
- Bug report
- Translations
But given the inactive state of GAE, I'd set the childboards to read only. That can be easily reverted if anyone revitalizes the project. If we decide so in the future, I'd also drop the GAE board into the archives. It's pretty much dead as it is. But that's a discussion for another day, I guess.
TL;DR: This list is what I think our boards should look like.Wiki
We previously touched the idea of moving the wiki in the IRC. Given the non permanent state of IRC, I'd like to rediscuss the idea here. The wiki is bad. Well, it's alright, but Wikia is bad. They had their good days, but for the last two years or so, they've been pulling an EA, slapping wikis with insane advertising and reaping record profit off it. I know quite a few wikis that moved off Wikia and even more that at least considered the idea. Moving away from Wikia is hard because of their very good SEO. Thankfully, the Glest wiki gets most of its visitors through direct links, presumably the (Mega)Glest forum and related sites, so I think a move from Wikia would not have any major hurdles. Volume is relatively low, too (less than the forums), so it shouldn't be an issue hosting-wise.
Anyway, I'd thus like us to set up a
MediaWiki based wiki on megaglest.org. I emphasise MediaWiki for a few reasons. First of all, I consider it superior to most of the other formats. Easier to learn than bare HTML, but can still use many HTML tags, secure, fast, and scales well. There's a reason it's used by the world's largest free encyclopedia (yes, Wikipedia). Of course, that also means that Wikipedia's help pages are completely valid for our wiki, and editors with experience with the various WikiMedia sites can easily hop in. Finally, we can export the entirety of the Wikia site into an XML file that can be imported into any MediaWiki wiki. Thus, easy conversion. The images can be moved via the
ImportImages script.
Granted, that would just move the wiki as it is. Some of the pages, such as the page on the G3D format or on Blender are all fine and dandy, but we'd probably want to change the existing pages to put MegaGlest at the center of attention. Bearing in mind I'd rather we move the wiki before we attempt any editing.
Most of the MegaGlest data on the wiki is actually pretty good. The only problem is that it's mixed up with GAE and Vanilla Glest stuff. What I would do is save a copy of the pages that have combinations of engines and make a link on the GAE portion of the wiki (presumably for consistency, we can continue to host a portion with GAE-minded stuff; I wouldn't wish being stuck on the Wikia site to my worst enemy). So basically, GAE gets an old, but valid for it, version of the page. Also easy to extend if the project is revitalized. The original page, on the other hand, will lose the GAE stuff and places that state a feature is MegaGlest only will be reworded to assume that people are using MegaGlest. The first target there is the XML pages. That is, everything linked from
XMLs. Those are important because it's the easiest way to find the XML structure. Nobody really wants to have to look through the forum to try and find what the XML tag for binding animations to the skill progress (
<anim-progress-bound value="true"/>, by the way).
We could then move the pages with the "MG/" prefix outside of that prefix. For example, MG/INI would be moved to simply INI (which already exists, so would be overwritten). This would break some links, but those could be very easily fixed with the AutoWikiBrowser (a basic bot that has powerful interwiki find and replace features; MediaWiki only).
Next, I'd take a look at the main page. Replace the instances of "Glest" with "MegaGlest", refine the links for usability, change the logo, etc. After the main page, there's the pages like
Configuration and
Installing mods which are largely outdated and could use some serious work.
Also noteworthy is that MediaWiki is moddable. Extensions, as they're called, are pretty easy to install. Plop a file into the extensions directory (in whatever folder you install MediaWiki to) and add a single line to a file. Full instructions are
here. Interesting thing about extensions is that while technically unaffiliated with the WikiMedia foundation, sites like Wikipedia use a ton of extensions. Some extensions I'd recommend would include
SpamBlacklist (lets you create list of banned URLs; most importantly, a list already exists, as
WikiMedia already uses this),
ConfirmEdit (which uses either a captcha or simple math problem to prevent spam for the first few edits of a new user or an anonymous user),
MultiUpload (which allows multiple files to be uploaded at once),
CategoryTree (creates a dynamic category tree),
WikiEditor (provides a bar with commonly used functions on the edit page), and
CodeEditor (on JS and CSS pages, the edit page has syntax highlighting, auto indent, etc).
All of these extensions are used on the current wiki under Wikia and Wikipedia. You can actually view a list of the extensions Wikipedia uses
here.
We'd also almost certainly need math formula support, as the wiki currently uses the tag in a few places (such as to show the damage formula). The math tag uses LaTeX for syntax and rendering, so that would have to be installed on the server (but probably already is). We would, however, have to enable formula support as per the instructions
here. The
MobileFrontend extension may be worth taking a look at, but I'm actually not sure what vanilla MediaWiki looks like on mobile... Assuming we're going to be using the default Vector skin (which we could later customize to make it "Glesty"), we'd probably want to toss in the
Vector extension, which would add some improvements.
Finally, I seem to be recalling a mention about restricting page viewing to certain groups of people in the IRC. Noting that wikis are intended to be open and I strongly doubt we have any need whatsoever to restrict viewing of a page (note, it's easy to restrict who can
edit a page!), we could use the
PageRestrictions extension to restrict viewing some pages to some groups. However, I'd hope I'm just remembering something wrong and we have no use for such an extension (on a side note, IRC logging is now enabled).
EDIT: We should also look at
Short URLs. However, a URL of "wiki.megaglest.org/w/Page_title" is much, much nicer than "wiki.megaglest.org/index.php?title=Page_title" in my opinion. They're user friendly, search engine friendly, and easy to type.
This guide would probably be the most useable way to do it for Nginx.
TL;DR: We should install a *MediaWiki* based wiki at the soonest convenience. We would then move the current wiki over and edit it. This wiki should have some extensions installed.
