Talk:MediaWiki modifications: Difference between revisions

    From Consumerium development wiki R&D Wiki
    (true, TikiWiki has some advantages and out-of-the-box features that we need)
    (can't trust MediaWiki developers with a real management problem)
    Line 3: Line 3:
    :I'm looking into it. The new version 1.8 or Polaris seems much more responsive then the 1.4 and 1.5 i fooled around with when trying to locate a CMS to do this concept development & research stuff.  
    :I'm looking into it. The new version 1.8 or Polaris seems much more responsive then the 1.4 and 1.5 i fooled around with when trying to locate a CMS to do this concept development & research stuff.  
    *It does do valid XHTML which is an advantage over
    *It does do valid XHTML which is an advantage over
    ::Yes a huge edge.  And it will likely do XForms long before other wikis, for this reason.  XML integration is important.  Microsoft Internet Explorer is so integrated with XML now, that we can just require that people use it if they want to work on opinion/content, and that will cut the coding very drastically.
    *The linkage visualization (map) thing seems very interesting
    *The linkage visualization (map) thing seems very interesting
    *It does have group management already, but according to my knowledge adding this to MediaWiki isn't a problem at all.
    *It does have group management already, but according to my knowledge adding this to MediaWiki isn't a problem at all.
    ::No, that's wrong.  Look at the MediaWiki user base - mostly at Wikipedia.  These people do group management very very badly, they have very serious governance problems, there are always troll fights and "regime change" discussions and flame wars, and "pogroms" and "witchhunts" and "purges".  They just don't know what they're doing, and on MeatballWiki and such you can find people complaining about how stupid the MediaWiki people are about how to do real world group management.  People who organize their own favourite project so stupidly can't be trusted to figure out what "requirements" exist for the software!  This is a very good reason to get away from MediaWiki and not to trust the people working on it.


    :more on this debate MediWiki vs. Other Wiki Implementations later on. Maybe we should commit an article to this issue.[[User:Juxo|Juxo]]
    :more on this debate MediWiki vs. Other Wiki Implementations later on. Maybe we should commit an article to this issue.[[User:Juxo|Juxo]]
    ::Yes, but keep in mind that much more than just "a wiki implementation" is required.  There's a need for signed and authenticated articles probably, and, maybe even payments processing for donations, or (as I claim) for "betting".


    [[MoinMoinWiki]] is even more extensible with a GREAT parser and extension system.
    [[MoinMoinWiki]] is even more extensible with a GREAT parser and extension system.
    ::This really should be looked at.  It's Python, but why not copy the exact architecture of it into PHP or Java, and integrate it into tikiwiki or etc?

    Revision as of 20:39, 6 November 2003

    Given that the features you want are mostly in tikiwiki, why not just use that? It would be easier to support a common wikitext standard in that more supported software, than try to make mediawiki do what it doesn't do well.

    I'm looking into it. The new version 1.8 or Polaris seems much more responsive then the 1.4 and 1.5 i fooled around with when trying to locate a CMS to do this concept development & research stuff.
    • It does do valid XHTML which is an advantage over
    Yes a huge edge. And it will likely do XForms long before other wikis, for this reason. XML integration is important. Microsoft Internet Explorer is so integrated with XML now, that we can just require that people use it if they want to work on opinion/content, and that will cut the coding very drastically.
    • The linkage visualization (map) thing seems very interesting
    • It does have group management already, but according to my knowledge adding this to MediaWiki isn't a problem at all.
    No, that's wrong. Look at the MediaWiki user base - mostly at Wikipedia. These people do group management very very badly, they have very serious governance problems, there are always troll fights and "regime change" discussions and flame wars, and "pogroms" and "witchhunts" and "purges". They just don't know what they're doing, and on MeatballWiki and such you can find people complaining about how stupid the MediaWiki people are about how to do real world group management. People who organize their own favourite project so stupidly can't be trusted to figure out what "requirements" exist for the software! This is a very good reason to get away from MediaWiki and not to trust the people working on it.
    more on this debate MediWiki vs. Other Wiki Implementations later on. Maybe we should commit an article to this issue.Juxo
    Yes, but keep in mind that much more than just "a wiki implementation" is required. There's a need for signed and authenticated articles probably, and, maybe even payments processing for donations, or (as I claim) for "betting".

    MoinMoinWiki is even more extensible with a GREAT parser and extension system.

    This really should be looked at. It's Python, but why not copy the exact architecture of it into PHP or Java, and integrate it into tikiwiki or etc?