Internetworkers: http://www.ibiblio.org/internetworkers/

["Alan MacHett" <machett AT ibiblio.org>]

More conceiving of the CommunityWebLogger (I have other ideas for names,
but that really isn't important now).  I'm skipping Michael's use cases
and jumping straight to a pseudo implementation flow chart.  It's a rough
draft and has some holes in it at points I haven't figured out yet.  It
might be overly complex or it might be too simple.  I expect harsh
criticism (because, as I've stated before, I probably don't know what I'm
talking about), so feel free to lay it on, or draw up an alternative plan.

Precondition:  Let's assume we've already figured out how to embed message
identifiers and promotion links into the INW archives.

(1) Would-be Editor visits archived message, clicks on promotion link, and...

(n) (potential step:  the embedded message id is compared to a database or
a series of files; the point of this will be explained later)

(2) ...is transfered to verification page.  "You have requested the
promotion of this message to article status.  If you wish to continue,
please enter your email address so that the author may respond," is
followed by a form entry field and a "Notify Author" button.
This page serves two potential purposes.  One, if we deem that only INWers
may promote articles, then this field could be used as a low-grade
password; only registered emails will pass.  Of course, someone could just
as easily pull an email address from the archives and use that, after
getting the "Sorry, you're not a member" alert.  They don't necessarily
have to get that alert though; all button clicks could result in
progression to the "Author Notified" page, but only registered INWers
actually get sent.  This option, if chosen, can be detailed later.  Two,
if we deem that Joe Anybody can promote a message, then we'll need to know
Joe's address to contact him and potentially include him in the editorial
process.  Regardless, we'll need a contact address.  This will become
apparant later in the flow.

(3) After clicking the "Notify Author" button, a canned message is sent to
the Author that "[email address] has requested that your message [link to
archive] be promoted to an article.  Do you give permission to do so?"
with "Yes" and "No" links (to CommunityWebLogger scripts).

(4)(a) If NO, then a canned message is sent to the would-be Editor and to
Inet-Announce that the request has been declined; would contain a link to
the archive for reference.  Additionally, if (n) above is invoked then
this is where it would be useful -- refer to (4)(c) below -- the embedded
message id is passed to a file/db for future reference.
(4)(b) If YES, then a canned message is sent to the would-be Editor and to
Inet-Announce that the request has been accepted; would contain a link to
the archive for reference.  Additionally, the body of the promoted message
is extracted and filed for editorial use.  (I assume this can be done
relatively easily.  I could be grossly incorrect.  My assumption is based
on another assumption -- that Mailman is database driven or that somehow
it can be accessed from an outside script.)  And again, if (n) above is
invoked then this is where it would be useful -- refer to (4)(c) below --
the embedded message id is passed to a file/db for future reference.
(4)(c) Some sort of database/file system should be kept to track the
status of "handled" messages in the INW archives.  Messages would have one
of two, three, or four states:
-1- Queried:  a temporary state to prevent the Author from receiving
multiple requests about the same archived message.  Upon clicking the
promotion link, the second and subsequent would-be Editors would see an
alert that someone else has already made the request.  Like the INW-only
security feature, this isn't exactly necessary, but might come in handy in
the future.
-2- Declined:  self-explanatory; subsequent would-be Editors would receive
an alert that the Author has declined to allow the message to become an
article.  The only question is whether the state is permanent.  Should the
status lapse after a specified period of time?  This would allow for the
possibility of a change of heart by the Author some time later if another
would-be Editor came along.
-3- Accepted:  also self-explanatory; could be further defined as In
Progress to clarify that a finished article has not been posted, giving
way to...
-4- Article:  denotes a completed project; would-be Editors would receive
an alert pointing them to the finished article.

(5) If YES, then the body of the archived message now resides in some
directory or database.  Editors go to some sort of interface to process
the text.  Yeah, here's my most glaring hole; I really don't know what
form this interface should take.  It could be a relatively simple ftp
process or it could be something more robust, like OmniEdit (
http://www.omniedit.com/demo.html ).  Depending on the latitude we want to
confer to Editors and Authors, they'll be able to manipulate either the
text only or the entire format of the finished Web page(s).  Or maybe
there's no interface at all; upon acceptance by the Author in (4)(b)
above, the extracted body of the archived message is forwarded to the
Editor for her and other Editors and the Author(s) to banter amongst
themselves and eventually email a Final Draft back to CommunityWebLogger
(but if we're going to go to all the trouble, we might as well have a
Nifty Interface).
Also, unless we want Author-Editors to have to go through all of the above
steps, something within the Nifty Interface should allow for rapid
publication.  An Author would go directly to the Nifty Interface, type up
her article, and click "Submit".
Like the embedded message ids and links, lets just assume for now that
this part is all figured out.

(6) The Editor(s) click on the "Submit to Author" button in the Nifty
Interface (or email the Final Draft back to CommunityWebLogger).  A canned
message is sent to the Author, either with the text attached or with a
link to the Final Draft, with links for "Continue Editing" or "Make It
So".

(7)(a) If NO, then a canned message is sent to the Editor(s) (either we've
held on to that originally entered email address or we've allowed for the
Nifty Interface to collect the addresses of Editors and associate them
with a particular Draft) informing them that the Author thinks the Draft
needs more polish.
(7)(b) If YES, then the Final Draft is passed to the INW Collection (or
INW Directory, depending on our ibiblio vs. Yahoo-Google bent).  If the
Nifty Interface allows total control, then a completed file is transferred
and its url added to the Collection/Directory Index.  If the Nifty
Interface allows only manipulation of text, then an include file is
transferred to a subdirectory and a url added to the Index; all
Collection/Directory pages would have the same format and would contain
the include file of any given article.  Additionally, a canned message
would be sent to Inet-Announce declaring that a new article [link to
Collection/Directory Article] has been added to the INW site.

(8) OR it all fails horribly and everyone blames Dave Matusiak for coming
up with the idea in the first place.  /wink/

I think that about covers it, glaring holes aside.  Tweak it as you see fit.

-Alan