Auto-generated wiki pages

[mcarans]

I will make this last contribution to this debate as I feel I've said more than enough. When you come to some sort of decision, I'll see if I can help out in implementing it.

I would suggest approaching this by considering at least the following 4 use cases. You may be able to think of more.
1. OXP author entering OXP information quickly and easily
2. Newbie trying to find OXPs and work out whether he/she is interested in them or not
3. Experienced user trying to find detailed info on one or more OXPs
4. Editor doing manual maintenance work to keep things up to date (if needed)

The final solution, whatever it is, should at the minimum have OXP name, category and brief description and possibly author to be of any use IMHO.

[Smivs]

Well, as I've said before I think it's pretty good now anyway.
The only bugbear is the updating, and I think we have just got to leave that to the OXP authors. It's the only practical solution, and they are their OXPs after all.
If I have a concern it is that the Min and Max versions columns need a sort out. With few exceptions they all seem to have 1.74.X as the Max, which I'm sure is not right, and there do seem to be an awful lot with 1.74 as the Min which again I doubt.
I've got no idea how this could be sorted out, so any bright ideas?
I think the Max and Min columns are the key to keeping the Wiki current, as it will be easy to spot 'un-tended' OXPs as the Max version would never go up...normally the author of an OXP should up-date their entry/entries with each release. For most people this will be very little work not too often. If this is not done for any particular OXP this would suggest that it is 'un-tended' for want of a better term.
A simple note on the Wiki page could warn readers that an OXP that doesn't comply with the current release may be unreliable.

[Thargoid]

And at the risk of repeating myself, speaking as an OXP author all we really want is something that's simple to enter data into (this one is better than the older one, but still not perfect) but above all somewhere we only have to do it once.

This will now be at least the third table incarnation to be updated, along with the already existing ones too. Updating a table is fine, it's just having to do it in triplicate (or even more so) that gets irritating and puts people off doing it

If I have a concern it is that the Min and Max versions columns need a sort out. With few exceptions they all seem to have 1.74.X as the Max, which I'm sure is not right, and there do seem to be an awful lot with 1.74 as the Min which again I doubt.
I've got no idea how this could be sorted out, so any bright ideas?

Both sound perfectly right to me. An OXP cannot be compatible with 1.75, as 1.75 doesn't exist yet. All that does exist is an ever-changing beta-code which hopefully at some point will become 1.75 (and possibly 1.74.3 and further along the way). But until it's fixed, frozen and released then there can be no guarantees that any OXP will be fully compatible with it.

And any OXP that uses for example mission screens will almost certainly be 1.74.0 and above only. Similarly many OXP writers these days don't bother too much with backward compatibility due to a lot of new features and major changes made lately, plus there aren't so many people using <1.74 these days (a few I know, but not many).

[Smivs]

As usual, Thargoid is right. This is getting far too complicated, but I think it could easily be simplified.
The Tables (catagory) on the main OXP page could be simplified by the removal of the Min version requirement, which is pretty meaningless. Instead of a Max version, there should be an 'Oolite Version' column stating the latest version the OXP is known to work with. This could be the principal version - 1.74.X rather than 1.74.2 or whatever, so authors wouldn't need to update with every bug-fix or minor update/release of Oolite. This would still allow us to pick-up on un-tended OXPs.
The alphabetical list, being just a list, has no information about individual OXPs and won't need manual updating.
Unless I'm missing something, this will allow us to both check easily whether an OXP is up to date, and minimise the work of the authors in keeping the info up to date - only one item would need updating, the 'Oolite Version' on the catagory table page, and then only when a new version of Oolite is released.

[Commander McLane]

As usual, Thargoid is right. This is getting far too complicated, but I think it could easily be simplified.
The Tables (catagory) on the main OXP page could be simplified by the removal of the Min version requirement, which is pretty meaningless.

Why is it meaningless? After all, there are people around who are still using Oolite 1.65 and then asking questions here why this-and-that OXP doesn't work for them.

The alphabetical list, being just a list, has no information about individual OXPs and won't need manual updating.

I'm sorry, but http://wiki.alioth.net/index.php/Catego ... sion_packs isn't a list at all, but a category page—a Wiki tool which helps to organize pages.

