This is the place to discuss the Wiki contents, forum issues, themes and to propose site-related features and ideas.
- Site Admin
- Posts: 1193
- Joined: 05 Aug 2011, 22:21
- Location: Wroclaw, Poland
You may have noticed, that I did some improvements to the wiki recently (some main page clean up and some more documentation). But ultimately this is too much for a one person job.
While OpenMW has grown, the wiki kinda didn't keep up with it. As I see it, we need improvements to the developer documentation, the end user documentation, the layout and the organisation.
I have sat up a wiki project in the tracker already and if there is sufficient interest and manpower, I could start to add more tasks to it.
We would need people with the following skills:
- Wiki syntax: General organisation and probably some more fancy layout elements
- Graphics design: we still need a logo
- Limited understanding of the OpenMW code base: I will continue to provide additional technical documentation as much as my time permits it. Some of it may happen on the forum (see the cfg thread for example) and will need wikifying eventually. There probably will be other tasks too.
- Good English skills: while I am fairly confident in my English skills, it is not my first language. It might be a good idea to have a native speaker go over the wiki and make minor improvements (spelling and some phrasing, maybe).
I only help out around release time, so I would be happy to help improve the wiki. Obviously not improving the developers side of the wiki, not my area.
Okay. One volunteer. That is a start. Could you please register on the issue tracker?
Here are my general thoughts about the structure of the wiki:
Everything but the main page falls into one of three categories:
This should provide a high level overview over OpenMW architecture. There were two heroic attempts at this:
http://openmw.org/wiki/index.php?title= ... chitecture
http://openmw.org/wiki/index.php?title= ... _to_OpenMW
But both were doomed to fail. The first one is too limited and focusses too much on what 3rd party components are used. The second one is too detailed (and still partially misses the big picture) and therefore is impossible to keep up to date.
Also both are incomplete and outdated by now.
The problem here is that NIco didn't provide any high-level documentation for his work. And when other people started adding to it (this includes me), we followed his example.
The deficit we ended up with is large enough to be not immediately fixable, so this will be a gradual over time effort.
This category also should contain all additional information, that is not covered by the issue tracker. I suggest we start cleanly with a new page and link all the old stuff under an older documentation section.
This should be the player's manual. Since you need the original game to play MW and all TCs I know of, we can assume that the player has the original manual. We only need to explain what is different from MW.
We don't have anything for this category yet. Once we are past 1.0 instructions about using new features of OpenMW should go here. We also may consider creating a manual for the editor in this category (maybe in a subcategory).
I started to reorganise the wiki. There are a couple of tasks on the issue tracker now (switch to the OpenMW Wiki project). If you see anything you like feel free to assign it to yourself (you need to register on the bugtracker first and throw me a note so I can set you up as developer on the wiki project).
Heroic is an embarrassing, but appropriate way to put it. My guide was to be complete, but considering how much actual work and intimate knowledge (or participation) is required for it (which no one has), means that it isn't realistic to see it finished.
I like the categories. Maybe I'll try to copy all the guide stuff and separate out sections so the right information can be used.
One thing is for sure is that we really can't manage not having an explicit design plan on paper anymore. Making one from the organic project right now might be heroic in itself, but might be worth it to show that we aren't organically developing it, and attract coders who can efficiently spend time on it, but also ensure we can complete all the features we want without being disorganized or hacky.
So - let's make three categories as said, and let's identify what section each needs and then make tasks.