-----Original Message-----
From: openguides-dev-bounces(a)openguides.org
[mailto:openguides-dev-bounces@openguides.org]On Behalf Of Christopher
Schmidt
Sent: 01 December 2005 19:12
To: openguides-dev(a)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
something
along 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.