[SGVLUG] Website Testing

[Dustin]

On Wed, 20 Jul 2005, David Lawyer wrote:

> I saw this too when I was checking out some links to sgvlug.org.  I
> think the person who wrote this is wrong.  Our site quickly, simply
> and rapidly provides info on sgvlug.

Two things: first, "boring" is an aesthetic judgement.  Second, while you
say "Our site quickly, simply and rapidly provides info on sgvlug" in a
context that suggests that you are offering it as a counter-argument to
the assertion that the site is boring, in fact it has no relevance to
boring.  Both can easily be true, and in fact I think they both are true.

What we really want is a site which ALSO "quickly, simply and rapidly 
provides info on sgvlug" but is not boring.

> person (and perhaps still am).  So I think that attendance is down
> because of our website failure.

I think that Tom was partly or wholly joking about the website appearance 
affecting membership.  In any case, we can't fix the website any faster 
than we are, so it isn't really worth discussing until we have further 
developments (which I hope will be Matti saying "yes, we have it 
working").

> There's also the universal markup method which is something like an
> html editor.  You create a page in say docbook or linuxdoc using vim
> and then run it thru a filter to get hmtl, plain text, pdf, etc., etc.
> Docbook is a very powerful markup language but why use it to create
> html pages when Docbook is equally as complex as html.

This doesn't actually solve any of the problems of writing plain html in 
vi--it's brittle, higher maintenance, and doesn't allow delegation.  In 
fact, it's worse in that it has a higher learning curve.

Universal markup is a solution to an entirely different problem than we 
have, unless you frequently find yourself thinking "if only I could sit 
down with a hot cuppa in front of the fire and read the SGVLUG website on 
my laptop in PDF form."

I don't find myself wanting to do that all that often.

> > The problem with using "just a plain text editor" is that once you
> > get to "more than one person doing the work" [or even "one person
> > using more than one computer"], you need to invest in a
> > revision-control mechanism of some sort anyway -- otherwise you'll
> > get changes overwritten by "the other guy with the older version of
> > the page..."  
> 
> Not if you use the copy on the server as the master copy and update
> it by editing with vim via ssh.  One could log their changes inside
> an html comment and keep a history of changes there, to be removed
> every couple of years when it becomes too large.

Yeah, vim does a kind of primitive file locking by creating a hidden "dot" 
file while the editing takes place.

Now what happens when I decide to use emacs while Tom is using vi?

> There are other ways too.  Suppose we have two co-maintainers, each one
> of which agrees to maintain the site for a 3-month period and then
> take 3 months off.  Or they can negotiate between themselves for
> variations: one fills in while the other is on vacation, too busy,
> etc.

This kind of thing is not very workable for volunteer organizations, 
because things change.  People legitimately have things that take 
priority, and it is unrealistic to expect such a system to work for long 
periods of time.

It *is* better than unloading it all on a single victim like Charlie, but 
introduces problems of its own (I thought you were doing this meeting).

> Also there can be two or more ssh login accounts on the server.

AFAIK, that is precisely what Michael wants to avoid for security reasons.
Sure, we could just give everyone in the LUG a shell account and delegate 
as much as we want.  It isn't a real solution.

> So there are simple ways to do this for sgvlug without any revision
> control system.

We can all invent many, many schemes for doing things manually.  What you 
don't seem to understand is that the people who are maintaining the site 
seem to be very clear that they do NOT want to do things manually if they 
don't have to.

> But as I explain above and Tom explains below, sharing the work
> doesn't require a dynamic site.

Are you saying you personally would like to maintain the site indefinitely
on your own?  I don't hear anyone else with much interest in doing it the
hard way.

> ...For the Linux Documentation Project
> (LDP), the hosting site would not allow the use of Plone, partly due
> to alleged excessive bandwidth needed by Plone.

That was almost certainly excessive server load, not bandwidth.

In any case, this is what testing is for.

> ...Part of the problem
> was the fact that the person that was hard at work to make Plone
> suitable for LDP became seriously ill and may die.

AFAICT if we implemented your solution we would have a similar problem--so
far only you find it in the remotest attractive.  In fact your solution is
more or less identical to what we've already been doing and are doing
right this minute, and Tom (at least) has told you so.  The fact that the
people who are using it at this minute don't much like it says something.

Dustin