The Technology of Peace

[Renegade]

Some of you may have noticed a few oddities in Ares and its related technologies in the past few weeks...a bright new message in certain builds of the game, read-only version control, and the bug tracker went down.

These were the heralds of a few of the deepest changes in Ares's development- and community structure so far, a set of changes I will explain today.

Are you unstable?
Our decision to closely guard the testing builds from the public eye has probably been our most criticized; while our reasoning has not changed, it is undeniable that, no matter our good intentions, the community simply refuses to accept the system.
We stand before two choices: Continuing as before, in the hopes that the desire for a new stable release will bring about more testers to finally release Ares as stable as it needs to be, or changing our approach, to see if a new way of doing things will be more successful than the old one.

Looking at these options, an oft-cited quote from our beloved Internets comes to mind:

Insanity: Repeating the same behavior over and over and expecting different results.

To put it bluntly, if the reasonable approach were compatible with the community, it would have worked by now. Instead, we're pretty much a year late with Ares 0.2.

Therefore, we have decided to change our handling of unstable builds.
If you have been playing with r1168 or newer, you will already have noticed a not-so-subtle message in the corner of your screen, clearly marking your version as unstable. Since this message ensures any and all players understand the stability rating of the version they're playing and cannot possibly (credibly) claim to have been confused about what they're dealing with, from now on, we accept the publication and usage of unstable builds by the general community.
We still maintain that both common players as well as normal releases of mods should stick to the stable versions, but if someone decides unstable is good enough for them, so be it.

Henceforth, unstable builds will be propagated both through Launch Base as well as http://ares.strategy-x.com/unstable/.
The latter location is currently in a "bare metal" state and will be upgraded in the future to include information about the branches the downloads belong to.

Neutral grounds
Another obstacle in Ares's community interaction is that people often equate Ares as a product and project with RenegadeProjects, and thus project their personal feelings regarding our quiet community and its members on Ares and its (distinct) community. This is a historically grown association, since we have been hosting Ares and its predecessors ever since DeeZire's moronic moderators tried to kill RockPatch in the womb, but nevertheless untrue and not helpful.
As a reaction, we have been working hard to move all things related to Ares development away from RenProj onto neutral grounds.

Of the many choices available to us, we have settled for LaunchPad and GitHub.
If you are not familiar with LaunchPad, it is a hosting platform for open source projects, offering everything a project needs to manage itself and its code and to interact with its community:

Bug reports
Bug reports will go through Ares's bug tracker at LaunchPad from now on. Compared to our previous software, it is vastly simpler to use for end users and far better documented.

The bug reports of the old bug tracker have been moved and are available as before. If you were monitoring a bug, that subscription has also been transferred.

Feature requests
Feature requests go wherever the hell you want.
LaunchPad has an awesome facility called "Blueprints", which are essentially static linking points for documents hosted elsewhere.
In essence, you can work out the details of your feature wherever you want - a thread at PPM, for example -, and when you're done, you simply register a blueprint for Ares.
If you'd like to move your feature description, to a wiki, for example, you can simply update the target of the blueprint.

