Bursting in [was: Maude licensed under GPL, 2.0 approaching...]

[Tril]

> I ended up writing the same old post that everyone else seems to have
> written at one time or another, but I promise I will not write anything
> like it again. 

Thanks for your comments about the project.  I don't think at all that
they were "the same" as any other post; rather, they were quite 
insightful.

On Sat, Jun 14, 2003 at 04:36:52PM -0700, Felix Holmgren wrote:
> 1) About the discussion on how to educate newbies: the stuff you're
> involved in is advanced enough that no-one who's not thoroughly
> motivated will get even halfways to understanding the issues at hand. To
> people who have that kind of interest, it will matter little whether
> there is some kind of curriculum, complete with exercises and projects,
> or not, since they will be the kind of people who find their own way of
> learning anyway. The wealth of information and links on the Tunes sites
> is a really great resource in itself for someone who wants to get into
> this kind of work. I think it's better to concentrate on expanding this
> (with an increasingly clear focus on the particulars of the project)
> instead of trying to tap into the psychology of a stereotypical Newbie.

Yes, expanding and organizing the existing information is what newbies
want.  I've recevied a complaint that Learning Lounge is rather
foreboding and it's hard to tell where to start, and another one that
says the navigation in the main site needs work.  These are useful
comments.  The problem is, these are exactly the kind of tasks that
newbies could accomplish and I think that they want to accomplish and
why they are so upset that we don't welcome them more.  I'd really love 
to delegate maintenance of the website away from me or water and toward 
someone who is currently unable to write TUNES-related code.

> However, as the specs and code get more concrete (which I hope they will
> soon) it's of cource crucial to document everything really well, so that
> people who might not be able to contribute much in terms of mathematical
> foundations for the project can start contributing in implementing basic
> algorithms, building libraries, etc. (I know the old argument that
> someone who only knows about writing database queries or whatever can't
> contribute anything anyway, but there *are* a lot of people between
> these two poles who might be able to contribute a lot once it's clear
> what's to be done.)

I hear this "document everything really well."  I've heard it from 
water, who told me to document Max really well.  I'm working on that 
presently: I'm switching my source files from .lsp to .nw (noweb), a 
literate programming system (see 
http://cliki.tunes.org/Literate%20Programming )
There will be as much detail as you could want about Max and its
implementation.

Stuff about attributes snipped.  I'm not interested in discussing them 
right now.

> B) How can there really be any uncertainty about the Tunes definition of
> "object" at this point? The pre-pre-draft spec that Brian published was
> a great step forward, but where is all the background material? The
> stuff on the web page and cliki doesn't come near giving a background
> for understanding what kind of decisions and considerations were
> involved in writing the draft. Maybe I'm being ignorant about the unique
> Tunes approach towards collaboration, but it seems to me (as it has to
> many before me) that the time is ripe to simply set up a priority list
> of issues to be decided upon (if only temporarily, and to see what
> different takes there might be), and make a first test specification of
> the basic system. That would make it possible for people like me (who
> have some basic idea of what is to be accomplished, but not about at
> which points the process is halting, and exactly why) to contribute in a
> systematic way, not only by writing code, but also in working out the
> conceptual problems once they have been clearly identified. Right now,
> it's hard to get an idea about what is commonly agreed upon
> Tunes-wisdom, and what is completely up in the air.

Yes, we know.  We're trying.

> 3)
> >> This could be a god news for this project: are we gradually
> approaching a
> >> shared agreement about Maude as good platform to bootstrapping (at
> least
> >> some aspects of) Tunes?
> >Check the posts from 2 years ago- people were talking about this then.
> >Alexis.
> Don't get me depressed. I can't see how anything more than Maude 2
> (implementing something like BMaude) should be necessary to implement
> the basic interfaces and protocols. Also, the concepts (although they
> are hard to extract from the Tunes sites) are not too unclear. It would
> be great if some insider right now stated why the project is not moving
> much: is it because of theoretical/conceptual problems or because of
> administrative/cooperative problems? If the former, which concepts need
> to be refined and decided on first? If the latter, what is the least
> common ground shared? What is the basic point of divergence?

Why TUNES is not "moving much": lack of time, and lack of people who are 
spending it on the project.

Here's what needs to be done on the project from what I can tell:

* Some feedback on water's specs (I've seen very little feedback.  I'm
also guilty of not giving any myself. Ok, now I put it high on my todo
list)

* Cliki expansion.  This is happening slowly, but anyone is welcome to 
increase it.  Contact water@tunes.org for the lists of stuff that needs 
to be fed into the cliki.  There's lists of infobot stuff, and lists of 
old TunesWiki stuff that just need to be gone through, as far as I know.
And you can always go through the Review list archives for more links 
that are not added.

* For me, continuing to work on Max.  It's progressing gradually and so 
far is not posing any brick walls.  I'm making Max to develop my own 
ideas for a framework for TUNES.  Note, that I am not claiming Max is 
going to be used in TUNES because I don't know if it will be suitable 
yet.  I'd rather someone else looked at it after it's released, and 
said, yeah that's what we want.  Until that happens with my code or 
someone else's code I don't think TUNES should have an implementation.
I encourage people to write their own prototypes or modify existing 
systems to explore TUNES ideas and understand them better.

* More feedback on the website - why it is unclear, what could be 
changed, etc.

* As usual, people to look for stuff to accomplish and then volunteer to 
accomplish it.  This includes people who want to be leaders of any sort.  
I seem to be listed under the root subproject as a head maintainer along 
with Fare.  Hadn't even noticed that there until now.  So ah, the 
maintainership of the root project is also open for volunteers even 
though it appears to be filled.  Fare and I just don't have incredible 
amounts of time.

> If all the knowledge and good judgement you people have
> aquired over the years could be communicated just a little more
> efficiently, I'm pretty sure no-one would have to write this kind of
> post again.

Yes, improved communication skills are also needed; we're working on it.
Thanks.

> Okay, whatever happens: thanks for everything so far.

Thanks for writing!

-- 
Tril 0. Byte <tril@tunes.org> http://tril.tunes.org/ 
PGP key fingerprint: DADB ED32 6E54 80D0 7E69  7549 C3A3 446F CAA4 66C0
This message is placed in the public domain.