Tunes webpage suggestions...

David Jeske
Mon, 4 Jan 1999 01:23:42 -0800

I originally wrote this as a private email to Pat, but it may be of
interest to others..

----- Forwarded message from David Jeske <> -----

Date: Sat, 2 Jan 1999 19:35:34 -0800
From: David Jeske <>
To: Pat Wendorf <>
Subject: Re: New Project Coordinator Introduction
X-Mailer: Mutt 0.94.13i

Hello Pat,

On Thu, Dec 31, 1998 at 12:48:53AM -0500, Pat Wendorf wrote:
> I'd like to start by introducing myself.  I am the current
> project coordinator for the UniOS project (URL listed below), and
> now the new project coordinator for Tunes.  The caretakers for
> this project (Fare, and Tril) have found the need for someone to
> fill this position, as the project has never had a real
> coordinator.

I agree. I'm glad to see someone ready to coordinate the Tunes
project. It needs much coordination. :) Welcome aboard.

> One question you might ask is: Why would someone, who is the
> coordinator of another project want to help with Tunes?  The
> answer is complex, but it comes down to a sharing of ideas and
> people for both projects, and the fact that both projects have
> similar goals.  I have not, by far, given up on the UniOS
> project,  I believe this move makes the UniOS project stronger,
> as well as Tunes.

>From reading the unios pages, I believe the philosophies/goals of the
projects are certainly similar if not the same. I really like that the
UniOS pages are structured into discrete papers. The Tunes web pages
are woefully out of date. Too often information on Tunes is
communicated in a string of disconnected email, and never put together
into a more formalized paper which can be understood as an atom and
debated or expanded on.

> My job for the time being, is to hear what you think is wrong or
> right with Tunes, and how we can make it better.  As the
> coordinator, I have already started looking into
> changing/simplfying one aspect of the project: The web page.  

Please. If you get any resistance, point me at them and I'll cure them
of their negativity. :)

> The web page is the public face of the Tunes project.  The first
> thing anyone who stumbles upon the project will see, is probably
>  What I propose is a simplification of the layout and
> possibly the information presented.  This of course is a huge
> undertaking, but I have taken the liberty of getting some web page
> professionals to asses the current page, and give feedback on what
> can be done.

Unfortunatly, I think there almost nothing 'right' about the current
layout. The 'old' project research is organized better, but very out
of date. All recent research and thoughts are (from what I can tell)
mostly absent from the webpage.

Encouraging people on the list to summarize their ideas into
"documents" style articles would be a good step. Having someone sift
through the mailing list archives and summarize key points might be
another good step, but much more daunting. There is definetly a gold
mine of stuff, but it's also buries with alot of jibberish. :)


Here are some of my first thoughts about restructuring the webpage,
consider them as such, and I'll let you know if I have any better

1) Start with an empty page which more closely resembles the UniOS
project page. 

2) Make a concise, no more than a few page, description of the Tunes
Goals, much like the UniOS project goals. The original Tunes position
paper is a bit long, but will be a good source of information. I think
Tunes has a somewhat more ambitious set of goals than UniOS, so it may
be harder to keep this concise. There are at least a few good "what
tunes is about" posts on the mailing list which would be a good source
of concise descriptions. I can try to find them for you.

3) make a document list which is similar to the UniOS documents
page. However, I believe there should be both a 'date ordered' list
and a 'relation ordered' list. For example, there are so many opinions
expressed about tunes over the years that it would be most useful if
papers were divided up into some kind of heirarchy. However, we don't
want recent documents to be lost in the pile. This is what was
attempted back in the old Tunes research pages days, and also again
with the more recent Tunes wiki WWW server. However, it's not very
well maintained.

4) Come up with a fairly standard format for the documents. For
example, each document should clearly state what it is trying to
prove. It should clearly list at least one example of that problem in
existing software. It should clearly list at least one example of a
solution which follows the paper's suggestion (if possible). It should
explain the context in which the proposal is going to be explained
(i.e. are we going to illustrate with a UNIX/C example, or an example
in some hypothetical Tunes or UniOS world? -- which should be
described in some other paper). Finally, it should explain the
proposal itself. I'm beginning to feel like a third grade english
teacher, but I think this would make the quality of the Tunes
information far better.

Perhaps there should be different 'types' of papers. For example, the
papers which review existing languages, or existing OSs, might not
follow the same format as a position paper about a future Tunes/UniOS
feature implementation. However, I would hope having a more rigid
format would help Tunes members solidify their ideas into something
more comprehensible to the rest of the world.

5) People should sift through the old Tunes "review subproject"
information and structure it into the new format. I will help with this.

6) People should sift through mailing list archives, and write, or
encourage the original authors to write, papers about the ideas

7) We should have a page which has a similar heirarchy with papers,
web-pages, and downloadable files, about different peoples attempts to
implementat projects or related ideas. This will encourage
implementation, because there will be a place to showcase it, and it
will encourage _explaining_ an implementation, because presumably
people will look at them.

8) it would be outstanding if someone (yourself, or everyone in
concert) could help come up with 'monthly minutes' which describe what
has been talked about in the last month. This could make up a slashdot
set of 'blurbs' about recent happenings on the mailing list. 

9) it would be best if all this information was stored in some
database/datastore, and not just manually maintained, so that it could
be searched and so that all information will always be available. I
can also help with this if it's needed.

David Jeske (N9LCA) + +

----- End forwarded message -----

David Jeske (N9LCA) + +