[cumbria_lug] UserGroup...

Schwuk schwuk at schwuk.com
Wed Apr 21 20:24:56 BST 2004


OK, time to unleash my idea on the world (or rather this list)...

What has been (briefly) referred to in the past as YACMS (Yet Another 
Content Management System) has actually had the working title 
'UserGroup' for a while now... Snappy, huh?

To sum it up in a nutshell, take the acronym CMS (Content Management 
System) and replace Content with Community.

It's a CMS specifically geared towards the running of user groups (you 
can see where I got the name from *grin*). Most of the features I chosen 
so far are geared towards running a Linux User Group (for obvious 
reasons), but could be equally applied to other types of groups e.g. 
Role Playing groups or Hill Walking clubs.

Also, by breaking the features down into components (or modules), they 
can easily be turned on or off, and new ones added.

Ground Rules:
=============
  - All HTML generated will be XHTML 1.0 Strict (preferably) or 
Transistional (as a fallback).
  - All cosmetic changes will be handled through CSS
  - Usability and Accessibility are the watchwords of the day

Features:
=========

  - Users
  - Discussions
  - Articles
  - Events
  - Library

Users:
------
Unless simply browsing the application, all users must be registered and 
authorised. No 'Anonymous Cowards'. All content created (whether an 
Article or as part of the discussions) should attributable.

On top of the Users comes Roles. As well as the traditional role of 
Administrator(s), more specific roles like Article Authors and Event 
Approvers should exist. These roles should be linked to the components, 
and be optional.

Discussions:
------------
Discussions are the cornerstone of the whole thing. Every item created 
through the application will have a discussion thread attached to it. A 
new article is posted - the group can discuss it. A new event is created 
- ditto. Standalone discussions are also supported.

Discussions will be threaded. More like email than the traditional 
bulletin boards (e.g. phpBB).

Articles:
---------
Articles can take two forms:

  - Summaries: e.g. links to off-site articles
  - Full: e.g. a how-to or review

The articles should track status (i.e. draft, published, archived) and 
revisions. Both of these should be masked from the users unless required 
(i.e. the revisioning is transparent, but can still be accessed).

All users can create Articles. There should be an optional approval 
queue, and optional restriction of who can create which types of articles.

I've also considered the (tricky) subject of content licensing (in 
particular Creative Commons), and one idea I've been kicking around is 
to allow the adminstrator to select a default licence, but (optionally) 
allowing content creators to select their own preference both as a 
personal default and on a per-Article basis.

Formatting of the articles has also concerned me - allowing full HTML 
access can cause problems, but using other markups (like phpBB's BBCode 
and Textile - http://textism.com/tools/textile/ ) can make things 
awkward for the users. Supporting something like Mozilla's Midas ( 
http://www.mozilla.org/editor/midasdemo/ ) might help here.

Another feature I've been kicking around is self-moderation. I doubt we 
would need it (currently) for the Cumbria LUG, but larger groups may 
need it. I'm sure most of us are familiar with Slashdot and their 
concept of Karma - my idea is similar to that, but executed differently. 
All users start out with normal rating - 0 if you like. If open posting 
is allowed, anyone with Normal or above karma can post unrestricted. 
Once you have posted an Article, people can moderate it (restricted to 
+/-). If enough people moderate it negatively, the Article is 'pulled'. 
The number of moderations could be fixed or based on the number of 
registered/active users. If you have X number of Articles 'pulled' your 
rating becomes negative and you lose your posting (and moderation) 
rights. Any future post have to be approved before they are published. 
Positive moderation gives users positive ratings, who then have to get 
higher number of negative moderations before getting 'pulled'.

It needs work, I know, but it's a start.

Events:
-------
Self-explainatory really. Support should be included for recurring 
events as well.

Some additional functionality I've been thinking about includes:
  - iCalendar support - publishing of the calendar to other applications
  - RSVP - users can indicate their intention to attend or not
  - trigger levels - events can be flagged as tentative until a (user) 
set number of have confirmed attendence or inversely the meeting will 
cancel itself if a (set) number of people decline.
  - Locations - events should have location information.
  - Location filtering - once a table of locations has been populated, 
users can choose to ignore or be notified about events in certain 
locations. E.g. someone in Carlisle isn't interested in an event in 
Barrow-in-Furness, but wants to know about events in Carlisle and 
Wigton. It would be cool to hook this into post codes (more accessible 
than lat/long *grin*) and distances (e.g. events within 50 miles of my 
location), but I was under the impression those sorts of systems cost money.

Again, Events can be created by everyone (with an optional approval 
queue) or restricted to certain roles. This could be extended so that 
pre-defined locations (e.g. the room at Aspatria) would require the 
approval of the location owner before the event was published.

Library:
--------
Over time, any group builds a stock of material that can be used by it 
members (e.g. the Linux User & Developer Magazine subscription that was 
donated to us) or members may want to share items (e.g. Trevors 
'bag-o-distros' or my numerous O'Reilly books) with other members. The 
Library component will help facilitate this by a) keeping a record of 
what materials are available and b) tracking who currently has 
possession of individual items.

------------------

So, there it is. What do you think?

Hopefully you can see from that why I think merging separate tools, or 
building on top of an existing one might be impractical.

Cheers,
-- 
Schwuk - http://www.schwuk.com
Cumbria LUG - http://www.cumbria.lug.org.uk




More information about the Cumbria mailing list