XpdWiki

FrontPage
RecentChanges
XtC
FindPage
PageIndex
XpApprentices

Set your name in
UserPreferences

Edit this page

Referenced by
RecentChangesBug
XtcProjectProposa...
ProjectBrainstorm...




JSPWiki v2.0.52


XtcWiki
Search Wiki:
Your trail:

The goal of this XtcProject is to replace the existing Java-based wiki we're using. We'll be starting with JSPWiki and fork the code. Why fork it? Why not try and continuously integrate? JSP has some unit test coverage.

  • JSPWiki's goals are more general than ours. Furthermore the code could do with some pretty aggressive refactoring and their unit tests could be made much stronger through things like checking that every implementation of an interface like WikiProvider? actually does something sensible rather than returning empty lists.
  • It's also an opportunity for us to practice some of the XP principles like CollectiveOwnership? and ContinuousIntegration. Personally speaking I'd like to make more use of some of the tools that are available nowadays such as: Jester (for MutationTesting), SameTool (for identifying duplicate code although a full-blown version of TheNose would be nicer) and Compuware's Pasta for visualising the package/class dependencies.

Coding sessions will hopefully take place on Tuesday.

We'll need:

  • A customer/customer representative(s)
  • To put together some UserStories for making JSPWiki more suitable given the NatureOfXtc
  • Index cards
  • A CVS repository. Sourceforge seems to be our best bet.
  • Volunteers to play the roles of Customer and Tracker. We could rotate this amongst whoever's available on Tuesdays.
  • People bringing laptops with the JSPWiki code. We'll use the http://www.ecyrd.com/~jalkanen/JSPWiki/cvs/JSPWiki-070303-cvs.tgz build as our branching point.
  • ...?

Possible stories/feature ideas:
  • Auto-creation of the meeting page for each week
  • Aliasing functionality so that a signature/page like IvanM automatically maps to IvanMoore
  • Session tracking so that a vandalism session can be undone more easily. This could be tied into the version control system behind the wiki.
  • Security levels
  • IP blocking so that known vandals can be blocked although I'm not sure this is a good idea as it violates SoftSecurity?.
    • I'm blocking some IP addresses using apache. Since only certain people should be able to add blocks (avoiding denial of service) I think that's the simplest way for the moment.
  • Wiki interlinking so that we can make links that point to other wikis.
  • Autogenerated monthly archives for backup/data mining purposes
    • MeatBall? has some nice IndexingSchemes? that might be interesting from a datamining perspective. Then there's Bryce's WikiNeighbour? http://www.oshineye.com/software/wikiNeighbour.py algorithm that we discussed a couple of months ago.
  • Administrative functionality via some kind of web-console
  • Significantly improved performance and scalability especially on pages like RecentChanges that require a lot of processing.
  • See also XpdWikiUserStories
  • ...

Edit this page   More info...   Attach file...
This page last changed on 14-May-2005 06:49:40 BST by 219.131.237.123.