Jump to navigation Jump to search
One or Two wikis?
Suppose two wikis, I'll call them Opinion Wiki and Content Wiki as working titles.
This has advantages:
- Better scalability
- Better security (HTTPS?) for Content Wiki without performance losses in Opinion Wiki
- Differentiated sysop power structure to deal with things that directly alter the Consumerium buying signal (content) versus not.
- Use of one to experiment for the others
- What else is there?
and disadvantages which would apply only if mediawiki were used:
- Distinct Recent Changes (could be hacked to show both in one view)
- Double login (can maybe be avoided by sharing the session, or using jabber id)
- Checking link correctness is more work (could be hacked too)
- Differentiated sysop power structure easier to subvert by usurpers unless care is taken
- What else is there?
I hear that OpenFacts have done something like session sharing with multiple wikis with MediaWiki. Must inquire them about their solution and experiences
For what I've been able to think lately maybe merging Content Wiki and Opinion Wiki into just one wiki could prove most workable. Since almost all article types have been defined already and will use a pseudo namespace or a real one if we hack it to support more true namespaces.
- What about Signal:Exxon versus Research:Exxon? Something has to be debated as research before it is accepted as reliable enough for the Consumerium buying signal to be affected? Ditch the words "content" and "opinion", they mean nothing.
- You're confusing design issues with wiki code issues. Don't bend design around mediawiki, it's garbage and will never work on the scale or with the reliability required. Other wikis do a much better job of dealing with these problems, and will do better in future, certainly. The tikiwiki people have already dealt with a lot of these issues, and the OneBigWiki people are working on login and changes issues, although they are wrong to think MeatballWiki is going to help, it's not a solution, it's another problem. The MoinMoin people could merge all this easily since they are using common Python facilities.
- Don't lose the two
From Opinion Wiki
- Group - must correspond to a real-world registered entity
- VirtualGroup - must not conflict with names of real-world entities. Consists of Users and Groups and other VirtualGroups
- Campaign - preferably descriptive names, and preferably recognizable to people doing real world campaigns say in NGOs.