The alphabetical list which Thargoid is referring to, and which used to be on the original OXP-page has been split into several pages (first two, currently four), namely:
OXPs 'A' to 'F': http://wiki.alioth.net/index.php/OXPs_% ... to_%27F%27
OXPs 'G' to 'M': http://wiki.alioth.net/index.php/OXPs_% ... to_%27M%27
OXPs 'N' to 'S': http://wiki.alioth.net/index.php/OXPs_% ... to_%27S%27
OXPs 'T' to 'Z': http://wiki.alioth.net/index.php/OXPs_% ... to_%27Z%27

EDIT: corrected typo

[Smivs]

As usual, Thargoid is right. This is getting far too complicated, but I think it could easily be simplified.
The Tables (catagory) on the main OXP page could be simplified by the removal of the Min version requirement, which is pretty meaningless.

Why is it meaningless? After all, there are people around who are still using Oolite 1.65 and then asking questions here why this-and-that OXP doesn't work for them.

Exactly, it might stop some of this. It could easily be made clear on the Wiki OXP page that the OXPs that are shown as working on the current oolite release may not work on earlier versions, and conversely that 'un-maintained' OXPs may not work on the current release. At a stroke, you're encouraging people to use both the current version of Oolite, and the OXPs.

The alphabetical list, being just a list, has no information about individual OXPs and won't need manual updating.

I'm sorry, but http://wiki.alioth.net/index.php/Catego ... sion_packs isn't a list at all, but a category page—a Wiki tool which helps to organize pages.

OK it's a catagory page that takes the form of a list. My point is it doesn't contain information about individual OXPs and therefore doesn't need updating manually. It's auto-generated.

The alphabetical list which Thargoid is referring to, and which used to be on the original OXP-page has been splitted into several pages (first two, currently four), namely:
OXPs 'A' to 'F': http://wiki.alioth.net/index.php/OXPs_% ... to_%27F%27
OXPs 'G' to 'M': http://wiki.alioth.net/index.php/OXPs_% ... to_%27M%27
OXPs 'N' to 'S': http://wiki.alioth.net/index.php/OXPs_% ... to_%27S%27
OXPs 'T' to 'Z': http://wiki.alioth.net/index.php/OXPs_% ... to_%27Z%27

As above. It's an auto-generated list of OXPs. It contains no information about the OXPs, it just lists them, automatically, so again no extra work for authors. My purpose here is not to discredit/criticize these pages at all, I'm concerned with minimising the ammount of effort OXP authors have to put in to keep things up to date.

The whole point I'm trying to make is that, providing we can sort out the 'Oolite Version' on the catagories page, many real benefits will flow, for everyone - OXP seekers, Authors, everyone!
a) visitors can easily find what they are looking for by scanning a logically laid out table with meaningful headings.
b) visitors can immediately see which OXPs work with the current Oolite release, and can be informed that this is the version to be using.
c) authors only have to update this one page, very rarely when a new Oolite version is released. The rest is done automatically.

[Cmdr James]

After all, there are people around who are still using Oolite 1.65 and then asking questions here why this-and-that OXP doesn't work for them.

Yeah, hardly surprising

Version 1.65, released in June 2006, is the latest full release of Oolite.

[Commander McLane]

The alphabetical list which Thargoid is referring to, and which used to be on the original OXP-page has been splitted into several pages (first two, currently four), namely:
OXPs 'A' to 'F': http://wiki.alioth.net/index.php/OXPs_% ... to_%27F%27
OXPs 'G' to 'M': http://wiki.alioth.net/index.php/OXPs_% ... to_%27M%27
OXPs 'N' to 'S': http://wiki.alioth.net/index.php/OXPs_% ... to_%27S%27
OXPs 'T' to 'Z': http://wiki.alioth.net/index.php/OXPs_% ... to_%27Z%27

As above. It's an auto-generated list of OXPs.

What gives you the impression that this over many years painfully handcrafted list (now split into four) is auto-generated? Is the string "Category:" contained somewhere in the four links? No, it isn't.

This alphabetical list, which used to be on the OXP-page before mcarans banned it from there in favour of his new category lists, is for me still the authoritative list of OXPs. The newly introduced categorized lists are merely an alternative way of listing the same stuff all over again.

