-----Original Message----- From: openguides-dev-bounces@openguides.org [mailto:openguides-dev-bounces@openguides.org]On Behalf Of Christopher Schmidt Sent: 01 December 2005 19:12 To: openguides-dev@openguides.org Subject: [OGDev] Marketing to OG Admins
[...]
- Ardurous Installation I personally find setting up a guide to be a non-trivial task. I'm getting used to it now - with Milton Keynes, it only took about 20 minutes total to get everything up and running - but the biggest reason for that is that the OG packages are already installed for Boston.
Have a look at ticket #36: http://dev.openguides.org/ticket/36
Many users don't have the ability to install systemwide perl modules, and users like me who don't know perl don't know how to set up the guide to point to a local directory. I think that a self-contained package for OG including all the perl modules which the app needs, and a preset use lib() pointing to a relative directory, would be the most useful thing that OG could do to ease installation.
Maybe PAR is an option. I am successfully using PAR at work. http://search.cpan.org/~autrijus/PAR
I suppose this might get relatively ridiculous: You can require that easy to install or commonly installed packages are already taken care of, but documenting these dependancies could go a long way towards at least letting people know if they could install OG.
I don't know if this is realistic or not, but I know that I do not find installing OpenGuides to be easy, nor is maintaining two seperate copies of the libraries (for Boston and Milton Keynes: I have a number of boston specific changes) to be something that I know how to do.
See ticket #36
If there is a way to make it such that OG can be installed by anyone with FTP and MySQL access, without any need for a shell account or CPAN, given a list of perl modules that they already have, and that seperate instances can be maintained for multiple guides, I think that it would be more commonly installed by guide admins and more commonly tested as well. If you can provide a nightly build that someone can just upload with a hand edited wiki.conf, you'll probably see more people able to test the changes without risking breaking their current guide.
See above.
- Reaching out Globally Right now, OpenGuides feels very much like a UK-centric
project. Dom is doing work to correct this, learning about projections and so on. I think that once we have cleaned up some of the Euro-centric aspects of openguides (and made clear some of the Geo aspects that are confusing at the moment), a good goal would be to reach out to other global users and try and find guide admins. With an easier setup process or the offer to host a guide for them, a number of users may be willing to support a wiki-guide to their city, especially in the absense of other similar services in the area. It would be interesting to see, for example, the Open Guide to Sydney - perhaps even hosting it with a current OGDev member as admin, and then trying to pimp it to sydney locals, thus skipping the setup step.
Good!
- Whizbang features I think that some features could be shortlisted for adding to the whizbang effect of OpenGuides:
- Google Maps support
Yup, that's what makes the Boston site look fantastic.
* New Data Format support - I'm thinking somethingalong the lines of providing JSON data interface as well as RDF, to possibly improve the integration with other web or non-web applications. (I've already implemented a JSON export of Boston, via
http://boston.openguides.org/?id=Central_Square_Station;action
=edit;format=js , which I'm using to write a Python commandline client.)
We should look to make this pluggable, to support future requirements for exporting data.
I don't know what else is considered Whizbang, but I think those could be neat to take advantage of some of the "OMG AJAX" movement going on in the web world today.
I'd qite like to see OG running under mod-perl.
My £0.02
Ivor.