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

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

> I think some rearrangement is needed of Michael's steps involved.
"Once
> an email is promoted, it is now an article," should be something like,
> "Once an email is promoted, it is now in the permissions stage."  The
> process might be:
> 1) promotion of email/article (by the author or would-be editor)
> 2) acceptance or rejection by author (assumed "Yes" if author promoted
it)
> 3) editing (by volunteers)
> 4) publishing to website

Cool... I'm going to add one more step:

1) promotion of email/article (by the author or would-be editor)
2) initial acceptance or rejection by author (assumed "Yes" if author
promoted it)
3) editing (by volunteers ## or original author
4) final author review
4) publishing to website

(Notice that I added that the original author can edit.)

2 and/or 4 could be configured to be automatic on an author-by-author
basis.

Cool... To get the semantics down, you can imagine that the email
changes form as it moves through the process -- kinda like a butterfly.

At first, it is email.
After promotion, it is a Proposed Article.
After initial author acceptance, it is a Working Article.
After editing, it is an Edited Article.
After final author acceptance, it is a Reviewed Article.
After publishing, it is a Published Article.

A published article can also have different states, such as active,
inactive, etc. Also, if an article is rejected, is it deleted or does it
just become a Rejected Article? However, I think we can wait a while
before worrying about those.

This is a simple workflow system with only one loop and a small number
of states. It should be easy to model on both the database and object
level.

> I think steps 1 and 4 should be automated.  The discussion list
archives
> already exist.  A "promote" link/button could be added to the page of
each
> read message (assuming the staff at ibiblio will accomodate this;
assuming
> it can be done with/around pipermail).  Upon clicking, the message or
a
> summary or a link back to the message would be remailed to the list
with
> an altered subject line ("[Promote]"), allowing the author and
would-be
> editors to respond on or off list.  If it is unobtrusive, then the
> promotion could also be done directly from the original message on the
> list, as in Michael's idea.  Then the editors do their thing.
Finally,
> through an interface on the INW site, the finished article is
submitted
> for publication in the correct category of the directory.

Great thoughts!! I really like the picture that you are drawing.

Rather than comment on the technical architecture at this point, I just
want to point out where we are in the systems development process. We
are analyzing the available technology. I'd also like to say that Alan
has a very good sense of the system requirements. From a software
methodology standpoint, we're playing a strong game. 

Now, I see the following different building blocks that can be employed.
I'm sure I'm missing some. Please add/modify. And have fun -- this is
where we get to do the lateral thinking and invent!

1) Archives gateway -- Some code that can read the archives and present
messages to an editor. The editor can select a message to promote, at
which point it would be copied out of the archives in to the working
area. 
2) Archiver extension -- This is what Alan is suggesting above. Editors
go to the archives and start the process there.
3) Mailman message id embedder -- Something to extend Mailman and embed
a unique id in the footer of each outgoing message. This would allow us
to close the loop. The user could click on a link and then
promote/edit/publish the message. Though this would be nice, I'm not
sure how realistic it is.
3) INW Mailbot Subscriber -- We can subscribe a program to the
InterNetWorkers list. The Mailbot could also receive messages and start
the promote/edit/publish process. I.e., an editor forwards a message to
the mailbot and this starts the process.
4) INW Mailbot Language Processor -- For self-publishing, you can embed
directives in the email itself. Then the entire process is automatic.
When the mailbot receives the message, it just moves it through all of
the steps. This is great for self-published "Check this link" messages.
I've already designed this language model. I'm just waiting for someone
to be interested in it ;-)
5) Workflow manager -- This is the piece that changes the state of
Articles and notifies editors/authors that an article state has changed.
It is also the code that publishes articles. It has a db backend.
6) Other app code -- There are other things the system needs to do, like
manage users, manage topics, etc. 

Anyway, those are some of the basic pieces that we can play with. I
think that the Archives gateway may be the simplest/lowest cost
mechanism... It doesn't have that closed loop elegance and makes the
editor work harder to get the process started, but it can get the job
done. The INW Mailbot and INW Mailbot Language Processor can make it
extremely easy to self-publish and might be useful to editors also.

But as discussed, cost-benefit analysis is done by those that would like
to spend their time and energy on the problem....

Anyway, let's kick around some more ideas and do some more research and
see where they take us.... 
 
> I foresee a few problems.  It's possible that we'll end up seeing the
same
> "editorial board" over and over again.  That is not necessarily a bad
> thing, but some people might object.  Also, should review be required?
> Meaning, should an author be allowed to publish to the directory
without
> peer review, or should editing be a required step?  We could perhaps
allow
> that, if no one chooses to edit the article, then it may automatically
go
> to publishing.

First, I don't see any reason that a person shouldn't be able to
self-publish all the way through the process. If anyone can be an author
and anyone can be an editor, why not? However, we may need to come up
with some policy guidelines -- no spam, nothing entirely commercial,
etc. -- and then enforce the policy somehow. "But I want to see policy,
not autocracy," he said tyrannically.

Now, let's step back a minute.... the problem isn't that the content on
the web site isn't polished. The problem is that we get new content very
infrequently! I'd like to get a system set up so that we get new content
more often than once a year. Really, if we end up with the problem that
*way* too many people are putting stuff on the web site, then we've
succeeded. Then we deal with that problem then -- not now.

I see this whole project as more Wiki than New York Times. I don't see
editors as police or guardians but rather enablers. Also, I don't think
that we have to worry about making the content really crisp and
polished. I think we just get it out there... frequency of new content
is important.

To me, the editing step is largely mechanical as far as preparing
content. The most important piece is that someone made the decision to
start the process -- to promote. I don't want to see a situation where
an editor goes "This is great! Now, you need to do 6 hours of work
before you can publish...." That's ridiculous. The most important part
is that someone says "That's great!" At that point, it's really up to
the author to decide what they want out on the site. It's their name
that will be attached to it, after all.

(On that note, we should explore anonymous and aliased authorship.)

Ideally, we'd have a lot of frequent content -- like Fark or Slashdot --
along with some highly polished content, like a widely read
authoritative tutorial that is highly ranked on Google. 

> Wishful thinking:  Assuming this goes well and a sizeable directory
> becomes established, then perhaps it, or the INW site as a whole,
could be
> (re)submitted to the ibiblio Collections Index.

Sounds great to me!!