[clue-admin] [Fwd: changing website]

[Jed S. Baer]

On Fri, 14 May 2010 11:53:47 -0600
Dennis J Perkins wrote:

> There doesn't seem to be enough interest among the members to decide
> which way to go.  They should be asked again before a decision is made.

I don't see any need for a general question to the membership. We have a
big enough task in front of us just getting agreement among the
interested parties on the admin list.

> As to whether we should choose a wiki or a blog, I think it depends on
> what we want to do.  A wiki is good for organizing lots of information.
> A blog is better for someone posting his thoughts and getting comments.
> I think a wiki might be better for our needs, but maybe someones sees
> how to use a blog for a group.

The core function of the website is to provide information to
participants in CLUE, mostly in the way of what the meeting schedule is,
and Installfests. In that way, it's more like a blog than a wiki. But it
also should have the function of a scheduler, i.e. a calendar app.
Announcements are like a blog function, but there's a record (or should
be) of each meeting, which is a seperate thing.

> Mediawiki would work.  A Chicago Linux group uses it.  One speaker
> copied our website for his presentation.

I hope a copy of that is available.

>  Mediawiki offers multiple
> passwords and password levels.  It's not hard to use; just learn a very
> simple markup language.

There's more to it than that, because there are customizations, at least
in the configuration, which we would need to suit our needs. At least I
think that's the case.

> A few individuals voiced opposition
> to PHP, which is what Mediawiki is written in.

All languages have good / bad things. Properly implemented, I can't think
of any "fatal" flaws in PHP. Sure, language purists will make points
about how it implements its object model, etc. None of this is germaine
to our goal. If anyone has objections to PHP which are of a
"show-stopper" type, I'm certainly open to hearing them.

> Writing our own program is out of the question.

I think it's too early to make that determination. We ought to be asking
how many PHP programmers there are, vs. how many people there are who are
familiar with the Drupal model, or the Joomla model, or whatever CMS it
is. We need to ask what the learning curve is for these CMS packages. We
could also ask whether an application framework would be better than a
CMS package.

> It could be fun but I
> doubt we could maintain the interest to pull it off and it would be
> custom.

Can we not raise the same objection to {insert package name}?

> Either a wiki or a blog will require a database.  MySQL is the most
> common.  PHP is also needed; maybe we need a PHP module for Apache?  Or
> does it run standalone in this case?  I'm guessing our provider would
> let us do this but maybe I'm wrong.  The database and config files need
> to be backed up.  If the database gets large, would backups become a
> problem?

The CLUE website already runs under PHP. Since we have virtual host, we
can install whatever we need. I've begun to be curious about SQLlite.
Part of the question will be whether we're going to build access controls
into the database itself, or leave them in the application. And, if we
choose a package, then we'll have to choose from what the package
supports.

> Jed has mentioned requirements.  He said they are in the admin mailing
> list.  I don't know exactly where they are.

http://cluedenver.org/pipermail/clue-admin/2009-December/003598.html

I think it'd be reasonable to use a Wiki to maintain requirements and
specifications. I'm not particularly thrilled with being the guy who
maintains access privileges to that Wiki, nor do I want it to be publicly
accessible. Not sure exactly what the access levels ought to be. But I'll
do it, if nobody else steps up. We can host it on the CLUE server, or use
a service such as WikiDot.

jed
-- 
Ok, so we should be thinking of a lovable, cuddly, stuffed penguin
sitting down after having gorged itself on herring. Still with me? 
 -- Linus Torvalds