[cumbria_lug] UserGroup...

[Adam Pigg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry, anything that supports mozilla only cant be a good thing.....think of 
the websites that are IE only!!!!

If textile is too complex then why not try the editor used in 
www.wikipedia.org? that of course means you'd have to use theie text 
rendering engine, but hey, its open source so just download it from 
wikipedia.sf.net

Other than that , it looks good!

now..off to check that timetravel modified delorean on ebay :)

C ya



On Wednesday 21 April 2004 19:22, Schwuk wrote:
> 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,

- -- 
adam at piggz.co.uk
www.piggz.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAiCj3zhQHWK5JlQ8RAtFWAKDdEEE8Wms9IBKnpVn3ZWuqry02bgCfQ7a0
1JXgxLR1pabbNHQQHOSuN5Y=
=w8AO
-----END PGP SIGNATURE-----