HAVE YOU CONTRIBUTED! ...
iain duncan
http://docs.turbogears.org/1.0/RoughDocs
That sign is really obnoxious in the rough doc section, and IMHO is not
a nice thing to stick in a new users face no matter how much help with
docs is needed.
NOBODY HERE WOULD POST LIKE THIS ON THE LIST!!! and expect a friendly
response. So why would we want to do that to our new readers? =(
I remember Kevin saying TG needed help with marketing. Well, here's one
area where we are failing ... don't start by yelling at the customer.
My two cents.
Iain
Karl Guertin
in RoughDocs. If it were on the home page or on /1.0, it'd come down.
As is? I find it amusing and more subtle than my second choice, which
would be a WWII propaganda poster bearing the same text.
Kevin Horn
Kevin Horn
iain duncan
No, *that* would be stylish. ;) Giant blue letters is in no way
subtle ...
( Maybe the poster could on the page for how to contribute to docs? )
Thing is, the rough docs section *is* the docs section for widgets.
Iain
iain duncan
> I like it.
Sure, but it's an "in joke" to the already converted. To the new reader,
the humour is lost.
Iain
Kevin Horn
On Wed, 2007-07-02 at 20:08 -0800, Karl Guertin wrote:
> As is? I find it amusing and more subtle than my second choice, which
> would be a WWII propaganda poster bearing the same text.
No, *that* would be stylish. ;)
Kevin Horn
Christopher Arndt
> re:
> http://docs.turbogears.org/1.0/RoughDocs
>
> That sign is really obnoxious in the rough doc section, and IMHO is not
> a nice thing to stick in a new users face no matter how much help with
> docs is needed.
>
> NOBODY HERE WOULD POST LIKE THIS ON THE LIST!!! and expect a friendly
> response. So why would we want to do that to our new readers? =(
Sorry, I don't get it.
People keep whining that the documentation is bad and when we want to ask them
to help us do something about it, they complain too.
Stop complaining, get to work.
Sorry, for the directness, you can now flame me.
Chris
Ben Sizer
> Sorry, I don't get it.
>
> People keep whining that the documentation is bad and when we want to ask them
> to help us do something about it, they complain too.
>
> Stop complaining, get to work.
>
> Sorry, for the directness, you can now flame me.
The main docs that Turbogears lack are generally the absolute basic,
minimum ones that most projects consider the bare essentials: a
reference to what everything does. Fixing that is not a job for users,
it's a job for the developers. Once the developers have done what
should have been done long ago, only then can the typical user of the
framework be expected to have a decent enough understanding of what is
going on to be able to contribute anything of significant worth.
Certainly nobody with a stake in this project has a right to start
demanding docs from people when they haven't even bothered to explain
the basics.
--
Ben Sizer
Christopher Arndt
> Once the developers have done what
> should have been done long ago, only then can the typical user of the
> framework be expected to have a decent enough understanding of what is
> going on to be able to contribute anything of significant worth.
Any contribution is significant, IMHO. Karl has pointed out a few times now how
people can help out without having in-depth knowledge of TurboGears.
> Certainly nobody with a stake in this project has a right to start
> demanding docs from people when they haven't even bothered to explain
> the basics.
I think, no-one *demands* anything, we're just asking for help. And yes, I
think it is perfectly valid to ask mere "users" to contribute. That's what Open
Source is about. Give and take. The distinction between users and developers
blurs. If you [2] can't help with TurboGears, help another project. Your Karma
will increase and - who knows - next life you will be re-born as a nice little
mouse instead of a beetle [1] ;-)
Sorry, if I'm a little bit silly or sarcastic, but it makes me sad when people
seem to forget that projects like TurboGears live through the participation of
everybody and voluntary work. If you think, using TurboGears has helped you in
some way, why don't you consider in giving something in return?
Chris
[1] Not that I want to diminish the ecological value of beetles in any way.
[2] I don't mean you, Ben, personally. Read this as a generic "you".
Ben Sizer
> Ben Sizer schrieb:
>
> > Once the developers have done what
> > should have been done long ago, only then can the typical user of the
> > framework be expected to have a decent enough understanding of what is
> > going on to be able to contribute anything of significant worth.
>
> Any contribution is significant, IMHO. Karl has pointed out a few times now how
> people can help out without having in-depth knowledge of TurboGears.
That is true. But I think that a lot of us would really be better
placed to contribute if we felt that there was at least a solid
baseline from which to work. For example, I have a few use cases that,
once I solve them, might be useful for submission to the docs.
However, given that quite often I have no idea why they work, or if
I'm doing everything the right way, I am reluctant to propose such
solutions. We really need API docs, even if they only exist for the
core packages. I admit I don't understand why there seems to be a
problem auto-generating them. How hard can it be to list all the
possible arguments for the expose() decorator and what they do, for
example?
I'd take a look at it myself now, but I can't install TurboGears here,
because it wants an old version of Python. Hopefully somebody will fix
that Real Soon Now.
> I think, no-one *demands* anything, we're just asking for help. And yes, I
> think it is perfectly valid to ask mere "users" to contribute. That's what Open
> Source is about. Give and take. The distinction between users and developers
> blurs.
I agree. But Turbogears is quite a complex project, including well
over 25 separate packages last time I checked. Many have different
coding styles. Half of those packages are poorly documented. There is
little way that the average user-developer can dedicate an adequate
amount of time to reading that source code and working out what it
does. Digging through those package boundaries is quite awkward. At
least in C++ I can quickly browse around the source with something
like Visual Studio; is there anything similar for Python?
> If you [2] can't help with TurboGears, help another project. Your Karma
> will increase and - who knows - next life you will be re-born as a nice little
> mouse instead of a beetle [1] ;-)
I've contributed several comments to the docs pages, most of which
seem to have been acted upon, which is good. I'd be much happier if it
was in Wiki format and I could refactor some of the overly
unstructured pages as and when I find the time, but it's not. I
appreciate that it may be reserved for a select group of people.
There's not much else I feel I can do though, especially since my own
Turbogears work is regularly halted by poor documentation. I even
bought the book - sadly through a degree of desperation rather than
desire - but haven't managed to read much of it yet.
--
Ben Sizer
iain duncan
> Ben Sizer schrieb:
> > Once the developers have done what
> > should have been done long ago, only then can the typical user of the
> > framework be expected to have a decent enough understanding of what is
> > going on to be able to contribute anything of significant worth.
>
> Any contribution is significant, IMHO. Karl has pointed out a few times now how
> people can help out without having in-depth knowledge of TurboGears.
Yes, but *demanding* ( which is the impression that sign makes ) is
rude, not practical, and doesn't make sense. And it makes the wildly
erroneous assumption that a new user plans on sticking around. They are
still auditioning the project. They won't contribute until they make a
decision that is worth putting time in, and we have to welcome them and
get them up and running as painlessly as possible in order for them to
do that. Then *maybe* they become commited users. And *maybe* they
become docs writers or developers. And that should be enough.
> Sorry, if I'm a little bit silly or sarcastic, but it makes me sad when people
> seem to forget that projects like TurboGears live through the participation of
> everybody and voluntary work. If you think, using TurboGears has helped you in
> some way, why don't you consider in giving something in return?
What ever makes you think that I don't plan on it? What does that have
to do with how we welcome new users? ( Which is the issue in point here,
I started the thread over that sign. ) Here is a simple thought
experiment for you. Have you contributed to docs for *all* of:
- apache
- cherrypy
- emacs/vim/your FLOSS editor
- linux/bsd
- xorg, gnome, your window manager of choice
- python/php/perl/
- gcc/g++/the rest of GNU code tools
- mozilla/firefox/firebug/venkman
Yes you are correct that we need volunteer work. But ALL of my list are
open source, and all are used by developers who are as qualified to
contribute as the average TG user. And as a developer I'm sure we could
both add another couple of dozen open source libraries and toolkits we
use regularly. All have docs. In none ( except now TG ) have I
encountered an *expectation* that making docs is a *responsibility* of a
new user and that I am expected as a user to contribute to *this*
project, and then been greeted by a sign like that. It is very poor
project manners to our potential user base.
I personally do plan to when I contribute, *when* I understand the
basics better. I'm making a point on a larger scale, because I would
like to see TG last, and this is not welcoming to new users. It looks
very bad from a marketing perspective, and we want new users right? In
order than a small share become developers. That is the spirit of open
source, give to all, some become developers. It is not the expectation
of a good project that all users become developers. You may personally
think everyone should contribute back to open source, I think so too, in
some manner. I sure as heck don't think that it even makes sense for me
to contribute back to each of the hundred odd FLOSS tools I use every
day.
Telling me to get back to work writing docs when I have been using TG
for 3 months now is just silly and as mentioned, a cop out. And I
represent well this "generic you" are yelling at. You don't hear that
crap from Bob about Mochkit. He put it out with stellar ref docs and
would never expect ( or allow for quality reasons ) a new user to do
that for him.
I did not start this current friction over the docs. But I did leap to
defend people for making valid critiques when they were greeted by a
non-sensical chorus of "well, stop complaining that the docs are
incomplete, why haven't *you* done anything about it?" Believe me, we
damn well are losing users over that attitude, they just don't say
anything about when they go. I'm stirring the pot because I *do* care.
If I didn't, I'd just say "TG? man, they were really rude when someone
pointed out that they had no manual, I'm going back to PHP.net"
So if people are going to say to me "stop whining and start writing
docs" then I'm saying back "stop whining about your lack of volunteers
are start treating your new users properly or you will lose them."
Iain
Jorge Godoy
> I'd take a look at it myself now, but I can't install TurboGears here,
> because it wants an old version of Python. Hopefully somebody will fix
> that Real Soon Now.
There are reports of successful runs of TG (with both SO and SA) with Python
2.5. You could also have helped with making it run or finding out why it
didn't run before...
> does. Digging through those package boundaries is quite awkward. At
> least in C++ I can quickly browse around the source with something
> like Visual Studio; is there anything similar for Python?
At least Eclipse and Emacs can help with that. I'm sure other commercial
tools and probably more of the free (as in speech and beer) kind exist.
--
Jorge Godoy <jgo...@gmail.com>
Christoph Zwerschke
> Yes, but *demanding* ( which is the impression that sign makes ) is
> rude, not practical, and doesn't make sense.
I have tried to create a more humorous version of the sign so that
people understand the gist of it without scaring them off. Actually I
think the sign would fit better to http://docs.turbogears.org/DocHelp
which is not such a prominent place, but that page was locked. If you
think it's too goofy I'll remove it. Just wanted to bring some humor
into the fierce discussion since I think both sides really have their
points and are right to some extend. So let's calm down a little.
Actually the problem is that TurboGears docs are a difficult issue,
since you need a lot of experience and overview over all the packages
involved. It's always the best if the one who originally invented and
coded a package writes an overview and the fundamental docs. I think
SQLAlchemy is exemplary in this regard. If the basic documentation is
there, then users can fill some gaps, add tutorials etc. In other cases,
the masterminds behind great open source projects leave pretty quickly
once the code is written and functional in a first version, since
writing documentation and maintaining the project is too boring and too
little a challenge for these bright minds. No offense or value judgment
intended her, I think it is just like that and we need to accept it,
appreciate their great work anyway, and make the best of it. After the
"founding fathers" left a project, it is always a difficult phase since
others are never so motivated as the one who originally started a
project, and don't have enough overview over the whole project.
-- Chris Z.
iain duncan
> iain duncan wrote:
> > Yes, but *demanding* ( which is the impression that sign makes ) is
> > rude, not practical, and doesn't make sense.
>
> I have tried to create a more humorous version of the sign so that
> people understand the gist of it without scaring them off. Actually I
> think the sign would fit better to http://docs.turbogears.org/DocHelp
> which is not such a prominent place, but that page was locked. If you
> think it's too goofy I'll remove it. Just wanted to bring some humor
> into the fierce discussion since I think both sides really have their
> points and are right to some extend. So let's calm down a little.
That one is WAY better! =)
Iain
( Though I still like the WWII theme idea too. Especially because it
could so easily incorporate gears in there. )
Christopher Arndt
> I have tried to create a more humorous version of the sign so that
> people understand the gist of it without scaring them off. Actually I
> think the sign would fit better to http://docs.turbogears.org/DocHelp
> which is not such a prominent place, but that page was locked.
Cool!
I moved it to DocHelp. I find it very nice. What do the other documentation
writers think?
Chris
Karl Guertin
that message.
Christopher Arndt
> Yes, but *demanding* ( which is the impression that sign makes )
Well, obviously, we both have a different understanding of which kind of
statement expresses a "demand" instead of rather "asking for something". I
always think, that everybody should be grown up enough to answer "no".
But I might be too optimistic about the understanding of people, I'm only a
programmer, what do I know about people ;-)
Anyway, I agree that a tongue-in-cheeck picture like the one Christoph created
is a million-times better!
Chris
gasolin
> is a million-times better!
>
HA! HA! I like this one.
These guys in picture looks pretty enthusiastic XD.
Ben Sizer
> "Ben Sizer" <kylo...@gmail.com> writes:
> > I'd take a look at it myself now, but I can't install TurboGears here,
> > because it wants an old version of Python. Hopefully somebody will fix
> > that Real Soon Now.
>
> There are reports of successful runs of TG (with both SO and SA) with Python
> 2.5. You could also have helped with making it run or finding out why it
> didn't run before...
I could have, but my home development environment allows me to use
Python 2.4, so I did that, knowing that it wouldn't work with 2.5. At
my work machine with 2.5 installed, tgsetup.py just says "get 2.4.3
instead", so that's the end of the matter for me. If the script is so
strict as to disallow me from even downloading it, I'm going to assume
it's not worth the bother.
--
Ben Sizer
Jorge Godoy
> I could have, but my home development environment allows me to use
> Python 2.4, so I did that, knowing that it wouldn't work with 2.5. At
> my work machine with 2.5 installed, tgsetup.py just says "get 2.4.3
> instead", so that's the end of the matter for me. If the script is so
> strict as to disallow me from even downloading it, I'm going to assume
> it's not worth the bother.
The script plays safe. And it predates the successful working tests on 2.5.
It was your choice to not go further and help and I respect that. I did the
same with regards to 2.5 (I had no time to go and see how installing 2.5 along
with my 2.4 development environment would go, so I abstained myself from it,
but you never heard me saying anything to rush things up on supporting it.).
--
Jorge Godoy <jgo...@gmail.com>
rdmu...@bitdance.com
for a couple weeks. I'm trying to get some traction on my current
project, that I want to deploy in turbogears. I've played around
with TG enough now to know I like the basic concepts and how easy
it is to turn python code into working web pages.
I like test driven development, so now that I'm ready to start
serious development the first thing I did was run the nosetests.
They failed. I tried it again in a fresh quickstart project,
and they still failed.
This is tg 1.0.1 with Identity enabled, and the identity tests appear
to be the problem. There's also the capitalization issue with the
tags that I heard mentioned here earlier. I also remember some
stuff about tests failing with DB errors, but I believe that had
to do with SQL Alchemy, and I'm using SO.
I'm surprised that a release went out the door with tests that fail
out of the box.
If these bugs have been fixed, what's the best way to track the
"production" version of TG (I presume that's 1.0.1 right now,
since that's what comes up when I do an easy_install of TG)
with bug fixes applied?
I did not get any hits when I searched on the particular error
message I'm getting from the nosetests. They look like this:
======================================================================
ERROR: A user can reset their password.
----------------------------------------------------------------------
Traceback (most recent call last):
File ".../sample/tests/test_registration.py", line 51, in setUp
self.create_identity_tables()
File ".../sample/tests/test_registration.py", line 186, in create_identity_tables
register_model.user_class_finder.user_class.createTable(createJoinTables=False)
File ".../SQLObject-0.7.1dev_r1860-py2.4.egg/sqlobject/main.py", line 1322, in createTable
conn.createTable(cls)
File ".../SQLObject-0.7.1dev_r1860-py2.4.egg/sqlobject/dbconnection.py", line 527, in createTable
self.query(self.createTableSQL(soClass))
File ".../SQLObject-0.7.1dev_r1860-py2.4.egg/sqlobject/dbconnection.py", line 752, in query
return self._dbConnection._query(self._connection, s)
File ".../SQLObject-0.7.1dev_r1860-py2.4.egg/sqlobject/dbconnection.py", line 303, in _query
self._executeRetry(conn, conn.cursor(), s)
File ".../SQLObject-0.7.1dev_r1860-py2.4.egg/sqlobject/dbconnection.py", line 298, in _executeRetry
return cursor.execute(query)
OperationalError: table tg_user already exists
Should I file a trac case for this? I haven't tried looking for the bug
yet since given the recent discussions about failing tests I'm hoping
the bugs have been fixed and I just need to update my version somehow...
--David
Mikkel Høgh
your test.cfg look like?
Christopher Arndt
> I like test driven development, so now that I'm ready to start
> serious development the first thing I did was run the nosetests.
What do you you ran the tests? On TurboGears itself or one of your projects?
> They failed. I tried it again in a fresh quickstart project,
> and they still failed.
Yes, but only one of them should fail.
> This is tg 1.0.1 with Identity enabled, and the identity tests appear
> to be the problem.
'tests.test_controllers.test_logintitle' to be precise.
> There's also the capitalization issue with the
> tags that I heard mentioned here earlier.
That can be fixed by setting 'kid.outputformat="HTML"' (capital HTML) in
'myproject/config/app.cfg'.
> I also remember some
> stuff about tests failing with DB errors, but I believe that had
> to do with SQL Alchemy, and I'm using SO.
No, it is effecting SQLObject also, because the identity initialization was a
bit messy when running tests. AFAIK that should be fixed in the 1.0 branch now.
> I'm surprised that a release went out the door with tests that fail
> out of the box.
Yes, we should probably have a pre-release testing script that checks several
quickstarted projects with different settings. I'll bring that up on the trunk
mailing list.
But you have to distinguish between tests for TurboGears itself and the tests
of a quickstarted project.
> If these bugs have been fixed, what's the best way to track the
> "production" version of TG (I presume that's 1.0.1 right now,
> since that's what comes up when I do an easy_install of TG)
> with bug fixes applied?
If you download a current tgsetup,py you should always get the latest
production release. You can also run an SVN checkout from 'branches/1.0', if
you want to benefit from latest fixes (but also suffer from possible breakages).
> I did not get any hits when I searched on the particular error
> message I'm getting from the nosetests. They look like this:
> OperationalError: table tg_user already exists
Hmm, this error might indicate that you aren't running the tests with a fresh
database. Have you changed 'test.cfg'? Can you checkout the latest version from
the branch and try if you still get the *same* error?
But, anyway, the problem with the identity tests still don't seem to be fixed.
When I run 'python setup.py test' in a quickstarted project with SQLObject and
identity and a fresh TurboGears 1.0.1 installation, I get the following error:
File "/home/chris/tmp/tgenv/src/MyTest2/mytest2/tests/test_controllers.py",
line 32, in test_logintitle
assert "<TITLE>Login</TITLE>" in cherrypy.response.body[0]
AssertionError
The same happens if I check out the latest 1.0 branch version, do a 'python
setup.py develop', create a quickstarted app and run the tests:
File "/home/chris/tmp/tgenv/src/MyTest4/mytest4/tests/test_controllers.py",
line 34, in test_logintitle
assert "<title>login</title>" in response
AssertionError
To see the real error, I run 'nosetests -d -w mytest4' and get:
file
"/home/chris/tmp/tgenv/lib/python2.4/cherrypy-2.2.1-py2.4.egg/cherrypy/filters/__init__.py",
line 151, in applyfilters
method()
file "/home/chris/tmp/tgenv/src/turbogears/turbogears/visit/api.py", line
147, in before_main
visit= _manager.new_visit_with_key( visit_key )
attributeerror: 'nonetype' object has no attribute 'new_visit_with_key'
The error is the same for projects with SQLObject or with SQLAlchemy. It seems
that changeset 2366 only fixed the tests of TurboGears itself and not the tests
in the quickstart templates.
Chris
rdmu...@bitdance.com
> It seems that the tests are trying to do something odd... What does
> your test.cfg look like?
Well, I figured out part of it. It wasn't identity tests, it was
the tests that came with registration. I'd forgotten that I'd
installed that package into my "clean" quickstart :(
But it wasn't those tests that were causing the problem. Once I
commented out all the code in test_controllers.py, the tests in
test_registration.py mostly passed. (There's one that doesn't,
but I'm not worried about that for now).
I noticed that only one of the two tests that check a rendered page
in test_controllers would pass, that being whichever one ran first.
In subsequent tests cherrypy would return an error page. That's what
clued me in to try commenting out that whole file. I just really
did do a fresh quickstart, and that behavior shows up in the clean
quickstart (with identity).
--David
Christoph Zwerschke
> I noticed that only one of the two tests that check a rendered page
> in test_controllers would pass, that being whichever one ran first.
> In subsequent tests cherrypy would return an error page. That's what
> clued me in to try commenting out that whole file. I just really
> did do a fresh quickstart, and that behavior shows up in the clean
> quickstart (with identity).
The controller test will only run properly if you have TG 1.0.1
installed and also applied the following patches (you are hitting the
second of these three problems):
If you use Kid >0.9.3: tag case mismatch
--> patch #1289
If you use identity: tables destroyed on shutdown (only first test runs)
--> patch #1298 (not yet comitted)
If you use identity & sqlalchemy: tables not created on startup
--> patch #1290
-- Christoph
Jorge Vargas
not documented are the addons there is even a set of diagrams with the
flow of requests.
> --
> Ben Sizer
>
>
>
> >
>
Jorge Vargas
ready environments. if you want to test and/or develop please use
trunk or the 1.0 branch and python setup.py develop, I'm not sure if
easy_install TurboGears=dev is working I don't use it.
as for 2.5 TG depends on a lots of packages and those where finally
upgraded with the lastest release of COnfigObj and pyrex which have
less then 2weeks.
Currently TG 1.0branch works on python2.5 but again that's not
production ready hence the hard block.
> --
> Ben Sizer
>
>
> >
>
Jorge Vargas
> > Ben Sizer schrieb:
> >
> > > Once the developers have done what
> > > should have been done long ago, only then can the typical user of the
> > > framework be expected to have a decent enough understanding of what is
> > > going on to be able to contribute anything of significant worth.
> >
> > Any contribution is significant, IMHO. Karl has pointed out a few times now how
> > people can help out without having in-depth knowledge of TurboGears.
>
> That is true. But I think that a lot of us would really be better
> placed to contribute if we felt that there was at least a solid
> baseline from which to work. For example, I have a few use cases that,
> once I solve them, might be useful for submission to the docs.
> However, given that quite often I have no idea why they work, or if
> I'm doing everything the right way, I am reluctant to propose such
> solutions. We really need API docs, even if they only exist for the
> core packages. I admit I don't understand why there seems to be a
> problem auto-generating them. How hard can it be to list all the
> possible arguments for the expose() decorator and what they do, for
> example?
this is already finish, we are having some troubles uploading it to
the server I hope it's fix in this week.
Until that is done you can use my test system (please don't abuse my
bandwidth) http://tg.maetico.com/api/, or you can generate your own
with easy_install epydoc and then
http://trac.turbogears.org/ticket/104#comment:11
In fact this is one place where users can contribute all you need to
know is how a apitool works. (epydoc has a problem with some of the
widgets code)
As for generating the docs you will be impress of how hard it is to
build such a tool for python code being it all dynamic, metaclasses
are a problem and some parts of TG are a bit complicated.
>
> I'd take a look at it myself now, but I can't install TurboGears here,
> because it wants an old version of Python. Hopefully somebody will fix
> that Real Soon Now.
>
I believe your windows pc is the one having python25? please don't
refer as python24 as *old* is the default on almost all OS, now just
step back for 1 min and think what feature python25 has that TG
*really* needs, at most I'll say sqlite which is not a good idea for
deployment, and any() all() which could be used for identity (they are
currently implemented in TG code),and TG needs the "extended" ET. So
there is really no advantage here, but ones again svn code already
works.
> > I think, no-one *demands* anything, we're just asking for help. And yes, I
> > think it is perfectly valid to ask mere "users" to contribute. That's what Open
> > Source is about. Give and take. The distinction between users and developers
> > blurs.
>
> I agree. But Turbogears is quite a complex project, including well
> over 25 separate packages last time I checked. Many have different
> coding styles. Half of those packages are poorly documented. There is
> little way that the average user-developer can dedicate an adequate
> amount of time to reading that source code and working out what it
> does. Digging through those package boundaries is quite awkward. At
> least in C++ I can quickly browse around the source with something
> like Visual Studio; is there anything similar for Python?
>
actually that's not entirely true, most of those packages are small
take a look at TurboKid, the ones that really mather are the major
kid, SQLobject, Cherrypy, ConfigObj everything else is just used
"internally" for example I have never had to touch any C code to
fix/implement anything on TG and there is no C code on TG itself just
on it's dependencies.
> > If you [2] can't help with TurboGears, help another project. Your Karma
> > will increase and - who knows - next life you will be re-born as a nice little
> > mouse instead of a beetle [1] ;-)
>
> I've contributed several comments to the docs pages, most of which
> seem to have been acted upon, which is good. I'd be much happier if it
> was in Wiki format and I could refactor some of the overly
> unstructured pages as and when I find the time, but it's not. I
> appreciate that it may be reserved for a select group of people.
>
yes me too, check out my lastest post on turbogears-docs about this, I
believe reverting to wiki is a good thing because most people like
ReST because of <insert reason here>
Jorge Vargas
>
> I like it better on RoughDocs where it's more visible, but I approve
> that message.
>
> >
>