To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.admin.generalOpen lugnet.admin.general in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Administrative / General / 10968
10967  |  10969
Subject: 
Unifying LUGNET user types
Newsgroups: 
lugnet.announce, lugnet.admin.general
Followup-To: 
lugnet.admin.general
Date: 
Fri, 9 May 2003 02:55:09 GMT
Highlighted: 
!! (details)
Viewed: 
87 times
  
All,

We're going to begin soon unifying the many types of LUGNET users into
a single, coherent base system.  This will greatly simplify sign-up,
configuration, and daily usage, and consequently I think this will make
a lot of people very, very happy once it is complete.

A lot of LUGNET over the past 5 years has "evolved" or grown organically
in ways which we didn't expect or didn't take pains to do right the first
time.

The biggest example is news-posting.  Originally, in 1997, we had planned
to implement a pure web-based discussion group system, _after_ implementing
a complete membership system.

When we introduced the NNTP-based newsgroups in 1998, we had no formal
membership system in place, nor did we forsee at the time that we would
need to provide (a) a sign-up procedure to weed out spammers and other
issues that quickly arose from allowing free-form From lines, (b) e-mail
gateways to the newsgroups, (c) e-mail authentication on posting, and (d)
eventually links to member pages/profiles from articles.

Thus we find ourselves now with five major classes of "accounts" on LUGNET:

1.  The super-casual user.  Never gets a cookie or anything, just uses the
website to look stuff up and lurk or do whatever.  [Not really an account,
but a class of user.]

2.  The casual users -- takes a cookie or two for things like the Newsgroup
Skip-Filter[1] or other minor web interface customization.  [The "account"
here is merely a cookie.]

3.  The News-by-Mail subscriber -- their "account" is (a) a small database
record based off their e-mail address and contains information about what
groups they are subscribed to, and (b) a cookie in their web browser which
remembers their e-mail address and confirmation code.

4.  The news-posting user -- their "account" is (a) a small database record
based off their e-mail address and contains information about their name,
their e-mail address, and optionally what groups they're allowed to post to,
and (b) a cookie in their web browser which remembers their name and e-mail
address.

5.  The lifetime member -- their account is a medium-sized database record
based off their member id and contains their member profile and other
goodies.  Member pages, set collection, and other things are stored in
additional databases.

To make things stranger yet, if a person of type 5 is signed in, and they
modify their type 3 or type 4 settings, a "virtual cookie" is stored in
their member record instead of sent to their browser.  This is how the
server knows your news-posting information when you're a type 5 signed in.

Sure, this _works_, but it is terribly and awfully confusing.  For example,
why does the server only let you use one of your e-mail addresses at a time?
Why should you have to fill out the News-Posting Setup Form every time you
want to switch between two e-mail addresses?  (A number of people do this,
some daily.)

The answer is because the current system is all mucked up.

The good news is that we're going to fix it.

Here's the plan:

We're going to move all of these things (user types 2-5) under a single
roof and call all these users "members."  There will then be two subtypes
of members:  Basic members and full members.

Basic members have blue eyes, and full members have brown eyes.

No, just kidding.

Basic members are essentially the current user types 2-4 and full members
are the current user type 5.  So:

Basic members (free) will be able to:

* get a member account -- a member number and password (one per person[1],
  which we'll enforce as strictly and vigilantly as we can) -- and with
  this they may:
     * sign in / sign out on the web interface
     * change their password, etc.
     * authenticate their id for other sites

* add and remove multiple e-mail addresses, each of which the server will
  validate by sending a confirmation e-mail.

* post to newsgroups -- and this includes:
     * configuration of skip-filter settings
     * on-the-fly choice of e-mail address (if you post from more than one)
       in a drop-down box

* subscribe to newsgroups via e-mail, as mailing lists

* have a member profile page, just like we have now for current members

* have a name/website listing in the member directory

* contribute data to database(s) via addition/change request form [future]

* vote in polls (hello Anders)

* post to private discussion groups [future]

* buy sets and bid in auctions [future]

Full members (fee) will be able to do everything that basic members can do,
plus the following:

* maintain a personal set listing and related features

* do enhanced newsgroup browsing [future], including:
     * store articles in arbitrary named folders[3]
     * tracking of read articles across browsers

* be a group curator

* create hosted pages

* create new polls

* create a private discussion groups [future]

* sell sets and run auctions [future], and specify criteria about what kinds
  of buyers to allow (all members, full members only, over-18 only, etc.)

* be a club contact and submit/manage club event information to the map/event
  database [nearer future]

This is _somewhat_ subject to change, but this is the current plan.  We
haven't decided yet, for example, whether all members or only full members
should get a square on the community virtual town map[2].  And it isn't
set in stone that there will always be only two types of members (basic/
full), but it seems like a perfect way to start and it can adapt as needed
without breaking the paradigm.

--Todd

[1] brainstem, meat-puppet, or a politically correct term of your choice.

[2] http://www.lugnet.com/admin/plan/map/

[3] didja ever notice that the new Spotlight function we put up last August
uses 'folder' in the CGI script name?
   http://news.lugnet.com/folder.cgi?f=Spotlight/lugnet
What I implemented was a _folder system_ for news articles, and the Spotlight
is merely a special case.  :)



1 Message in This Thread:

Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR