On Sat 12 May 2007, Kake L Pugh <kake(a)earth.li> wrote:
OK, so since Daniel has stepped down, and after
several people (thank you!) - I'll write a proposal for a hackathon
with me as moderator. I'll take Daniel's summary and people's
comments into account; now would be a good time for last-minute input
if anyone has any.
Here's the first draft - comments welcomed.
OpenGuides is a complete wiki-based application for running a website about
some subject where geographical location is important. The most popular use
at the moment is as a platform for a guide to a city - London, Oxford,
Vienna, and Boston are among the major cities covered. The project has been
running for over four years now, and has a small core team of programmers as
well as a close-knit community of other interested parties including
contributors to the various guides.
The content of an OpenGuides website is managed by the Wiki::Toolkit suite
of modules, and stored in your choice of SQLite, MySQL, or Postgres.
OpenGuides itself provides structure and a UI layer on top of this.
OpenGuides and Wiki::Toolkit are both written in Perl, and are available on
One of the major advantages of Openguides over other wiki software is its
use of structured data, allowing complex queries such as "find me all the
real ale pubs within 500m of King's Cross station which serve food at
lunchtime" . Most search results can be viewed either as a list or on a
map, using the Google maps API .
We have many, many tasks which could be addressed at a hackfest, depending
on the skills and interests of the participants. These include:
Currently we use the traditional "wiki way" of not requiring any
authentication at all; usernames are simply stored in a preference cookie by
the user's browser. We'd like to add authentication as an option; OpenID is
one possible way of going about this.
- making it easier to extend the core OpenGuides package
Many guide admins have written add-ons to supplement the capabilities of the
OpenGuides distribution; some of these can be folded back into the core,
while others only make sense for particular guides/cities/countries. Making
it easier to write these extensions not only makes it more likely that
people will hack on things that can eventually go into the core, it also
makes it easier for people to create local extensions without having to fork
the codebase. This task can be broken down into a number of possible
subtasks, for example:
- creating an SQL query builder
- refactoring the structured data handlers to allow customisation of
the structured data fields
- creating a template framework to allow a consistent look and feel
between core OpenGuides and local extensions
- "good enough" internationalisation
OpenGuides' HTML is output by means of the Template Toolkit; we distribute
the templates along with the Perl modules. Currently, these templates are
all in English, and people wanting to run guides in different languages have
to translate and maintain their own set of templates. All I'm thinking of
at this stage is a way to let us distribute templates in multiple languages
without significant repetition of presentation logic.
- improving the full-text search
The text search is handled at the Wiki::Toolkit level; the content of a page
is tokenised and indexed when a page is saved. We need better canonicalisation
of these tokens to allow fuzzy matching (to catch misspellings) and to make
sure that punctuation is irrelevant in searching (e.g. King's Cross vs.
- page deletion
Page deletion is irreversible at the moment, which is not a good thing.
What we need to do is add "deletion" in at the Wiki::Toolkit level, by
marking "deleted" pages/page versions as non-visible, and then making sure
they don't get returned by queries unless specifically asked for.
- JSON output / API
We've always been very keen to allow data-sharing between OpenGuides and
other applications. We have RDF output, but this isn't hugely
programmer-friendly due to the amount of faff needed to actually get out
usable information. Other, more programer-friendly outputs would be great;
JSON might be a useful starting point.
- non-Perl tasks
Obviously this is a Perl-based conference and a Perl-based hackathon, but
there are a number of other tasks which could be done by people who're
interested in OpenGuides but don't feel comfortable diving straight into the
code - or indeed non-Perl partners; I'll be providing one of these :)
Non-Perl tasks include: template translation, user testing, writing
documentation, coming up with new example designs/stylesheets.