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

["Michael D. Thomas" <mdthomas AT mindspring.com>]

> More conceiving of the CommunityWebLogger (I have other ideas for
names,
> but that really isn't important now). 

Let's hear 'em!

 I'm skipping Michael's use cases
> and jumping straight to a pseudo implementation flow chart.  

Depth first, cool. We're still in the requirements/design phase, which
is where I'd like us to hang out for a bit... esp. on the more
complicated pieces.

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

Or... we've decided that it's not too much to ask that an editor to pull
a message out of a list instead of just clicking a link embedded in the
message. In fact, maybe it's even better that way... a little barrier to
entry...


> 
> (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,

More direct answer: don't worry too much about authentication/privilege
issues if you don't want to. I've got a good handle on it and have
solved such issues multiple times on bigger systems than this. That
said, if this is the kind of problem that rocks your boat, carry on.
Let's all have fun...

More technical answer: Assigning privilege levels to functionality is
fundamental to good system design. The question is one of granularity
vs. cost. The finer grained your privileges the more complex and costly
it makes the rest of your systems development. For a system like this, a
good granularity is at the screen level. I.e., you define a privilege
for each screen in the system. For any screen, it is up to the
administrator to turn privileges on or off. If the PromoteArticle
privilege is turned on and an anonymous user tries to access that
screen, they must authenticate. 

This general authentication flow is true for any screen in the system --
you could even lock down the home page if you'd like.

Make sense?


> 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.

This is a good weak authentication scheme -- what I'd rather call
"usable." The best authentication is biometrics but that is much less
usable. Requiring fingerprints would probably discourage most of our
editors, as would requiring passwords. I studied the problems of
authentication vs. usability when I was looking at the INW survey stuff
a couple of years ago:

http://www.ibiblio.org/internetworkers/survey/SurveyFuncSpec.html

(BTW, I reached the obvious conclusion that a voting system /MUST/ be
open source -- free as in "free speech." Another topic...

> 
> (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).

This assumes that we can send the author HTML email.... We definitely
want to if we can. We may have to record a preference for each author
and then make a guess about what is appropriate for the default.

> 
> (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; 

Oh, ummm, not Inet-announce. That's our low volume broadcast only
list... Maybe inw-editors or some such...

> 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.  

Instead of going to the archives, you deal with a special message
datastore tuned to this purpose.

If we have a mailbot subscribed to the list, it can have its own copy of
each email. As the mailbot receives emails, it can process them into
some kind of structured format. If the emails are marked up in the
proposed CommunityWebLogger Meta-Markup Language (CWLMML), then it can
process those instructions at the same time. 

It's usually easier to structure data in the first place rather than
deal with semi-structured data at query time.


(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:

The mailbot would feed the datastore. The datastore would be part
relational and part text (or possibly XML) storage. (The text (or XML)
could be stored inside of the relational database, but I would still
consider it different than the structured data.)

> -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.

Nice catch! Don't want to spam the valued authors...

> -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.

Very nice workflow! I'm down on workflow right now, so I'm going to
suggest another way to think about it -- imagine that a Post (or
Article) is an object with these various mutually exclusive states. Each
time the state is changed, interested parties are notified. They can
then go visit an editor for the object.... I'm showing my design
patterns orientation here. To me, this makes the problem simpler...
should I reference some design patterns?

> 
> (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).

Yeah, I think you consider the article as an object that has various
states and has an editor. This gives you the most flexibility. Then the
administrator can require privileges to change states (see earlier
example) or possibly forbid certain state transitions (maybe you forbid
an article from going to an unpublished state; it can only go to deleted
after being published, much as food in a restaurant can only go to the
trash after being served...)

> 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.

The markup language that I discussed in an earlier post takes care of
the "self-publishing" use case. We can also provide a "self-publishing"
web interface. The more I think about it, the more I think that
self-publishing is the big bang/little buck use case.

> 
> (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.

I'm going to harp on my object/state idea again and diss the concept of
workflow. In this workflow, 6 and 7 could go back and forth multiple
times. It's easier to implement that with an object/state paradigm than
a workflow paradigm....

But then, I'm not exactly sitting down to implement it right now either.
As discussed before, it is the implementers that decided the
implementation.

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

Yeah, I'm about tired of him and all of his crazy ideas.