And this alphabetical list was the only page I ever needed to edit when I released a new OXP. Now, however, I will have to update at least two unrelated lists. First this old, alphabetical one, and then one or more of mcarans' new category lists, depending on whether I think that my new OXP is an enhancement, an expansion, or miscellaneous, or possibly all three. Which means that I end up having to edit not one, but four Wiki pages, in order to place links to my OXP.

Personally I find that things haven't become easier and clearer through the new system, co-existing with the old system, but rather more complicated and more confusing.

[mcarans]

What gives you the impression that this over many years painfully handcrafted list (now split into four) is auto-generated? Is the string "Category:" contained somewhere in the four links? No, it isn't.

This alphabetical list, which used to be on the OXP-page before mcarans banned it from there in favour of his new category lists, is for me still the authoritative list of OXPs. The newly introduced categorized lists are merely an alternative way of listing the same stuff all over again.

And this alphabetical list was the only page I ever needed to edit when I released a new OXP. Now, however, I will have to update at least two unrelated lists. First this old, alphabetical one, and then one or more of mcarans' new category lists, depending on whether I think that my new OXP is an enhancement, an expansion, or miscellaneous, or possibly all three. Which means that I end up having to edit not one, but four Wiki pages, in order to place links to my OXP.

Personally I find that things haven't become easier and clearer through the new system, co-existing with the old system, but rather more complicated and more confusing.

Since my name seems to have been mentioned repeatedly in this post, I presume I'm required to say something.

There used to be two lists - the alphabetic list and the old categories pages. I guess you didn't bother with the latter, but if you had, you would have found that you had to enter your OXP in various places depending on its category. An alphabetic list is only useful if I already know the name of an OXP and if I know that, I probably already know what it does or can find the full website or wiki page about it and don't need to look it up in the alphabetic pages.

I don't think you need a high IQ to work out from the definitions on the wiki if your OXP is an Enhancement, Expansion or Miscellaneous. Within those super-categories, if your OXP spans multiple of the sub-categories, like Mission and Equipment, you can use Combination. In the remote event that your OXP spans Enhancement and Expansion, I would put a single entry in Expansion under Combination. Hence you will never need more than a single short entry.

I agree that this interim stage could be confusing. I resisted the temptation to completely remove the alphabetic list and old categories pages from the OXP page, in case people wanted to reference them, but ultimately they should be hidden or removed, then there will be no confusion.

[Smivs]

Commander McLane, I think we have been talking at cross purposes, with I fear mis-understandings on both sides.
When you talked about the Alphabetical List I thought you meant the Alphabetical List that is linked from the Wiki OXP page, which is auto-generated.
I've just worked out you meant this table which used to be on the OXP page.
You define this table as the definitive list of OXPs and I wouldn't dispute that for a minute. Likewise I wouldn't diminish the work that has gone into it, but this in a way hints at one of the reasons why it might have out-lived its use. For one thing, to insert a new OXP you had to effectively edit every OXP after it to sort out the alternating background colours for each entry. And the list was also getting completely un-wieldy. It was rapidly becoming the longest web-page in history.
As a reference it is still extremely valuable and shouldn't be removed entirely, but as a resource for those looking for OXPs it is, frankly, useless. It's far too long to scan effectively, and being alphabetical rather than catagorical, it was no use if, say, you just wanted a bit of eye-candy.
So we had an un-readably long alphabetical table and an auto-generated catagorical list which had serious shortcomings of its own. These have been discussed at length elsewhere.
What Mcarans has done is create something, that with a small amount of care and effort, could be the start of a better way forward. What he has given us is a (potentially definitive) table of OXPs, arranged into simple catagories for ease of use by both OXP-seekers and OXP authors. It is easy to update as each OXP is listed only once and only needs a small edit (to the version column) each time a new release of Oolite occurs. It also holds more relevant details of the individual OXPs than its predecessor.
In essence it takes all the best points of the various lists and tables that went before and brings them all together in an easy to use and easy to maintain format...all in one place.

[maik]

Uh-oh, this is taking a turn and tone that is rather unwelcome.

Let's lean back for a moment and ponder what we want to achieve. This already was mentioned further up in this thread but allow me to recap and go back to the drawing board:

