From Fedora Project Wiki
fp-wiki>ImportUser
(Imported from MoinMoin)
 
m (Cleanup.)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
<!-- Do not remove
{{header|infra}}
-->
<!-- StartHeader
-->
<pre>#!html
<div style="height:66px; width:100%; background-color:#002867;">
<a href = "http://fedoraproject.org/wiki/Infrastructure"> <img style="float:right;padding-top:3px;" src="http://fedoraproject.org/wiki/Infrastructure?action=AttachFile&do=get&target=InfrastructureTeamN1.png" /></a>
</div>
 
<HR style="height:2px; background-color:#00578E;" />
</pre>
<!-- EndHeader
-->


= Requirements for a New Wiki =
= Requirements for a New Wiki =
Line 46: Line 34:
* Email notifications?
* Email notifications?


----
[[Category:Infrastructure]]
[[Category:Infrastructure]]

Latest revision as of 21:36, 25 May 2008

Requirements for a New Wiki

  • Performance
  • MoinMoin has some architectural problems that limit performance, especially when saving changes. In theory these architectural problems with MoinMoin are solvable but no one has stepped up and written some code yet.
  • The Wiki sees a lot of traffic, especially around release time.
  • Interacting well with proxies and load balancers is important, as we use both to improve performance/reliability.
  • Full text searches are currently very slow.
  • Security
  • Integration with the Fedora Account System - there shouldn't be a different username for editing the Wiki from what is used for the rest of the Fedora infrastructure.
  • ACLs - some pages (e.g. the Packaging hierarchy) need to have edit access limited to specific groups of individuals.
  • I would like to have an easy way to propose changes to ACL protected pages by editing them and waiting for someone to approve the changes. It is really a PITA to ask everytime on via mail for a change. This would also make it easier to discuss changes to a wiki page, even when there is no acl.
  • Underlying implementation needs to have a good track record for security - e.g. anything implemented in PHP going to have an uphill battle to gain acceptance.
  • Automated conversion of existing content.
  • Keeping history of changes would be nice, but not a requirement.
  • No one wants to manually reformat poorly translated content.
  • Ability to convert sections of the wiki to DocBook XML or to manual pages.
  • For the release notes and other Docs projects uses.
  • I18N
  • Page translations
  • Separate language URLs
  • HTML/CSS
  • Output valid/semantic markup
  • Easily themable
  • General
  • SQL Backend
  • Unicode support
  • Hierarchical pages
  • Page history
  • Searchable
  • File attachments
  • Categories?
  • Email notifications?