User:Jukeboksi/Blog/June2004: Difference between revisions

    From Consumerium development wiki R&D Wiki
    (no, all the opinions are, is leaves in a TIPAESA tree structure or something similar)
    No edit summary
    Line 3: Line 3:
    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".
    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.  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 [[faction]]s (although it's quite important to allow [[factionally defined]] scoring to let you just agree with someone else's view easily).
    :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 [[faction]]s (although it's quite important to allow [[factionally defined]] scoring to let you just agree with someone else's view easily).


    :Discipline 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.
    :Discipline 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.

    Revision as of 17:21, 22 June 2004

    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).
    Discipline 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.

    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)
    If you know such people, then just have them copy GetWiki's XML import feature, which is the right design, into a new MediaWiki version that has a license you can live with. Then fight the geeks who hate GetWiki because it breaks Wikimedia's unrighteous monopoly over text they didn't write.
    Can't reintegrate GetWikis leech code into MediaWiki because it's untastefully not licensed under GPL.
    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!
    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.