revdocs
Marielle Lange
mlange at lexicall.org
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:
revolution.
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
------------------------------------------------------------------------
--------
Marielle Lange (PhD), Psycholinguist
Alternative emails: mlange at blueyonder.co.uk, M.Lange at ed.ac.uk
Homepage
http://homepages.lexicall.org/mlange/
Easy access to lexical databases http://lexicall.org
Supporting Education Technologists http://
revolution.lexicall.org
More information about the use-livecode
mailing list