|
|
OpenSolaris Wiki RequirementsSummaryThis page discusses the requirements for Wiki or Wiki-like technologies for use on the OpenSolaris website. The requirements are grouped in decreasing order of importance (that is, the groups are of decreasing importance) using terminology proposed in IEEE Std 830-1998, consistent with the DSCM requirements document.DiscussionThe requirements detailed here should be taken in the context of the website restructuring effort, details of which can be found here. The list is drawn, in part, from the original set of requirements posted on Genunix, referenced here for completeness. The requirements posted here should also be covered by the requirements listed below. If you would like to comment on the requirements, or suggest new requirements, the best place to do so is the website-discuss mailing list.Essential RequirementsE0 The software must be free and open sourceTo be considered for use by the opensolaris.org website, the software must be available under an OSI approved open source license. E1 The software must have a page historyA page history is considered essential in order that page edits may be logged and, if necessary, reverted. This must also work for page translations. Revision 'diffs' are also highly desirable. E2 The software must have pluggable authenticationThe software must be able to be integrated with the opensolaris.org authentication application through the development of suitable code. (See auth.opensolaris.org for more details). Roles held in the OpenSolaris user management system must be mapped to the wiki software's notion of roles in order that permissions may be set appropriately. E3 The software must be Java basedIn order that the wiki software can be extended and maintained, given the infrastructure resources, the most sensible choice of technology on which to base the software is Java. E4 The software must have a WYSIWYG editorNot everyone who wishes to contribute to the site will be familiar with the text formatting rules of a particular wiki or indeed with wikis themselves. A 'what you see is what you get' editor makes it easier for people to contribute. The editor should have tool bars, a preview capability and support rich formatting. Ideally, the software should also support pluggable editors. E5 The software must support non-ASCII titles The software must allow the creation of pages with non-ASCII titles E6 The software must support UTF-8UTF-8 must be the only allowed encoding E7 The software must support UTF-8 exportExport to other formats, say PDF, should work for non-ASCII characters. E8 The software must support language taggingAll pages should be tagged with the content-language, that is, authors declare the content-language at page creation time. E9 The software must support translation linkingAll language versions of a page should be cross-linked. That is, source pages should point to available translations; translated pages should point back to source. (Translation is not a lossless process. Readers of translated material like to be able to easily refer back to the material in the source language. Many users find the source [typically English] versions first - through search, navigation etc. Linking from the English increases the 'findability' of the translations.) E10 The software must support an internationalized UIAll UI strings should be externalized into resource bundles, which allows for easy translation of the UI. E11 The software must support a translation APITranslation processes are greatly simplified if there's an API that allows the content to move in and out. Moving content in and out through the UI does not scale. E12 The software language support must scaleAny language content model should clearly scale to support many languages.Conditional RequirementsC13 The software should have an active communityIn order that defects may be addressed and enhancements be made the software should have an active community with at least mailing list support. Current user guides, administration guides, development guides and API documentation are also highly desirable. C14 The software should have pluggable content storageThe requirements for extracting content for use elsewhere or indeed for importing content may change over time. While versioned flat-file storage is probably acceptable, it is desirable for the software to have alternative storage capabilities (a database, for example). C15 The software should have pluggable 'look and feel'For the wiki software to render a familiar look and feel, consistent with the rest of the opensolaris.org website, it should be possible to 'skin' the pages with a pluggable look and feel which may be changed when required. If the software does not natively support this, something like Sitemesh may provide an acceptable alternative. C16 The software should be easy to build, install and manageDue to the nature of open source projects, the requirements of the wiki may change over time. As well as being flexible enough to meet these needs in terms of deployment and structural re-organization, the software should also have management capabilities or tools to aid the day-to-day administration. C17 The software should be susceptible to search indexingWhatever search technology is chosen for the opensolaris.org site (see http://auth.opensolaris.org/restructuring.html for a brief discussion), the wiki software should be susceptible to indexing by the search software. It should also be able to restrict searches to a particular language. C18 The software should support accessibilityThe software should support the use of assistive technologies for people with disabilities. This link provides use cases for people with disabilities and this link provides 16 rules for "Section 508" compliance for web-based applications. C19 The software should have support for feedsThe software should support RSS or Atom feeds (for recent changes, for example). C20 The software should have support for file attachmentsThe software should support attaching files to a page. C21 The software should have support for footnotesThe software should support adding footnotes to a page. C22 The software should have support for page redirectionThe software should support page redirection. C23 The software should have taxonomy support (namespaces, categories and hierarchies)The software should support content structuring with support for page taxonomies, for example, page hierarchies, namespaces and/or categories. C24 The software should have support for change notificationThe software should support notification of page updates, watch lists or similar. This capability should be localized. C25 The software should support tracking for orphaned pagesPages without referring links should be readily identifiable. C26 The software should support page commentsThe ability to comment on a page is distinct from being able to edit the page. The software should support users commenting on pages. C27 The software should support right-to-left layoutThe software should support right-to-left GUI layouts. C28 The software should support versioned translation linkingTranslation linking (see above) should link to the correct version. For example, suppose v1.13 of an English page is translated into Korean. The Korean page should link to v1.13, even after the English page is updated to v1.14. C29 The software should support translation prioritySome core material [install guides, faqs, admin guides etc] would be important to translate. Consequently, it would be useful if authors could rank the translation priority of their material. That way any translation volunteers, could quickly identify the more urgent material. C30 Content exportThe software should support exporting of content into other formats such as PDF, XML, ODF. The ability to export multiple pages in this manner is also desirable (although this overlaps somewhat with the 'pluggable content storage' requirement above, this export requirement is more specific as the above is a more general point directed towards management and backup concerns).Optional RequirementsO31 Virtual server supportIn order to give greater flexibility for deployment, it is desirable that the software supports running virtual servers based on hostname. For example, abc.xyz.com is distinct from def.xyz.com even though the two hostnames resolve to the same IP address. O32 Localized page listingThe software should support listing of all pages in a particular language.Evaluation PlanThe evaluation plan is to narrow the number of candidate wiki engines to a manageable number based on the essential requirements, and then proceed to a second round of evaluation based on the conditional and optional requirements. There are over one hundred potential wiki engines available according to www.wikimatrix.org, so elimination based on the essential requirements seems a sensible path forward. Using the Wiki Choice Wizard at www.wikimatrix.org, with the selection criteria that there must be a page history, WYSIWYG editor, installable (rather than hosted), free and opensource and finally that it used Java, 6 candidate wikis emerged; ButorWiki, Corendal Wiki, Daisy, IkeWiki, JSPWiki and XWiki. The comparison is available here. Of those 6, only JSPWiki and XWiki support pluggable authentication (IkeWiki requires more investigation). The evaluation will be performed by the OpenSolaris infrastructure team and evaluation reports posted to these projects pages with notifications sent to the website-discuss mailing list.ScheduleWeeks 1 and 2
Tentative dates:
|