Hi! On Tue, May 08, 2007 at 01:33:58PM +0100, Kake L Pugh wrote: The role of the "moderator" maybe sounds more complicated than what we expect, which is: Somebody to a) give a short introduction on the topic (~20 minutes) so that 'newcomers' know what the project is about and how the big parts relate to one another b) prepare some tasks (from open bugs to new feature ideas) c) help people (especially newcomers) to start working on some of those tasks (this is probably the hardest thing...) So maybe somebody (or even several people, if they can agree on sharing the available funding (up to 500 Euros)) now wants to step up and submit a proposal (which doesn't have to be a full-fleged business plan, a short description of OpenGuides and several tasks / TODOs should be enough) -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

On Sat 12 May 2007, Kake L Pugh <kake(a)earth.li> wrote: Here's the first draft - comments welcomed. Kake ---------------------------------------------------------------------------- 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 CPAN. 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" [0]. Most search results can be viewed either as a list or on a map, using the Google maps API [1]. [0] http://preview.tinyurl.com/22jlzu [1] http://preview.tinyurl.com/2ddc3d We have many, many tasks which could be addressed at a hackfest, depending on the skills and interests of the participants. These include: - authentication 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: - modularising our javascript snippets into libraries - 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. Kings Cross). - 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.

I'm willing to moderate a hackathon. According to the site, a hackathon lasts three hours, has a 30 minute intro, and then some coding delegation/hacking. I'd hope that in the next 7 weeks I can accumulate 30 minutes of discussion material. :) Are there any topics that anyone feels are a must-have? I'm thinking about benchmarking for different db sizes, access control, auth integration, advanced google maps, spam control, Are we sure no one else is interested? Being the most junior team member, I get lowest priority, but it seems a shame to waste a sponsored trip to Vienna, and I'd love to meet the team and do some hacking. Give me some feedback and I'll post a proposal by end of day tomorrow. -Daniel Kake L Pugh wrote: -- Daniel Packer, Principal X To Infinity, LLC 191 Chrystie St, Suite 3F New York, NY 10002 P 718.502.6519 / F 866.833.0673 Web, Code, Software, and Systems. Visit www.xtoinfinity.com for info.

A naive response from a non-programmer (who is highly grateful for all the cool work you are doing) - I'd partly agree with Simon, my preference would be something that allows us to choose between mapping systems as they improve on each other. Ideally openstreetmaps or another free+open format would be the goal but in Milton Keynes right now Google give us the best resolution. I suspect as Simon notes best quality option varies from locality to locality. We're intending on having a push on openstreetmapping but I can't see it happening comprehensively for a year or so here. regards and thanks again! Mark (Milton Keynes Open Guide) http://miltonkeynes.openguides.org/ -----Original Message----- From: openguides-dev-bounces(a)lists.openguides.org on behalf of Stephen Gower Sent: Tue 5/8/2007 11:01 PM To: OpenGuides software developers' list Subject: Re: [OGDev] Fwd: YAPC Europe 2007 Reminder - CFP and CFH DeadlinesApproaching On Tue, May 08, 2007 at 04:50:55PM -0400, Daniel Packer wrote: Just picking on one bit! Can we reduce that to "advanced maps"? I don't mind if, at the end of the day, consensus is that google is the way forward, but it seems to me (as a non-programmer) that google got a headstart by being the first "slippy" map with a decent API. For Oxford, at least, there are better free (as in beer and maybe as in speech) maps available from a user point of view * The aerial photography in maps.live.com is way better, cos Google still don't have Oxford in a decent resolution (everything to the east, but it stops at the ring-road. * The maps from maps.live.com are better than google, showing more paths and other non-car routes, but even better (where it exists) is the data from openstreetmap - and that's getting better all the time. In most of Oxford we've now got every cyclepath and footpath as well as streets covered - and that's important when pubs for example are only accessible by towpath or other footroute. Compare for example the "Map" and "Mapnik" links on the map at http://oxford.openguides.org/wiki/?Perch and suddenly you see another way of getting there (the Mapnik link is images made from fairly old openstreetmap data of Oxford). s -- OpenGuides-Dev mailing list - OpenGuides-Dev(a)lists.openguides.org http://lists.openguides.org/cgi-bin/mailman/listinfo/openguides-dev

It's not going to make sense for me to do the hackathon since I may not be using OpenGuides for my project after all, and my time to devote (if any) would be limited. OG is such a great project I hope I can still contribute somehow either way. -Daniel Daniel Packer wrote: -- Daniel Packer, Principal X To Infinity, LLC 191 Chrystie St, Suite 3F New York, NY 10002 P 718.502.6519 / F 866.833.0673 Web, Code, Software, and Systems. Visit www.xtoinfinity.com for info.

On Tue 08 May 2007, Daniel Packer <daniel(a)xtoinfinity.com> wrote: Custom metadata would be very nice too. Kake