User:Jukeboksi/Blog/June2004
30.6.2004
Today I'm going to drink beer, befuddled by the complexity of Consumerium plans and the unsanity of everyday life.
after some beer, on #wikipedia:
here are the basic assumptions i'm relying on: there will be Opinion Wiki where strict syntax will be required to get aggregate information to Publish Wiki, non-neutral-pov is the rule. there will be research wiki where all non-neutral-pov stuff will get axed immediatelly with a kind notice to go mess around in the Opinion Wiki. Publish Wiki will import from Research Wiki pending that someone will bet their own credibility in declaring some information so certain that it needs to be published. also aggregated (via SQL scripts written in a not-yet-decided language) will be used to automatically update the articles in Publish Wiki with the aggregate information from Opinion Wiki with highlights and links to the whole mess of opinions --Juxo 17:53, 30 Jun 2004 (EEST)
25.6.2004
Perhaps I hastily presented this reintroduction of Opinion Wiki in a wrong way indicating that it would have something to do with forming the opinion on what to publish and what not. This is absolutelly not the case, but it is meant to provide a place dedicated to voicing our opinions on things. In all large public wikis this is done on the talk page of the article and all CPOV stuff is quietly moved to that talk page. In the scheme of organising things that has clarified in my head we won't be importing talk-pages though it is constructive to place a link to the talk-page of research wiki if there has been heated discussion on what is NPOV in each case.
- So why is this not just called talk pages in Research Wiki rather than being called "Opinion Wiki"? If you want to use MediaWiki you have to call it what mediawiki calls it. If you want to have namespaces like critique:Research_wiki_page fine, but same concept.
- Because keeping TCE type of stuff in it's own wiki, the Opinion Wiki, enables us to aggregate the information by using much simpler SQL. Queries are run periodically to update the opinion information in Publish Wiki. By implementing the needed collating in SQL we don't need to fork off from MediaWiki, but can just concentrate on improving the Export-import functionality.
- So, because you are not a great programmer, you propose making a bad user interface because it is easier to implement? Why not just recruit better programmers that can implement the right user interface? And in SQL there is no reason not to just have a more sophisticated query to distinguish things with certain tags from those without, i.e. "what goes to the Publish Wiki" etc.
- by "won't be importing talk pages" you mean the Publish Wiki won't have them? Fine. what is the disagreement here? Also don't forget New Troll point of view, when new information shows up, and new trolls to propagate it, the existing editors must assume they know less about that subject than they need to, since it's not been a previous area of expertise. Therefore they must back down in favour of more troll-friendly ways of determining what is so. This won't always be "quiet".
24.6.2004
Today I'm trying to get into OOP in PHP. TimStarling is helping out with my newbieness. And still implementing Export-import in a reasonably advanced manner is one concrete goal right now.
And I'm determined that opinioned edits will have a distinct wiki (Opinion Wiki which will then in time implement TCE functionality. In a discrete wiki this can be done with accessing SQL directly instead of modifying MediaWiki code, which leads to simple design and implementation.
- This is just wrong.
- No, it's not.
- All edits are "opinionated", especially with the subject matter we're going to deal with.
- Trying to move everything YOU think is opinionated elsewhere will just result in the politics as usual.
- There won't be that much moving once we lay out the ground rules of what goes where.
- What would move is necessarily factionally defined, there's no objectivity there.
- The right answer is a method for objective scoring or voting or betting, like answer recommendation for instance. Qualitative argument (talk page style) can be structured as TIPAESA but proliferating wikis is just wrong.
- I disagree.
- Only one decision is being made: whether to publish the research or not. That requires more focus, not more spread out text all over the place.
- It's a difficult question of how to deal with what to publish and what to not without receding to sysop power structure but it is clear to me that the Publish Wiki will draw somehow approved content from Publish Wiki and aggregated opinions from Opinion Wiki ie. Facts from research and opinions on the subjects of research from opionion wiki --Juxo 13:52, 25 Jun 2004 (EEST)
22.6.2004
I'm back and once again I'm the man with the plan. Actually relaxing in the country side I let all irrelevant thoughts of minor Consumerium details drift away and I saw what it was that was bugging me down. The plan as it is won't work because we won't get any reasonable consensus on what goes from Research Wiki to Publish Wiki because it is a matter of Opinion thus I'm going to re-introduce Opinion Wiki to the plan and maybe that way we can negotiate what gets "published".
- That's stupid. Adding new wikis is obviously not the right way to vote or score or bet on things - and some such quantitative approach will ultimately be required to make such publication decisions fairly - see edits, votes and bets. Obviously there is an objective way to turn research into publication, probably by answer recommendation (approval voting on the various answer options) which doesn't even require factions (although it's quite important to allow factionally defined scoring to let you just agree with someone else's view easily).
- Perhaps, discipline all Publish Wiki talk to be in TIPAESA form or something, to make it easy to put forward an issue to be resolved, but don't create a separate wiki for it - that is like cancer. The point of wiki is to concentrate argument, not spread it all around to three different namespaces. One issue is one issue, period, and everything must be easily found based on the one name of the one issue. And only one place to put an argument for or against publishing a particular fact.
I'm off to the country side to relax a bit
18.6.2004
I've been working on CorpKnowPedia and pondering about how Consumerium and CorpKnowPedia interrelate. Like the information they are collecting is just a subset of the information we are intending to gather, but on the other hand it's useful that there exists such a place at this moment where information on corporations can be recorded. I guess we just have to get a really workable import/export scheme working so that both sites can exist. Maybe we will have such a work order that corpknowpedia does big corporations and their interrelations and consumerium does the smaller companies. I don't really know. This is not an easy problem to solve.
15.6.2004
Today I downloaded MediaWiki 1.3.0beta3 and installed it on my iBook to try out the XML-import facility by commenting out the lines that disable the code from running. I have to say that the way it works by asking you to upload a downloaded xml-dump is really inadequate for our future needs.
- Right. The GetWiki way is the correct way: direct to another web address and tranparently mirror the material as is, including all changes, until there is a need to fork just that one page. However there are ideological reasons and Wikimedia corruption reasons why you will not ever get the MediaWiki coders to do that.
- No. The right way is to recruit PHP coders to make an import feature that works for us. I know very little PHP, I can hardly read the SpecialImport.php that contains the code for the Import feature. --Juxo 23:05, 18 Jun 2004 (EEST)
- So just get someone to clone it. It's not rocket surgery!
- What we would need is a myriad of wikis with radiobuttons to choose from which wiki to import and do it live, not manually saving and uploading the file.
- Yes, absolutely. Being able to import from a different wiki per article is ideal. At least a different wiki per namespace!
- Also importing histories failed
- That's unacceptable given GFDL, but GetWiki doesn't do that right either. Also when Wikipedia exports it give you only the last edit comments not the whole list of editors you'd need to do GFDL attribution to the legally required standard.
- Actually whole import thingy failed even though it reported success for uploading files without the history parts.
- Disaster!
- Also what is needed is suffixing the imports so that we could have Article, for imported from Research Wiki to Publish Wiki Article (Wikipedia), for articles imported from Wikipedia, Article (CorpKnowPedia), Article (Disinfopedia) and what have you.
- Yes, you see this issue all the time with redirects from Meta-Wikipedia to Wikipedia, and probably it's also required for Simple English to full English: rather than seeing NO article in Simple, it would make sense to see the Full one. Rather than seeing no article in full where there's one in simple, it would make sense to mirror it.