| 1 | | There are compelling reasons to support mediawiki format completely in the core trac release. 6. jamwiki is cloning mediawiki in Java and keeping the format identical so Java-based projects can easily integrate a full wiki. 5. drupal_wiki is likewise supporting mediawiki format as its native format 4. mediawiki is very widely used in intranets already including very large ones like the US inteligence services' "Intellipedia" 3. mediawiki is also widely used for documentation and requirements engineering by open source and share-alike (including free software and open content) projects - most of the target market for trac has to support mediawiki anyway, and in some cases has a strong motive to update large public wikis running on mediawiki 2. of hundreds of millions of page reads from wikis every year, the overwhelming majority of those are from wikis using mediawiki format. The public interest in supporting, teaching and implementing this format is now immense and unstoppable, even if a markedly "better" wiki format existed, it would not overcome this data compatibility problem. 1. Most importantly, almost all technical and requirements domain concepts that might need to be referred in specifications already have names in most widely used languages thanks to Wikipedia. Working out the most neutral and least controversial names for tens of thousands of scientific, technological, business and other concepts has been the greatest contribution of the Wikipedia project. Since those names are expressed in the characters allowed in mediawiki names, with many conventions growing out of Wikipedia usage, any deviation (any more or less permissive use of characters) would "break" the character set and force "translation" of names of concepts to determine if the concept existed in the Wikipedia namespace (or "GFDL corpus namespace" to be legally more exact as all Wikipedia content is under GFDL and other mediawikis copy the names under this license). |
| | 1 | There are compelling reasons to support mediawiki format completely in the core trac release. |
| | 2 | 1. jamwiki is cloning mediawiki in Java and keeping the format identical so Java-based projects can easily integrate a full wiki. |
| | 3 | 2. drupal_wiki is likewise supporting mediawiki format as its native format |
| | 4 | 3. mediawiki is very widely used in intranets already including very large ones like the US inteligence services' "Intellipedia" |
| | 5 | 4. mediawiki is also widely used for documentation and requirements engineering by open source and share-alike (including free software and open content) projects - most of the target market for trac has to support mediawiki anyway, and in some cases has a strong motive to update large public wikis running on mediawiki |
| | 6 | 5. of hundreds of millions of page reads from wikis every year, the overwhelming majority of those are from wikis using mediawiki format. The public interest in supporting, teaching and implementing this format is now immense and unstoppable, even if a markedly "better" wiki format existed, it would not overcome this data compatibility problem. |
| | 7 | 6. Most importantly, almost all technical and requirements domain concepts that might need to be referred in specifications already have names in most widely used languages thanks to Wikipedia. Working out the most neutral and least controversial names for tens of thousands of scientific, technological, business and other concepts has been the greatest contribution of the Wikipedia project. Since those names are expressed in the characters allowed in mediawiki names, with many conventions growing out of Wikipedia usage, any deviation (any more or less permissive use of characters) would "break" the character set and force "translation" of names of concepts to determine if the concept existed in the Wikipedia namespace (or "GFDL corpus namespace" to be legally more exact as all Wikipedia content is under GFDL and other mediawikis copy the names under this license). |
| 3 | | Accordingly, the benefits of keeping trac internal data and user's internal documentation in mediawiki format are profound: 1. any concept whatsoever that is named in a document can be quickly checked to see if it exists in Wikipedia or a list of other public wikis, and the option to link it added 2. statistically improbable phrases can be related to more standard phrases by relatively simple programming/searching methods, e.g. consulting Amazon lists of keywords attached to books, checking for matches with text of Wikipedia articles 3. any page managed by Trac can be instantly moved to, or can instantly incorporate updates from, or possibly embed or be embedded in, any other page in a large public wiki or mediawiki- or drupal- or jamwiki- based intranet 4. TracWiki could become the Python equivalent of jamwiki (Java) and possibly be included in other applications as a module as is intended for jamwiki; This would better distribute the maintenance effort and spread trac 5. mediawiki extensions would be encouraged to integrate trac so that, for instance, bugs in mediawiki-based services would be able to contain trac links directly in talk pages and edit summaries. 6. anonymous trolls are more likely to complain about errors seen in trac, as all anonymous trolls already know mediawiki format so they can troll Wikipedia 7. such trolls will no longer appear to write long whiny tickets like this. These advantages will get more significant, not less, over time, as the number of trolls in the world increases (we may be in the Troll Age). |
| | 9 | Accordingly, the benefits of keeping trac internal data and user's internal documentation in mediawiki format are profound: |
| | 10 | 6. any concept whatsoever that is named in a document can be quickly checked to see if it exists in Wikipedia or a list of other public wikis, and the option to link it added |
| | 11 | 7. statistically improbable phrases can be related to more standard phrases by relatively simple programming/searching methods, e.g. consulting Amazon lists of keywords attached to books, checking for matches with text of Wikipedia articles |
| | 12 | 8. any page managed by Trac can be instantly moved to, or can instantly incorporate updates from, or possibly embed or be embedded in, any other page in a large public wiki or mediawiki- or drupal- or jamwiki- based intranet |
| | 13 | 9. TracWiki could become the Python equivalent of jamwiki (Java) and possibly be included in other applications as a module as is intended for jamwiki; This would better distribute the maintenance effort and spread trac |
| | 14 | 10. mediawiki extensions would be encouraged to integrate trac so that, for instance, bugs in mediawiki-based services would be able to contain trac links directly in talk pages and edit summaries. |
| | 15 | 11. anonymous trolls are more likely to complain about errors seen in trac, as all anonymous trolls already know mediawiki format so they can troll Wikipedia |
| | 16 | 12. such trolls will no longer appear to write long whiny tickets like this. These advantages will get more significant, not less, over time, as the number of trolls in the world increases (we may be in the Troll Age). |
