Obviously you know of the other solutions as you and I discussed this before, but I really felt that going with something that was "easy" to setup and can easily be extended was the way to go
At one point I may have but I have a very short term memory so I couldn't probably even name more than a few wiki's from memory.
I've always been a fan of the premise of a wiki. I remember when I was newcomer to the doc team I used to follow my list of edits as they went on. I guess it was just something to make me feel good about myself. Right there and in front was essentially a log of all the contributions I had made to the wiki.
For instance, when I was on the Customization Team, I announced that there will be an option for customization authors to create a wiki page for their customizations. That has been planned in this. With the current url structure, it will be easy for us to add other products, extensions, tools, and anything else we care to document
Ah, I remember planning quite extensively something just like this back in the day. I really wanted to allow for mods to have their own wiki page. I can't remember all the details of how I planned to arrange it, but I knew it wouldn't be something too easy to do using SMF. Well I guess you could create a topic for each mod, but indeed I don't think it would work as well as using a Wiki.
As has been said before, if people create or modify pages with changes that we don't agree with, we'll revert them. If people continue to go along that route, they'll be banned. At the start, they'll not be able to make changes to the wiki and probably have some kind of ban from the forum. If you are a problem on one part of the site, we don't want you to continue that behavior elsewhere. I do like your suggestion of some kind of filter though. I will research that and you may see it added in the future.
Oh I get very much the idea upon reverting abusive changes. I was just merely thinking that certain vandalism could be harmful to the community and easily avoidable by default. Stuff like posting pornographic images however might be harder to prevent unless we moderate all image uploads perhaps. I don't know how wikipedia does it, maybe they just rely on speed of light reverts.
A wiki, not just Mediawiki was chosen over SMF because it is the right tool for the job. We could use a wrench to hammer nails, but a hammer would work better for the job. I've selected "user driven education" as our motto for a reason. We, the team, shouldn't be doing all of the work. Especially when there are plenty of willing and capable people to help. I'd like for us to lead the masses and moderate where needed, but we aren't capable of doing it all. I have a vision of having a near autonomous (from the team) website where we here to develop the system which runs the website and ensure that things run smoothly. Other than that, the software can handle most of what happens around here. Especially when it comes to support (support and documentation to me are one in the same).
I understand the philosophy of a wiki and I don't disagree with it. I do think there are some drawbacks however, such as the quality of documentation is much harder to keep at the exceptional level it is expected to be at when maintained by the Doc Team.
Also it is much harder to coordinate big-scale restructuring type changes when the wiki is open for everyone. Before we could just work on a copy install of SMF, tell the team members to not edit the docs in the live environment, and migrate the changes over. Here, it is harder to just close off the live environment if we are planning to make some heavy changes to the way the docs are formatted or organized.
Granted it is probably much less work to reformat the organization on a wiki, with the main changes just being to the Main Page, so that is good.
SMF 1.1 will be supported by the old Online Manual. I plan to convert it to something more static (searching will still be available) and at some point far down the line it will probably be dropped altogether. Future versions of SMF can be done with our current URL structure. Although, I have some other possibilities - looking at how MySQL does their documentation. You'll see on some pages that 1.1 documentation has found its way to the wiki. There are headings separating SMF 1.1 and SMF 2.0.
There is usually going to be a time where it is hard to determine what to do without a clear versioning support included. Think of SMF 2.0 now. It just may be the more commonly installed version of SMF today, but people who choose to stay on the stable product should have the right to complete and quality documentation. I think at some point a clear line has to be drawn. It can't be decided to have some bits of version Y mixed with version Z documentation. People should be able to go to one place, expect one thing, and get what they expect. If I go to the wiki, I want to know if I am looking at 1.1 documentation or 2.0 documentation, or both at the same time, or I have the choice between which one.
All I am trying to say is you need to decide on what exactly the wiki is. And that is up to you, I am not trying to get in your way. Will the wiki be generic or not? If it is suppose to be for SMF 2.0, it should be stated to make it obvious.
Also, I haven't checked to see if you guys are doing so, but make sure that that now that the documentation is open, that essentially all documentation discussion is open as well. Make use of the Talk pages! Doc Team is now more the moderators of the documentation and is no more a contributor necessarily than any other contributor. If the majority of the community advocates something, be sure not to get in the way in letting the community
wreck improve the wiki.
