1 <?xml version="1.0" encoding="utf-8"?>
2 <!-- Generated by Docutils 0.9 -->
3 <document source="original/WikiRequirements.rst">
7 <section ids="requirements-for-an-oekonux-wiki" names="requirements\ for\ an\ oekonux\ wiki">
9 Requirements for an Oekonux Wiki
11 <topic classes="contents" ids="contents" names="contents">
18 <reference ids="id1" refid="requirements-for-an-oekonux-wiki">
19 Requirements for an Oekonux Wiki
25 <reference ids="id2" refid="introduction">
32 <reference ids="id3" refid="requirements">
39 <reference ids="id4" refid="non-functional-requirements">
40 Non-functional requirements
46 <reference ids="id5" refid="functional-requirements">
47 Functional requirements
53 <reference ids="id6" refid="requirements-for-policy-choices">
54 Requirements for policy choices
62 <comment xml:space="preserve">
63 ############################################################################
65 <comment xml:space="preserve">
66 ############################################################################
69 <section ids="introduction" names="introduction">
75 <reference name="Project Oekonux" refuri="http://www.oekonux.de/">
78 there has been a long discussion about setting
79 up a Wiki for the project. Also several attempts to establish a Wiki
80 have been made. Most of these discussions took place on
81 <reference name="the projekt mailing list" refuri="http://www.oekonux.de/projekt/liste/">
82 the projekt mailing list
85 which is the organizing body of the project.
88 One of the most important questions was which Wiki software to use.
89 Finally a decision has been made based upon the requirements being
93 The following lists all the requirements which have been found and
94 lists the alternative solutions for them. One reason for this list is
95 to document the design decisions / choices taken and their basis in
96 the requirements. This way it is easier to
98 <bullet_list bullet="*">
101 understand the decisions
106 change decisions while not forgetting about reasons for the original
111 <comment xml:space="preserve">
112 ############################################################################
114 <comment xml:space="preserve">
115 ############################################################################
118 <section ids="requirements" names="requirements">
122 <section ids="non-functional-requirements" names="non-functional\ requirements">
124 Non-functional requirements
126 <enumerated_list enumtype="arabic" prefix="" suffix=".">
129 The software must have an active developer community and must be
139 Only an active developer community of a Free Software
140 project guarantees for a constant development.
146 Discussion came down to two candidates which met this requirement:
148 <reference name="MediaWiki" refuri="http://wikipedia.sourceforge.net/">
152 <reference name="MoinMoin" refuri="http://moinmoin.wikiwikiweb.de/">
155 . The following requirements list
156 alternative solutions only for these two Wiki implementations.
161 The software must be easy to use for people used to Wikipedia
170 Because of the overwhelming success of Wikipedia many
171 people are used to the way how Wikipedia is operated.
191 The typical use cases need to be identified and a
192 special help page must be created for these users.
199 <comment xml:space="preserve">
200 ############################################################################
203 <section ids="functional-requirements" names="functional\ requirements">
205 Functional requirements
207 <enumerated_list enumtype="arabic" prefix="" suffix=".">
210 Email notification must be possible sending diffs and other changes
219 Email notification is a basic requirement for any
230 Rumor has it that there is a plug-in for email
231 notification but nobody saw it yet (2005-03-26).
241 Supports email notification as diffs for arbitrary pages
242 and page groups (regular expression). Only notifies on moves and
251 It must be possible to limit changeability of a page (for instance
261 Some pages are private pages or should not be changes
272 Don't know whether this can be enforced technically.
282 Implements access control lists (ACL) allowing for
291 Categories must be possible
300 With categories can form arbitrary non-hierarchical
329 Navigation panels must be available
338 Useful to create overviews.
362 macro for hierarchical
367 macro for structures based logical
368 expressions on regular expressions over page names.
376 A version history must be available
385 Needed to get an overview of the change history of a
414 List of changes for a given user must be available
451 A watch list must be possible reporting about the latest changes
452 for a given set of pages
481 Can be simulated by email notification.
489 Automatic links by using CamelCase (aka WikiWords) must not be the
499 CamelCase makes sense only in certain language. In
500 particular German is a language where automatic CamelCase links
511 CamelCase words never create automatic links.
522 <reference name="NoCamelCase" refuri="http://moinmoin.wikiwikiweb.de/ParserMarket/NoCamelCase">
525 plug-in makes this the default.
533 Support for other than the standard Wiki syntaxes like
535 <reference name="reStructuredText" refuri="http://docutils.sourceforge.net/rst.html">
547 All Wiki languages suck so support for more sane
548 syntaxes is a very useful thing. In particular support for
550 <reference name="reStructuredText" refuri="http://docutils.sourceforge.net/rst.html">
553 being a powerful language and a good candidate
554 for a standard ASCII based markup language.
564 There is no support for any other syntax than the
575 Offers several syntaxes by the concept of parsers. Among
576 the available syntaxes are
577 <reference name="reStructuredText" refuri="http://docutils.sourceforge.net/rst.html">
581 <reference name="LaTeX" refuri="http://www.latex-project.org/">
592 Arbitrary attachments must be possible
604 Nice to have to attach arbitrary data to a page. In
605 particular it makes possible to include material not marked up in
616 Unknown but probably available.
632 <enumerated_list enumtype="arabic" prefix="" start="11" suffix=".">
635 Shortcuts for links must be available
647 In particular it is useful to be able to reference
648 entries in the Oekonux mailing list archive as easy as possible.
658 Implements this by templates.
668 Implements by InterWiki links.
674 <enumerated_list enumtype="arabic" prefix="" start="12" suffix=".">
677 Page templates must be available
689 Page templates are a good way to support policy
690 decisions by offering standard templates for all page types.
716 <enumerated_list enumtype="arabic" prefix="" start="13" suffix=".">
719 It must be possible to revert page changes
731 Useful to undo unwanted changes.
757 <enumerated_list enumtype="arabic" prefix="" start="14" suffix=".">
760 It must be possible to know who did a change in a page
798 <enumerated_list enumtype="arabic" prefix="" start="15" suffix=".">
801 Offline usage must be possible as far as possible
813 Not everyone is always online so offline facilities are
814 generally useful. Offline usage includes
816 <bullet_list bullet="*">
819 a push feature for change notification
841 Not available. At most email notification is available.
851 Email notification allows for monitoring changes and in
852 principle the diffs can be used to update a local copy. A local
854 <reference name="MoinMoin" refuri="http://moinmoin.wikiwikiweb.de/">
857 only needs Python and
858 <reference name="MoinMoin" refuri="http://moinmoin.wikiwikiweb.de/">
862 is easy to accomplish. Because
863 <reference name="MoinMoin" refuri="http://moinmoin.wikiwikiweb.de/">
867 storage scheme it is at least easy to update a local copy in
868 short online phases for offline use so at least offline browsing
875 <enumerated_list enumtype="arabic" prefix="" start="16" suffix=".">
878 Pages must be locked during they are edited
890 Page locking prevents parallel editing of a page which
891 is useful in a highly frequented Wiki.
911 Editing a page locks it for 10 minutes and the lock can
918 <enumerated_list enumtype="arabic" prefix="" start="17" suffix=".">
921 It must be possible to edit sections of a page
933 Makes parallel editing of a page less dangerous which
934 is useful in a highly frequented Wiki.
960 <comment xml:space="preserve">
961 ############################################################################
964 <section ids="requirements-for-policy-choices" names="requirements\ for\ policy\ choices">
966 Requirements for policy choices
968 <enumerated_list enumtype="arabic" prefix="" suffix=".">
971 Pages standing in a certain close relation to a certain other page
972 must be possible in a sane way
981 There are several ways in which a page can have closely
982 related pages (e.g. discussion pages). It makes sense to have a
983 uniform way to express this relation.
993 Implements discussion pages as one a special type of
994 closely related pages by suffixing
999 namespace of a page. For other closely related pages there is no
1000 fixed implementation.
1010 By making sub-pages possible all types of closely
1011 related pages can be implemented by some fixed names being part
1012 of a policy and supported by page templates.
1020 Structuring of content must be possible by a page hierarchy
1029 The maintenance policy may decide to have a page
1030 hierarchy as a structuring principle.
1040 Implements a top level structure by namespaces and
1041 allows for structuring otherwise.
1051 With sub-pages arbitrary hierarchies can be build on any
1060 Sub-Wikis must be possible
1069 The maintenance policy may decide this makes sense.
1089 Could be done in a page hierarchy on any level.
1097 Underscores and white-space in page names must be possible but
1107 If the maintenance policy decides that underscores and
1108 white-space may be used in arbitrary ways the software must be
1109 able to reflect this.
1129 Underscores and white-space is significant.
1136 <comment xml:space="preserve">
1137 ############################################################################
1139 <comment xml:space="preserve">
1140 ############################################################################
1142 <substitution_definition names="projekt">
1143 <reference name="the projekt mailing list" refuri="http://www.oekonux.de/projekt/liste/">
1144 the projekt mailing list
1146 </substitution_definition>
1147 <substitution_definition names="NoCamelCase">
1148 <reference name="NoCamelCase" refuri="http://moinmoin.wikiwikiweb.de/ParserMarket/NoCamelCase">
1151 </substitution_definition>
1152 <target ids="project-oekonux" names="project\ oekonux" refuri="http://www.oekonux.de/"/>
1153 <target ids="the-projekt-mailing-list" names="the\ projekt\ mailing\ list" refuri="http://www.oekonux.de/projekt/liste/"/>
1154 <target ids="mediawiki" names="mediawiki" refuri="http://wikipedia.sourceforge.net/"/>
1155 <target ids="moinmoin" names="moinmoin" refuri="http://moinmoin.wikiwikiweb.de/"/>
1156 <target ids="restructuredtext" names="restructuredtext" refuri="http://docutils.sourceforge.net/rst.html"/>
1157 <target ids="latex" names="latex" refuri="http://www.latex-project.org/"/>
1158 <target ids="nocamelcase" names="nocamelcase" refuri="http://moinmoin.wikiwikiweb.de/ParserMarket/NoCamelCase"/>
1159 <comment xml:space="preserve">
1160 LocalWords: diffs CamelCase InterWiki MoinMoin rst projekt MediaWiki aka
1162 <comment xml:space="preserve">
1163 LocalWords: Wikipedia PageList WikiWords reStructuredText
1165 <comment xml:space="preserve">
1166 LocalWords: Wikis NoCamelCase