We want to have
a) a good overview for someone who doesn't spend all his time monitoring the BB to find new OXPs that might tickle his palate or updates to existing ones
b) as few as possible, ideally only one, places for OXP authors or Wiki maintainers to update.
c) an indication if an OXP is (in)compatible with the current version of Oolite.
d) lots of other information about the OXP

I like Svengali's proposal in the Sandbox a lot. It covers points a), b), and c) and partially d).

However, in order to keep the list simple, I would
1) remove the version as we already have the date of the last update. Having this sortable makes it easy to get a list of updates / new OXPs when you come back from vacation or just an extended Oolite break.
2) remove the engine column simply because I don't understand it
3) remove the authors column because they can be named on the OXPs Wiki page and in the OXPs readme file. I do not think that users will frequently want to search for or order by authors. If they find they like the work of a particular author then the Wiki page of the OXP they already know should have links to the author's other work.
4) replace the min and max version with a compatibility flag. IMHO it would be sufficient to have this only for the current major version (1.74) in the form of y/n/? and update this when 1.75 or 1.76 rolls along. All other version information should be on the OXP's Wiki page, e.g. information about different OXPs versions for different Oolite versions.
5) Remove the size column and move the information to the OXP's Wiki page. I think there are only very few users who care about download size so much that they wouldn't even want to visit the OXP's Wiki page to find out if they had known it's too big beforehand.

The list should remain on one page. Authors would need to keep this list updated together with their OXP's Wiki page.

Looking at the alphabetical lists, we would loose the information about which ships and stations are added unless they are included in the brief OXP description. Again, IMHO this information should be provided on the OXP's Wiki page.

Epilogue

I'm happy we are having this discussion now. I think it's also good that people like mcarans go ahead and do stuff instead of just talking about it, although in retrospect it could have been a smoother ride. But after all, the Wiki doesn't loose anything and we can always go back to where we were.

Again, I'm happy to contribute my time to sort this out if everybody is happy with the proposal. Or continue the discussion until we get there

[maik]

...and Smivs beat me to it

[Smivs]

...and Smivs beat me to it

Oops, sorry!
You've made some other good points, though I'm not sure about some of them. Just to go on the record I'm happy to give what time I can to this as well.

[Thargoid]

If we do the proposed table column trimming then most of the reason to go with the new list over the individual alphabetical one is lost, which kinda makes the whole exercise pointless (the sortability by author and version is rather what gives any interest in the update).

Just to clarify something, the original "big" (all in one) alphabetical list linked to by Smivs isn't the one I and McLane were referring to. You are correct that whilst this is detailed it is a complete pain to update and keep looking correct. He and I were both referring to the next evolution from that, which he linked to a few posts back (the one broken down into 4 parts, with each letter having it's own little table).

Most of the gripe here seems to be that suddenly we've got several different tables kicking around and now the workload to keep the wiki fully up to date has gone up by a factor of 3x or so.

Yes the new sortable table is a very good demonstration of what could be done, but as yet it is not a functional table as most of the data is missing from it. Hence it was better on the wikii sandbox where it was originally shown, or should have been sandbox'd on our wiki as suggested above. What is irritating is that it has now been dropped into the main functional wiki page as "the main table" when it is vastly underpopulated with its correct and full data - all of which is available in the previous table.

So my proposal would be that currently things are reverted to how they were, and that the new sortable table is put into a sandbox whilst the author of the table must lead and oversee the population of it with all the currently available data from the existing table. Then and only then should the "swap over" take place, at which point the whole community can then continue to support one single table (the new sortable one), with the other tables depreciated and supported only if the community wishes to (with the explicit note that these tables are old and may not be complete any longer).

It's either that or in trying to improve the wiki in fact the whole thing ends up broken, factionalised, incomplete and essentially useless.

[maik]

If we do the proposed table column trimming then most of the reason to go with the new list over the individual alphabetical one is lost, which kinda makes the whole exercise pointless (the sortability by author and version is rather what gives any interest in the update).

I guess you mean the min/max version of Oolite that is compatible with an OXP and not the OXP version? What would be the use case for sorting by these (from users' or authors' perspective)? Also, what would it be for sorting by author?

So my proposal would be that currently things are reverted to how they were, and that the new sortable table is put into a sandbox whilst the author of the table must lead and oversee the population of it with all the currently available data from the existing table.

I agree.