Marielle Lange mlange at
Wed Oct 26 17:07:30 EDT 2005

Hi Jonathan,

> That particular site does indeed allow both style sheet control and an
> easy download of all the page material in one shot.

Jonathan... I believe this is more complex than this. See the  
excellent points made by David.

What is that this wiki can bring as benefits that this mailing list  
doesn't? Easy answer:  searching facilities. Relevant contexts (the  
very very precious "See also" section). But this is already provided  
for in the revdoc that comes in your rev package.

> I really believe that getting people to use it would not be too  
> difficult. It would become a natural process - one that extends  
> from discussions on this list.

Not sure this is true. What is the major hurdle for the success of  
this wiki? Emails arrive in the mailbox. To answer them, you click  
reply, type a bit of text, and you are done.

What would be the motivation to open a browser window, connect to the  
wiki, login, add a bit of text, go back to the email and reply "your  
answer is now on the revdocs website".

The very honest answer I can give for myself: no motivation **at  
all**. I may contribute to your wiki for a week or two (not even sure  
about that), but after that, I will just stop doing it. And I am a  
person keen to help... so what to expect from the ones who are even  
less than me?!

> So, if we want out own domain name - that would not be the site.

I really don't want to dampen your enthusiasm. On the contrary, I am  
very much interested in your proposal to help. But hosting is not how  
you can help best. Your wiki, my wiki, another wiki, this is not  
important. With admin access, you can help take care of this wherever  
it is, so can I, so can Tim and Dennis (great... in terms of numbers,  
this is should be enough to get it off the ground). A domain name can  
be moved from one server to another. With php, mysql, metadata, the  
content of a wiki can easily be moved from one server to another.

As long as we don't have an adequate infrastructure, putting doc on  
the wiki is very dangerous because this defacto gets you create a  
service... this defacto gives you the full responsibility for the  
good running, present and future of this service. Not that I suggest  
you made an error, Jonathan. That was great... thanks for taking the  
time... that got us start moving. But take care... Only go for this  
kind of initiative when the following scenario is ok for you (time,  
energy, moral): nobody helps. Do such things ready to accept any help  
that comes... but don't create something counting on help because it  
seems to you so obvious that other should join and help.... when  
nobody has taken any firm engagement to help.

Sure, I have snippets and many useful resources on my wiki... But I  
haven't created this as a service for the community. I have created  
something that is intended to be useful for the community... but also  
serving some other purposes of mine. I created this to learn, to test  
ideas, to create a demand, to experiment, to organize my own notes  
and keep them at hand wherever I am, to see what was possible, what  
was needed to work well, to evaluate the interest (number of hits on  
the page), to analyse contexts in which people contribute. Because of  
this, I expect nothing in return of the time and money I put in this.  
To have somebody contribute in the wiki or send me a nice email makes  
my day... they are superb bonus... but days without any contribution  
don't have any adverse effect on my moral.

But it's not the same at all for the revdoc wiki project. If it gets  
created it must be to serve as service for the community and not ego  
boosting (I speak for me there) or some other personal purpose .  
There shouldn't be ***any*** benefit for the persons who run this  
other than the benefits that all other users take from this  
(increased productivity). Because of this, we really need to set up a  
structure in which the costs for the individuals who give a hand are  
minimized. Medium (up to 1h a day) to high (2-3 hours a day)  
maintenance costs (in terms of time and difficulty) would only be  
acceptable if we had somebody *paid* to take care of the maintenance  
(actually, the main management team at wikipedia is paid, they get a  
lot of sponsors money). This won't happen. Revolution is a very small  
company which focuses its limited resources on what's more important:  
providing a great software. This community is too small to have  
donations pay for somebody doing maintenance.

We haven't that yet... as long as we don't have it, I would  
discourage any person to put the doc on an editable wiki unless they  
are prepared to do all the job of contribution and maintenance job  
themselves in the event nobody gets to help. I am not ready to do  
that (do all the job without any help) . What I am ready to do is  
help set up a structure which maximizes the chances to have others  
help. To  maximize the chances of having members actively contribute,  
we have to minimize the costs of contributing. So, we need a way to  
fetch information directly from the mailing list content. As David  
mentioned, we also need a way for the information to be directly  
updated from within the environment in which you do programming:  

I personally believe that we should avoid to put too much effort in  
the actual commenting of code before we have identified a solution  
where maintenance is as automatized, as reliable and as system  
independent (doc viewed within revolution, within the scripter  
scrapbook, on the web) as possible. I really believe we should put  
some effort on helping to set up such a solution.


Marielle Lange (PhD),  Psycholinguist

Alternative emails: mlange at, M.Lange at
Easy access to lexical databases          
Supporting Education Technologists              http://

More information about the Use-livecode mailing list