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

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

> Firstly: Steve, thankyou! Michael, thank you!  Both of you; I get it.


Thanks for asking, Alan! It was nice to have a technology topic.

> Secondly and Lastly:  I really and truly like Dave Matusiak's idea.
I've
> always entertained the notion that the INW site should evolve into a
> repository of information ... 

This is an idea that I've been tossing around for about a year now. I'll
go ahead and present the idea for discussion.

:::Goal::: 

* There's a lot of great content that is generated for the INW list.
* Some of it may be of interest to a wider audience -- i.e., those who
aren't subscribed or would not subscribe to the INW list.
* This is a classic signal-to-noise ratio problem.
* How about we set up a streamlined, automated process for promoting
interesting list material and publishing it to the web site? With a
minimum of effort on the part of the authors, stuff that is already
being generated for the list can also be published on the web site.

:::Problems:::

* Technical: let's not worry about those just yet.
* Permissions: The original author -- who ever does the post -- must
agree that their content can be published (The other way to think about
it is to consider that any content posted to the list somehow becomes
the property of INW. I don't think we want to go there.) One of the
trickier problems is where one author replies to another. Do you have to
get permissions from both?
* Popularity/Purpose: "Will the system get used? Will people put info in
to the repository? Will people read the repository? Is it a good use of
the INW treasury?" First, there is no INW treasury. Secondly, I've
written lots of programs that never get used b/c they were just learning
efforts. As with everything that we've created for INW, I think the key
is to take joy in the act of creation and to hope that it will get used.
I don't think that standard cost-benefit analysis applies. The "cost" is
the time and energies of volunteers that are working on the project, and
the "benefit" is whatever the volunteers get out of the experience. The
benefit to the community is secondary -- as long as it isn't
detrimental. Part of the management of the project is setting the
expectations of cost and benefit correctly and to make it easy for
people to enter and exit the project as they wish.
* Cultural: Over the years, I've found that most any suggested
augmentation of INW will face the criticism that it will break lots of
things that are good about INW and that, generally, changes to INW are
bad. I'm an optimist -- I think we could create a repository without
adversely affecting Triangle InterNetWorkers. The cultural debate will
come, so let's go ahead and start it.
* Precedence. I'm sure that others have tried a similar scheme and
failed. That doesn't necessarily mean that we will. Let's learn from
previous mistakes. 
* Classification: To really be a repository, we need to classify the
content. The best time to do this is when it goes in. On the web site,
you could then choose topics by subject (such as Database, Web Design,
Politics, General Rant, etc.)
* Editing: There will probably need to be an editing step for most
articles to make them good web content. We'll need to strip out '>' and
do deeper modifications.
* Usability & Learnability. The system needs to be easy to learn and
easy to use.

:::Solutions:::

Here are basic requirements:

* The permission scheme is very, very important! There are two ways to
think about permissions: opt-in and opt-out. I think that the author has
to opt-in on a per post/article basis. Beyond that you can have
convenience mechanisms -- "I'll just opt-in for all posts so I don't
have to opt-in on a per article basis."
* The work of selecting and editing content is distributed. I.e., I
don't think that there should be one editor. I think that anyone should
be able to act as an editor. Anyone should be able to read a post, say
"hey, this should be on the web site!" and start the process of getting
it there. Also, people can edit and promote their own posts.
* There are three key steps: promoting, editing and publishing. 
   - Promoting means that an editor likes an email and would like to see
it published. Once an email is promoted, it is now an article.
   - Editing is the act of getting the article ready for publishing.
   - Publishing is the final act of making the article available on the
web site.
* An editor should be able to promote and edit an email very easily.
They should be able to start the process by clicking on a link inside of
the email and then navigate a simple interface for the purpose of
editing.
* An author who has had his email promoted should be able to easily give
(or decline) permission for the article to be published.
* The system should support a way that authors can declare the title and
topics of their post. I envision that a lot of the content would be of
the "Hey, check out this link" variety. By using some really simple
markup, the authors of such "here's a link" messages could:
   - Declare that they are submitting the post to the web site (i.e.,
self-editing).
   - Specify a title for their article. (The title could also be derived
from the title of the web page that is pointed to.) For "here's a link"
messages the body of the article would be very brief. It would be most
like www.fark.com.
   - Declare the topics for the article.
I think that all of these goals could be achieved in a way that wouldn't
be overly obtrusive to those reading the emails from the list. In fact,
the added structure could even improve the readability of messages.

Thoughts?