10.10.10 The bboard system must provide mechanism for users to effectively choose which messages to read within a forum. Bboard must provide an overview interface to enable users to find messages of interest or relevant to them. This overview should provide the user with cursory information to facilitate quick scanning and meaningful evaluation of message contents. 10.10.15 The full text of bboard messages should be searchable by user queries. 10.10.20 [unimplemented] Bboard should consistently provide a mechanism to limit or sort displayed posts by categories, posters, and date range as well as to perform a text search. 10.10.30 [unimplemented] Most users primarily want to browse and read new posts or replies since their last visit. The bboard interface must allow users to ignore messages they've already read. 10.10.40 [unimplemented] Users should be able to search within and limit scope to messages they have already read as well as messages they have not read at all. 10.10.50 Users must be able to easily post new messages to a bboard, or reply to existing messages they have come across. When replying, users must be presenting with enough context to assist their composition.

10.20.10 Users can register for email notification of new messages in a particular forums. 10.20.13 Users can register for email notifications on a particular thread. 10.20.16 Users can register for email notifications on a particular category. 10.20.20 [unimplemented] Notifications can be sent as each message arrives or in an organized digest form over a configurable time period. 10.20.30 Individual messages will have appropriate RFC 822 headers to enable threading in the mail client. 10.20.40 [unimplemented] Email from the alert system should be tagged in the header with the site and forum name to enable easy filtering in mail clients. Well, as easy as the mail clients make it anyway. 10.20.50 [unimplemented] If the user requests it, email generated should use MIME encoding to deliver attachments and appropriately encode HTML. Otherwise plain text emails should be augmented with URLs and styling cues in place of rich content.

10.30.10 The bboard system must support a flexible presentation layer that allows custom layout of bboard content. 10.30.15 Publishers should have the option of displaying discussions in a flat linear fashion or in an indented threaded view. 10.30.20 Parties with administrative privileges on a particular subsite can create, delete, and edit forums scoped to that subsite. 10.30.30 Forums can be designated moderated in which case parties with sufficient privileges must approve messages before they are displayed generally.

Objects must be structured to allow the flexible configuration and assignment of the following privileges: 10.40.10 Reading forums 10.40.20 Reading messages 10.40.30 Posting new messages 10.40.50 Approving and rejecting posted messages (for moderated groups) 10.40.60 Managing the forum (editing title and description, determining moderation and restriction policies, granting approval privileges to others, banning users) 10.40.70 Managing categories (editing, deleting, combining categories)

20.10.10 Messages are the basic units of the bboard module. The bboard system will provide a repository to store text messages. 20.10.20 Messages will be tagged as having HTML, plain text, or preformatted text in their body. 20.10.30 Messages will have a brief plain text subject line. 20.10.40 Messages will be related to their creating user. 20.10.50 Messages may optionally have binary attachments. 20.10.60 The bboard system must store relations between messages and their replies to enable threaded views.

20.20.10 Forums are the main administrative units of the bboard system. Forums are containers to which messages uniquely belong. 20.20.20 Forums must have a brief text descriptions and optionally a longer description called a charter.

20.30.10 There must be a mechanism for intra-forum categorization to facilitate filter, searching, and tractability.

40.10.10 bboard should provide a framework for extending the generic messaging repository with meta-data and in tandem extending the user interface to take advantage of this meta-data. This would let developers properly layer functionality such as geo-spatial messaging and slashdot style scoring. This is actually provided via ACS messaging and the ACS Object system. 40.10.20 bboard should support replying to and initiating threads from email. Administrative email list functionality should be developed or integrated. 40.10.30 Bboard should let users register interests (categories, certain users, keywords) for the purpose of filtering and sorting message displays. 40.10.40 Users should have the option of enabling spell checking on their posts. A framework for filtering (removing bad words, promoting text URLs to html links, auto detecting HTML vs. plain text, etc.,) should exist. 40.10.50 Allow users to configure how big the textareas editing widgets they get are. 40.10.60 Moderators should be given the option of making notes on a given discussion that appear prominently in the discussion display. 40.10.70 Moderators should be able to set posts to expire at a configurable time in the future. 40.10.80 Mega bonus points: an nntp gateway to bboards for access from standard news clients. 40.10.90 The bboard system should be able to take advantage of a caching system that stores the results of database queries for optimal scalability. 40.10.100 Publishers should have the option of allowing users to edit various parts of messages after they are posted (e.g. the text body, the subject, the text presentaiton style etc.,) 40.10.110 A user interface should allow administrators to easily categorize or recategorize existing messages. 40.10.120 Publishers should be able to classify users based on their forum contributions and appropriately target them for email, promotions, etc., 40.10.130 Explicit permissions for posting new messages vs. posting replies. 40.10.140 Explicit permissions for posting attachments.