That way, we have a static element we can work with in the system, there is a static link for your feature request you can spread (in the likes of https://blueprints.launchpad.net/ares/+s...gs-of-doom), but you can still develop your feature in your own time, in your own crowd, using your own tools.

Feature requests of the old tracker have been moved to the new bug tracker for reasons of simplicity, but using the bug tracker for feature requests is explicitly discouraged. While the old software, as an "issue tracker", was well-equipped to deal with feature requests, the new tracker is narrowly focused on being a bug tracker, and LaunchPad is geared towards Blueprints for feature development.

To underline this point, all imported (and properly filed) feature requests have been converted to blueprints with associated wiki pages. The blueprints are associated with their respective imported bug, so you can both find the original report through the blueprint as well as the blueprint through the report (right-hand side, box "Related Blueprints").

This also means if you're having a hard time finding your feature request through the search, you can go the path of old tracker → new tracker → blueprint.
Though that really shouldn't be necessary. The search is pretty good.

Answers
LaunchPad's "Answers" section is kind of like a forum crossed with an FAQ section. If you want to ask a question about Ares or find the answer to something not in the manual, this will be the place to go.

In addition, frequently asked questions as well as important answers will be available through the FAQ section it provides.

Code & Contribution
Through our move from our local Subversion repository to a git repository on GitHub, contributing to Ares has become a whole lot easier.
Anyone can fork the project, fix an issue or implement a feature and request a pull of the code, or make his own fork available to the community.

Even if you're not a C++-coder, you can do the same to help with the manual, which has been rewritten to be almost code-free. You don't need to be a coder to help with the manual anymore.


Most importantly, however, all of this happens away from RenProj. Unless you specifically want to visit our forums to discuss the finer details of Ares development or use it to start a blueprint, there is no need for you to visit our evil lair innocent little meadow anymore.

The Manual
As mentioned above, there's been some work to the manual, both to make it easier for non-coders to contribute as well as to make it easier to use for modders.
In the future, the authoritative manual will reside at http://ares.strategy-x.com/documentation/. When in doubt, that manual shall be regarded as correct, and if it's incorrect, that's a bug.

The new manual has three major advantages over the previous one:

1. Pages.
   While the original manual was appropriate for Ares 0.1, 0.2 is significantly bigger and the documentation has evolved a lot since then, making the one-page & no pre-links design cumbersome to work with and a pain to load.
   The new manual has one page for each topic, in a clear, hierarchical structure, and all items can be linked to: e.g. http://ares.strategy-x.com/documentation...ced-rubble
   
2. Separation of content and output.
   Apart from individual text markup like text links or boldness, the actual manual content is completely independent from its output, allowing us not only to update the manual's design without touching the content, but also to export the manual into a variety of other formats - depending on the results of future tests, we might, for example, provide a PDF version of the manual with the release packages, instead of the whole hundred-file HTML folder.
   
3. Easy code.
   From now on, manual content is no longer in HTML, but in reStructured Text (reST), making it a lot easier for non-coders to jump in and help. Add to that the fact that all topics are in separate files and that the manual has its own, independent repository, and manual changes are something anyone can do.
   

At this moment, the manual is still in an intermediate state, where the data is converted and imported, but not cleaned up yet. It should be usable, but it hasn't reached its full potential yet.

We will provide a complete guide to editing the manual in the already-mentioned FAQ section soon.

LaunchBase
LaunchBase will be better.
Busy with real life, Marshall was awesome enough to release LaunchBase's source under the General Public License, allowing us to patch LB on our own.
Currently, due to the big, structural changes we made, LaunchBase-Ares interconnection is broken, but we will correct this as soon as we can, and throw in a little tidbit as well.

Ares 0.2
We are still hoping to release Ares 0.2 in the very near future; in order to facilitate the stability testing of the current state, we are providing a number of testing branches that merge different combinations of the remaining feature branches, including one Fat Man branch, which will include all designated 0.2 feature branches merged into trunk (i.e. it will be an unstable version of what Ares 0.2 will be).

This, combined with liberal spreading of those unstable releases, will hopefully generate enough feedback to find the remaining showstoppers and release Ares 0.2.

You can find the "Fat Man" branch binaries here.
You can find the testing criteria for the actual testing branches here, though binaries aren't available for all branches as of the time of posting. These will be generated as code is updated.

Remember: The more you test, the quicker we can release.

Adapting & The Future
We realize that basically changing everything at once can be a tad confusing for the community, but we are confident that LaunchPad's facilities are easy enough for everyone to adapt quickly.

Through these changes, basically everything a normal player or modder needs is concentrated under https://launchpad.net/ares - downloads of the stable version, bug reporting, feature requesting and questions & answers. Once the current form of the manual is uploaded with the 0.2 package, a user of the stable version generally shouldn't need to visit any page other than Ares at LaunchPad.
All code is concentrated under https://github.com/Ares-Developers, and the last few outliers like bleeding-edge binaries and manual are all children of http://ares.strategy-x.com/.
In other words: Even if you want to use the very latest Ares binaries and documentation, browse all code related to Ares, report bugs, submit feature requests, read important information and discuss implementation intricacies with other Ares users, you still won't need more than three entry points at max.

Out of these three entry points, two are on independent servers managed by large-scale corporations, so even if disaster strikes and STX goes down, code, downloads, bugtracker, blueprints, FAQ and Q&A will all still be available.

Each facility is more feature-rich and easier to use than the one before, improving the user experience dramatically.

All in all, interaction with Ares as a project and with its individual aspects should be better and easier for everyone.

As for the future of the project as a whole, three months of break do help to quiet the mind, so we're not going to make predictions who will work on Ares's code in what capacity after 0.2. We can report, however, that GraionDilach has shown himself quite capable of modifying and releasing Ares on his own, so even after a mass exodus of coders, there should be enough coding prowess left to carry Ares to the next generation of coders.

And ultimately, Ares is open source, and can now be forked with the click of a button. It cannot be killed anyway.

So fear not for the future of Ares, enjoy the unstable builds, and report test results god dammit.



Epilogue
In case you were wondering: The original draft of this post was saved November 6th, 2011, and was always designed to go up after all aspects of it were deemed release-worthy. The fact that it's going up now is related to the fact that the holidays are over and we had time to code, not the recent outbreak of armchair project management on the forums.