Django's documention is horrible
Simon W
For such a good web framework it's a shame that the documention is not structured well .. at all. It consists of massive text put on a page with some random examples. But examples is all there is. In other languages and frameworks I'm used to have at least a well structed API documention listing all methods and members of classes with some comment attached to them. They also show the class heirachy, quick and simple. I spend more time searching for minor stuff in the documention than writing code. The django project should look into doxygen or some similar doc generator.
And this mailing list? It's so hard to find any existing answers quick, google doesn't find none. I mean comon .. look at jQuery, you find what you're looking in less than 2 sec using google. Why isn't there a proper forum?
Am I the only one who frown upon this?
Cheers
Shawn Milochik
I am certain that your non-confrontational tone and obvious appreciation for all the hard work done for free by volunteers has endeared you to all of us.
One minor suggestion: In the community, we like to see people who identify room for improvement step up and volunteer their own time to fix the things they want fixed. Do you have any spare time?
Shawn
mrmclovin
django very much for what it is. The library is beautiful really, but
the documentation is the opposite.
I wish I could spend time to help improve the documentation, but I
have not the time.
Instead I thought I'd make this (not very well expressed obviously)
complaint to bring it up to developers attention and see if there's
anyone else that thinks that I do.
Im not a beginner when it comes to programming and django was very
easy to learn but as soon as you start developing and want to tweak
stuff it's so hard to get fast detail documentation .. Im just curious
why the django project haven't set up any proper forum?
Again sorry for my unfriendly topicstarter.
Sam Walters
My approach with regard to:
> frameworks I'm used to have at least a well structed API documention listing
> all methods and members of classes with some comment attached to them. They
> also show the class heirachy, quick and simple.
I just look at the source itself for this.
cheers
sam_w
Ovnicraft
or use pydoc
cheers
sam_w
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
--
Cristian Salamea
@ovnicraft
Chris Czub
Javier Guerra Giraldez
>
> or use pydoc
right.
i think what Simon means (but still can't articulate) is the
difference between explanations (which are great in the Django docs)
and references (which aren't so good).
but the right tool for Python code references is pydoc, which _is_
very complete in Django.
maybe it would be a nice gesture to add pydoc's output to the online docs?
--
Javier
Shawn Milochik
mrmclovin
There's lots of class relations and going back and forth is clumsy.
Also in most cases Im just after the specification of a class or where
it's defined and it takes longer time if you have to scroll down the
source code as well. Have a look at the API doc of a 3D library called
Ogre3d http://www.ogre3d.org/docs/api/html/annotated.html
Do you see what I mean? Fast, simple, clean and online! Very
convenient!
mrmclovin
solutions by ask&answer is not good for documentation IMO. I don't
like to ask questions because then I have to explain the problem, word
everything right and then wait for an answer. I prefer to find the
answer quick on my own and only ask as a last resort and I think many
people agree with this.
Steven Elliott Jr
Sent from my iPhone
--
selman kocael
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
--
// // //
Shawn Milochik
On Jan 10, 2011, at 5:23 PM, mrmclovin wrote:
> Yes, being part of the community is good. But to base help and
> solutions by ask&answer is not good for documentation IMO. I don't
> like to ask questions because then I have to explain the problem, word
> everything right and then wait for an answer. I prefer to find the
> answer quick on my own and only ask as a last resort and I think many
> people agree with this.
I totally agree with this myself. And there are plenty of resources -- the Apress books, the official docs, stack overflow, and all the blogs.
If there's something you're lacking in Django education after availing yourself of those things, then being a part of the living community embodied in this list and DjangoCon is the best way to keep current and learn the clever solutions others have developed for common "problems" that haven't been baked into Django proper for whatever reason.
Shawn
James Bennett
> For such a good web framework it's a shame that the documention is not
> structured well .. at all. It consists of massive text put on a page with
> some random examples. But examples is all there is. In other languages and
> frameworks I'm used to have at least a well structed API documention listing
> all methods and members of classes with some comment attached to them. They
> also show the class heirachy, quick and simple. I spend more time searching
> for minor stuff in the documention than writing code. The django project
> should look into doxygen or some similar doc generator.
The way I see it, there are two types of documentation:
1. Documentation which must be written by human beings.
2. Documentation which can be generated automatically by software.
The documentation you'll find on docs.djangoproject.com is the first
type. It consists, in large part, of things people want to know about
Django but which can't be worked out automatically by a piece of
software scanning over the code and docstrings. Much of this is in the
form of how-to documents, broad overviews, tutorials, etc. which walk
you through some feature and provide example code for common use
cases; this sort of documentation can only be produced by human beings
who know Django fairly well and put in the time and effort to write.
The second type of documentation seems to be what you're looking for.
Things like big lists of classes and members with docstrings are
useful, certainly, but they're not something which requires human
effort to produce; as others in the thread have pointed out, there are
quite a few good tools for Python which will scan over a codebase and
spit out this information into the output format of your choice. And
since this type of documentation can be generated by software any time
you need it, there's not a whole lot of utility to putting it up on
the site.
So my recommendation for you would be to look at tools like epydoc,
since they do exactly what you appear to be asking for; meanwhile
we'll keep putting the efforts of the Django dev team into producing
the documentation epydoc can't :)
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Russell Keith-Magee
> Im just curious
> why the django project haven't set up any proper forum?
I'll address this one.
I am yet to meet an online forum interface that doesn't make me want
to gouge my own eyes out. For my money, email is a vastly preferable
interface in almost every respect. Google's Groups could certainly do
with some work, but it's a lot more serviceable than any forum
interface I've ever used.
Yours,
Russ Magee %-)
Javier Guerra Giraldez
<rus...@keith-magee.com> wrote:
> I am yet to meet an online forum interface that doesn't make me want
> to gouge my own eyes out. For my money, email is a vastly preferable
> interface in almost every respect.
wholeheartedly agree. (and i'm sure not to be the only one)
--
Javier
Kevin Monceaux
> I am yet to meet an online forum interface that doesn't make me want
> to gouge my own eyes out. For my money, email is a vastly preferable
> interface in almost every respect. Google's Groups could certainly
> do with some work, but it's a lot more serviceable than any forum
> interface I've ever used.
I couldn't agree with you more. I never do well keeping up with
online forums, but I'm on umpteen mailing lists. My local mail
archives serve me well.
My main complaint about Google Groups is that I can't download message
archives when I join a group. That option is available with most
Mailman based mailing lists, and I've even found a script for
downloading Yahoo Groups message archives. My local archive of this
mailing list only goes back to 2009. I'd love to have the full
archive of this list at my fingertips.
--
Kevin
http://www.RawFedDogs.net
http://www.WacoAgilityGroup.org
Bruceville, TX
What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.
Christophe Pettus
On Jan 10, 2011, at 1:25 PM, Simon W wrote:
> For such a good web framework it's a shame that the documention is not structured well .. at all.
I have no doubt that the project would be more than receptive to doc patches to fix the problem.
--
-- Christophe Pettus
x...@thebuild.com
Torsten Bronger
Kevin Monceaux writes:
> [...]
>
> My main complaint about Google Groups is that I can't download
> message archives when I join a group.
You can ready it as a newsgroup through Gmane.
Tsch�,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: torsten...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
Sam Lai
>
> On Jan 10, 2011, at 1:25 PM, Simon W wrote:
>
>> For such a good web framework it's a shame that the documention is not structured well .. at all.
>
> I have no doubt that the project would be more than receptive to doc patches to fix the problem.
This isn't about patches to the existing docs (which are great for
their purpose). It is about Django missing an API reference manual,
something like .NET Class Library Reference
(http://msdn.microsoft.com/en-us/library/gg145045.aspx), PHP's
Function Reference (http://www.php.net/manual/en/funcref.php) or
Java's (rather hideous looking) API reference
(http://download.oracle.com/javase/6/docs/api/).
I'm glad someone brought this up (although 'horrible' seems like too
strong a word). I miss not having these docs in some online form
because once you know enough about Django, you often know that Django
has capability x but you don't remember what class/namespace it is in.
You end up having to google and spend a while locating the info in the
existing docs. Browsing or grepping the code isn't much better (maybe
I'm missing an app or two here).
API docs also tend to be more structured and concise so you can
instantly see what parameters take what, what exceptions might be
thrown, what the return value is/represents etc.
Right now, I almost always have a browser tab open to
code.djangoproject.com for this purpose.
Talk/ideas are cheap, so here's my take on possible API docs for Django -
An API reference site structured in a similar manner to the above
examples, with the ability to easily search; integrated pydocs; links
to relevant sections of the Django docs; a link to see the code of the
function/class/method etc. A wiki-style section for each page would be
nice too to document caveats, tips, tricks, relevant snippets etc.
Of course the dynamic nature of the code makes this harder to do and
will probably require some human intervention to ensure an entry
exists for every parameter, mapped method etc.
P.S. what's the short answer to why the current Django docs aren't on
a wiki site instead of being versioned inside SVN?
There are some minor clarifications here and there that I'd like to
add, but the overhead of producing a patch, creating a ticket,
flagging down a committer, getting a consensus, and finally having the
patch committed is a bit off-putting. I can understand the process for
code, but it just seems a bit over-the-top for docs. Maybe a
compromise would be adding something like the per-paragraph comments
that The Django Book site has; that way the docs stay official, yet
there's still a way for users to add to them.
> --
> -- Christophe Pettus
> x...@thebuild.com
>
Kenneth Gonsalves
> Am I the only one who frown upon this?
the documentation is excellent - structure needs revamping as it is very
difficult to find any thing unless one knows the key words. It was far
better uptil circa .96. I have been working on a small scheme on how to
structure it better - because I know how busy the devs are here, I
refrained from criticising without giving a possible solution.
--
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/
James Bennett
> This isn't about patches to the existing docs (which are great for
> their purpose). It is about Django missing an API reference manual,
> something like .NET Class Library Reference
> (http://msdn.microsoft.com/en-us/library/gg145045.aspx), PHP's
> Function Reference (http://www.php.net/manual/en/funcref.php) or
> Java's (rather hideous looking) API reference
> (http://download.oracle.com/javase/6/docs/api/).
I've already addressed this point politely, so perhaps it's time to
turn it up a notch:
If your computer is incapable of running pydoc, epydoc or other
similar scripts, how is it simultaneously able to run Django?
Or, not quite so snarkily:
If your computer *is* capable of running pydoc, epydoc, etc., why
aren't you using those tools? And if you're not using them now, why
should I believe you'll make use of epydoc-generated API references if
someone else generates them for you?
(OK, so that was pretty snarky, but I think it's a valid question to ask)
> P.S. what's the short answer to why the current Django docs aren't on
> a wiki site instead of being versioned inside SVN?
There's already a wiki on code.djangoproject.com; it's part of Trac.
If you think wikified documentation would be a good idea, you should
feel free to start putting some up there.
What you'll find pretty quickly, though, is that there's a good reason
why the official docs live in the repo and are maintained by the core
team rather than being on a community-edited wiki: the wiki is where
useful things go to die. It's full of half-baked solutions, code that
only (maybe) runs on Django 0.96, etc., etc., because the nature of a
wiki doesn't really encourage people to make long-term maintenance
commitments. Those of us who have commit bits *have* made such
commitments, and incidentally do a lot more than just committing
documentation patches as they come in; for anything bigger than a typo
fix, there's almost always heavy editing going on for style,
consistency, readability and a bunch of other factors that a wiki can
only manage at the cost of massive bureaucracy and high barrier to
entry (it's no coincidence that Wikipedia is notoriously hard to edit
successfully -- I'm pretty sure they have more documentation on
policies than we have documentation, period).
mrmclovin
what I was trying to say: django need a reference manual to complement
the existing documentation.
On Jan 11, 8:55 am, James Bennett <ubernost...@gmail.com> wrote:
> If your computer is incapable of running pydoc, epydoc or other
> similar scripts, how is it simultaneously able to run Django?
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
compile the game in order to play it.. or just install it and play it?
You seem to be missing the point of having a convenient way of
providing a reference manual. I didn't know about pydoc until now,
maybe it's got what im looking for. However, I rather spend my time
writing django code instead of using different 'tools' to get simple
reference docs.
Masklinn
> On 11 January 2011 13:39, Christophe Pettus <x...@thebuild.com> wrote:
>>
>> On Jan 10, 2011, at 1:25 PM, Simon W wrote:
>>
>>> For such a good web framework it's a shame that the documention is not structured well .. at all.
>>
>> I have no doubt that the project would be more than receptive to doc patches to fix the problem.
>
> This isn't about patches to the existing docs (which are great for
> their purpose). It is about Django missing an API reference manual,
> something like .NET Class Library Reference
> (http://msdn.microsoft.com/en-us/library/gg145045.aspx), PHP's
> Function Reference (http://www.php.net/manual/en/funcref.php) or
> Java's (rather hideous looking) API reference
> (http://download.oracle.com/javase/6/docs/api/).
>
> P.S. what's the short answer to why the current Django docs aren't on
> a wiki site instead of being versioned inside SVN?
Because wikis stink and a documented versioning means it's easy to keep in sync with the corresponding source, it's easy to package documentation with the corresponding release, documentation fixes can go through the same process as code fixes (including documentation bugs on the tracker) and documentation contributions are treated as first-class contributions and have the same status as code one, also serving as a "gateway drug" to contribution to Django's code?
> There are some minor clarifications here and there that I'd like to
> add, but the overhead of producing a patch, creating a ticket,
> flagging down a committer, getting a consensus, and finally having the
> patch committed is a bit off-putting.
Only the first two are your job (why would you have to "flag down a committer"?) and unless your changes are extensive and/or controversial in my experience getting a document patch in is trivial.
Which leaves three tasks: 1. editing the rst files, 2. running `svn diff` and 3. creating a ticket. Last time I did it, it was pretty painless.
Masklinn
> If you bought a game, would you rather like to get info on how to
> compile the game in order to play it.. or just install it and play it?
>
mrmclovin
>
> This analogy makes no sense whatsoever, I fear.
letting users "compile" the source themselves?
Guess I will try pydoc now and get my own html reference. I hope next
time someone is looking for this is able to Google this post ... :)
Masklinn
> On Jan 11, 9:59 am, Masklinn <maskl...@masklinn.net> wrote:
>>
>> This analogy makes no sense whatsoever, I fear.
>
> hehe why?
In fact the APIDocs are pretty irrelevant to a new Django user, and the handcrafted guides will likely be much more valuable.
mrmclovin
On Jan 11, 1:51 pm, Masklinn <maskl...@masklinn.net> wrote:
> On 2011-01-11, at 13:47 , mrmclovin wrote:> On Jan 11, 9:59 am, Masklinn <maskl...@masklinn.net> wrote:y?
> Because you don't have to compile APIDocs to be able to use Django.
>
> In fact the APIDocs are pretty irrelevant to a new Django user, and the handcrafted guides will likely be much more valuable.
access to api reference in order to extend and customize django
further efficiently.
shofty
want to gouge my own eyes out. its not a great place for reading code
is it? you can't do a [code] [/code] to isolate an example on it. the
point im trying to make is that your choice isn't necessarily my
choice. who is right? (nobody, but then you know that).
ASIDE: you'd think there'd be a djangonaut smart enough to amend the
existing forum code im sure i've seen (in pinax maybe) to add in a
[stacktrace][/stacktrace] and then start a community helpsite.
don't worry, i fully understand that the ethos exists within django
that the tools are there and we can if we feel we need to go out there
and do it. im not sure im ready yet, but maybe in time. for now i'll
cope with the google groups.
also to pick up on another point mentioend in here that there are a
lot of blogs. there are. tons. bloody loads and loads of blogs, all
with old outdated code on. and not many people blogging point out what
version they are running when blogging.
also check stack overflow out. lots of django examples on there,
hardly any of which are moderated by a community who know the code
inside out, and again, nobody pointing out what version of django
they've copied and pasted their supposedly fix all code from.
all im doig here is pointing out that it is hard to find working
examples of code on the web for many reasons. the documentation is
great, but it doesn't go far enough sometimes. IMO.
On Jan 10, 11:51 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
Masklinn
> but by the same token, ive not seen a mailing list that hasn't made me
> want to gouge my own eyes out. its not a great place for reading code
> is it? you can't do a [code] [/code] to isolate an example on it.
pretty easy to display code in an email. There is no need to "isolate"
an example of it, just indent it a bit to create a separate block if
you really want to. And clearly no need for [code] tags.
Hell, there are lists (hg's for instance) where code review is handled
by posting patchbombs inline on the list and reviewers commenting on
the patch. And it works pretty damn well too.
> ASIDE: you'd think there'd be a djangonaut smart enough to amend the
> existing forum code im sure i've seen (in pinax maybe) to add in a
> [stacktrace][/stacktrace] and then start a community helpsite.
I'm sure there is, the question is if there's a djangonaut able to do
that who sees *value* in doing this. Apparently hasn't been the case
so far, you might be the one to change this no?
> all im doig here is pointing out that it is hard to find working
> examples of code on the web for many reasons.
And a forum would *not* help with that: forum posts get outdated just
as anything else, and people aren't going to go edit their old code
all the time in order to ensure it stays current. Just as bloggers
rarely go through their archive to cleanup or fix breakage in their
previous code.
Furthermore, form management is much more heavyweight than a mailing
list in that you have to deal with more extensive moderation and spam
management needs. And the bigger the community using them, the harder
and more expensive (in terms of time) it is.
If you have the time to launch yourself into such a project, you
should go ahead, I don't think the django core team really has that
kind of time on their hands. Especially while they're trying to
release 1.3.
Rainy
are things in django itself and existing docs that could be improved.
I would prefer if they spent the time on more important
things rather than relatively less important, e.g. things that can be
done automatically by modules like pydoc.
OTOH I would also appreciate it if someone made an nice online
module reference for django. I don't need it very often, but when
I do, it'd be nice to have, no doubt.
I think it's unfair to say Django docs are bad -- to the contrary,
they're the best docs I've seen in an open source project.
And forum interfaces and especially searching is pathetically
bad, I always end up using google to search forum sites instead
of built-in search.
Kevin Monceaux
> I guess your post should be replaced by my first one :). It's exactly
> what I was trying to say: django need a reference manual to complement
> the existing documentation.
Do you mean like the reference manual one can build from Django
source? I think it can be built in several formats. I've only tried
the PDF version myself. The PDF manual for Django 1.2.3 weighs in at 945
pages, complete with index. Chapter 5 is titled API Reference.
Kevin Monceaux
> Do you mean like the reference manual one can build from Django
> source?
The above wasn't entirely clear. I meant the manual one can build
from the documentation source code which is included the Django source
tarball.
Doug Ballance
Compared to everything out there, it was incredible. Back then it
also had a helpful comments section on each page where people chimed
in to clarify various parts of the document. It reads like a text
book, which is a big help when learning the framework.
Unfortunately it reads like a text book, which is a big pain when you
know the story and just need the details. The wonderful code snippets
lose their context. The lengthy explanations and sequential
introduction of facts becomes more hinderence than help when trying to
find that one bit you know is in there somewhere, but it's a needle in
a haystack. It's designed for reading, not so much for reference.
It's also definitely not for the impatient.
After several years with Django, I usually find it easier to just poke
around the source. It's all layed out logically and, and if you have a
general overview of the framework it's much faster than trying to scan
through the online docs. Unfortunately this approach requires a
certain level of familiarity with how django works to get the most out
of it.
A few things I think would help make a big difference (they would have
to me at least):
1) A couple of complete reference examples. Not just snippets
introduced a few lines at a time, but full working examples you can
unzip and expect to work and provide a simple reference to the basics.
I've been using django for 3 years now in developing a fairly complex
project. I'm still not 100% clear on the best way to layout a
project. What I have obviously works, and I'm stuck with it now...
but it was a guess back when I first started. I realize there is no
one size fits all answer for that type of question, but a tiny working
example with one project and two apps would go along way to providing
someone first starting out, especially if the projects did simple
introductions to all the major topics: a view, a view with an
authentication decorator, a good example of template inheritance use
to 'theme' a site, a few of forms, severa of which don't use a helper
(ie no ModelForm) and requires some inter-field validation, maybe a
simple middlware that reads/writes a cookie. A custom tag/filter or
two. Something that showcases the "admin is not your app" principle.
I really would love to do this, but I'm a little concerned it would
turn out to be a bad example here and there! If there is interest I'd
volunteer to give it a go though.
2) An overview of how django processes a request. From start to
finish, concise on one page with links to the appropriate details if
necessary. Possibly a paragraph or two explaining how it differs from
say php. In my opinion this should be the first page of the
documentation, well before the tutorial. The following page is
ancient, but a good example of what I mean. It wasn't until I read it
that everything just kinda clicked. Too bad it took a good 6 months
for me to run across it more or less on accident.
http://www.b-list.org/weblog/2006/jun/13/how-django-processes-request/
3) The page comments for the existing documentation. I really miss
that feature. The comment system PHP uses improves their
documentation many times over. With Django's great community I'm sure
we'd get a lot of good additions, though moderating the comments makes
more work for someone.
4) A small 'best practices' reference not about the django details,
but the big picture. Using virtualev. Project layout. Admin vs
app. Considerations to keep in mind for writing reusable apps.
Production vs Development configurations and switching. Handling
timezone conversions. Avoiding performance pitfalls when using orm
queries. Signals, how they can be useful.
derek
Framework (open source) for nearly 10 years, I can say with confidence
that Django's human-written documentation is superb. The ALWF
documentation was never kept up-to-date (and the online API did not
really help much) - the user's had a wiki which attempted to fill that
gap but ended up exactly as per Jame's comments: "the wiki is where
Maybe the Django project/development team is making an unreasonable
assumption that people cannot generate the API using the appropriate
Python tools... assuming enough people feel this way, there is nothing
preventing any one of them from tackling this and putting it on a
website for the rest to browse. If you have enough gumption to work
with an open source project this should be readily "doable".
On Jan 11, 9:55 am, James Bennett <ubernost...@gmail.com> wrote:
ashwoods
that django has excellent high level docs (django docs site) and low
lvl docs (code is well py-documented -in the source). Epydocs, and
other doc alternatives - automatic or semi automatic doc generators
like pydoctor, sphinx (a quick google search revealed quite a few free
and nonfree python doc generators) are what i consider standard
(python) programming tools, and it actually makes sense for the
developer to do this "client" side (3rd party libaries, etc... all in
one interface, and for the code version you are using, for example).
The difficult, hard to write human documentation in django is
excellent, btw :p
all that said, maybe we can take a look at trac plugins...
http://trac-hacks.org/wiki/PyDocPlugin
http://trac.edgewall.org/wiki/TracDev/ApiDocs
i have no experience with them, maybe someone here has used them
before?
cheers,
ashley
Mike Dewhirst
of a typical* developer transitioning from beginner to guru and the docs
which should be of interest at successive stages during that transition.
*typical - I know there ain't such a person. However, there ought to be
a "target audience" the Django Foundation wants to reach. That person
becomes the target audience for the intro and gets described in the
intro to the intro.
If the intro works other "typical" devs can be described for alternative
intros. Too meta huh?
Problem is there are too many small operators who need more than Django.
Such as aesthetic guidance, CSS etc etc
It's a quite daunting curve but really all anyone needs is to know where
to find the docs appropriate to their current stage.
How about a survey where people tick boxes which describe where they
currently sit on the continuum so that existing gurus can see how the
first "typical" dev can be described.
BTW - Django docs rock.
Mike
Rainy
On Jan 12, 7:18 am, Mike Dewhirst <mi...@dewhirst.com.au> wrote:
> OK - so we need an intro to the documention which describes the timeline
> of a typical* developer transitioning from beginner to guru and the docs
> which should be of interest at successive stages during that transition.
>
> *typical - I know there ain't such a person. However, there ought to be
> a "target audience" the Django Foundation wants to reach. That person
> becomes the target audience for the intro and gets described in the
> intro to the intro.
>
> If the intro works other "typical" devs can be described for alternative
> intros. Too meta huh?
>
> Problem is there are too many small operators who need more than Django.
> Such as aesthetic guidance, CSS etc etc
>
> It's a quite daunting curve but really all anyone needs is to know where
> to find the docs appropriate to their current stage.
>
> How about a survey where people tick boxes which describe where they
> currently sit on the continuum so that existing gurus can see how the
> first "typical" dev can be described.
on this list and on stackoverflow. Something like:
In last 2 years:
total: x questions
admin: 250/x
views: ...
templates: ...
(but with more detailed subcategories).
If anyone has done this, please share because this would be
very useful to all django doc/tutorial authors.
-ak