[wplug-internet] Internet Committee

[Michael Semcheski]

> > Where should the board and committees keep their documents?  (e.g., on
> > the server, in google documents, webdav, etc.)

> Is there any reason why these "documents" should treated differently
> from any other content to go onto the webserver?
> There should be a content management system, which could be as simple as
> having a commit hook script in subversion (or cron job or ... or ...)
> that puts the latest version of the content into the webserver document
> root or as complex as we deem necessary to satisfy wplug's collective
> proclivity for tech.

This is how it came up (in my mind) that we should think about giving
members shell accounts.

Why not have directories on the server for each committee, for the
board, etc.  For instance:
The members list would be in the board directory.  All users in the
'board' group would have write access to that directory.  Regular
members might have read access.

Same with committees.  Lets suppose that the Internet Committee came
up with some SOP's related to how to handle the tasks that come up
from time to time.  Examples are: New mailing list, mediawiki upgrade,
restore from a backup, change board members, etc.  These documents
could be kept in a directory on the server, and committee members
would have right access.

In my view, its much simpler to have this accessible via shell/vi or
scp than a web collaboration system, and probably easier to maintain,
too.  If all of this was in a version control system, than we still
might need to give out accounts so people could access the repository.


> The most important point is to have easily available documentation that
> says "here are the decisions we made, here's how to get started, here
> are instructions for common tasks (user administration, content
> add/remove/rollback, list management, etc.)"

I think if you do a good job on the documentation side, you can do a
lot more with your implementation.  An example is shell accounts.  If
we have as part of the documentation that we only give out shell
access at GUM's or committee meetings, that users getting shell access
are properly indoctrinated and know that shenanigans will not be
tolerated... and we back that up with procedures that purge the passwd
file of out-of-standing accounts... then there's a chance that it
would work.

If you don't have documents that assume the reader is someone who took
over a few years later and has no clue and no guidance and is trying
to get things under control, then in a few years, when many of us have
moved on, the people who pick up the slack are in a bad spot, and
things start to break down.

And one more thing, I like wiki's, and all of the SOP's in my lab are
on our wiki.  But for what we're talking about, I'm a little hesitant.
 Suppose the wiki crashes?  Suppose its vandalized?  That's why I like
keeping the 'collaboration' system as simple as possible, with as few
dependencies as possible.

But I'm certain there are other ways that we can accomplish what we're
trying to.  I'm not saying what I've laid out is the only way.  The
bottom line is we'll get out of it what we put into it.

Mike