Version 24 (modified by Kenneth Gonsalves, 8 years ago) (diff)




The django-users@… is the primary source for help on using Django. However many users are unable to get full mileage from the list as they are inexperienced in formulating their questions and in interacting with the list members. This page seeks to address this problem. Many members of the list, including core developers, take a lot of time and trouble to patiently answer questions asked, and we users should take as much trouble to ask properly formulated questions. Try to follow the steps outlined below to make for a more pleasant and rewarding experience on the list.

Classify your question

There are different types of questions, each type requires a different level of detail. The most common type is about problem solving, and most of this page is devoted to this. Other types are:

Does Django have a particular feature?

Wrong way:

Does Django have scaffolding like rails?

Here you assume that everyone knows what rails is and what scaffolding is. Or you expect users to waste their time investigating. Do not do this. Explain what this feature is and what it does. Right way:

Foo framework has a feature that automatically generates html given certain keywords like
 'abc' generates an 'xyz' widget, does Django have this feature?

Is Django suitable for the app I want to build

Questions on best practices

Do your homework!!

  • Most of the time, Google holds the answer to your question.
  • Don't expect a 'one-shot / copy-and-paste' answer, there may be some work involved.
  • Don't give up on the first page, it's not unusual to go as far as 400-600 results (depending on how relevant each hit is)
  • Make full use of exception tracebacks, and don't be afraid to dive deep into the Django core code (this is a great way to learn + find hints about what caused your problem)
  • Look through the django-users mailing list archive ( )

Be imaginative with your Google keywords

If you are looking for information relating to say "Sphinx", just typing that in alone usually won't help.

Here are some common search alternatives you could try;

  • Looking for a method/class called 'ReportBug'
    ReportBug python
    "def ReportBug"
    "class ReportBug"
  • Looking for items relating to Django models
    "Django (model|models)"
    "from django" "import models"
    "howto" django models
    "problem with" django models
  • Look for other peoples mailing list entries about MySQLdb
    "django-users" "(problem|exception)" "MySQLdb"
  • Be smart when it comes to looking for information about exceptions:
    For example:
    OperationalError: (2002, "Can't connect to local MySQL server through 
    socket '/var/run/mysqld/mysqld.sock' (2)")
    Would become:
    django "OperationalError" "2002"
    "connect to local MySQL server through"
    "OperationalError" "connect to local MySQL server through"
    django "problem" "2002" "database"

More on where and how to search

The documentation is the best place to search. The only problem is that the search bar in the docs does not work well on multiple keywords. A search for date range will not give you the desired result. For this use the 'site' option in search engines like duckduckgo -

The other place to search is the mailing list. If you *must* search blogs or forums, make sure that you check the date of the post and the django version before complaining that it doesn't work.

Note that the documentation is excellent, but not perfect. It is mostly written by developers, and they often leave out things that are glaringly obvious to them, but not so obvious to the end user. At the same time they are very receptive when this is pointed out by us. Do file a document bug if you come across such problems.

Prepare the question


  • Put a meaningful subject line - 'newbie needs help' *may* bring you a donation, but is otherwise useless. Use the keywords you used in your search.
  • Indicate what your end goal is (or is not)
  • Include tracebacks (where applicable; especially if there is an error). Make sure you *paste* the *full* traceback. Do not worry about using up space - you are not paying for it.
  • Include a tested example of the code you are using.
  • Do not obfuscate your code or invent code snippets - if you are reading this, your code is not rocket science and no one is going to steal it. Probably no one will take it even if you pay them.
  • Indicate what attempts you have made to resolve the problem/issue yourself
  • Ask yourself, what extra information might you need to resolve similar problems?
  • Proofread your e-mail multiple times, rewriting for clarity and brevity as needed. You will greatly increase the chances of both getting help and figuring own your stumbling block this way.
  • If you post on a Friday or a weekend wait till people have a chance to get over their Monday hangover before expecting a reply.


  • Expect an instant or one-shot answer. (django-users is *NOT* your personal tutor.)
  • Be vague e.g. "please help build a website"
  • Keep repeating the same question - if anyone has an answer, you will get it sooner or later.
  • Use the phrase 'it doesn't work'. The most common question on IRC is: 'What does doesn't work mean?'


For many of us, English is not our native language. Try to follow English syntax, but do not waste everyone's time by apologising. People will realise your difficulty and will ask for clarification if needed. However avoid using 'sms-speak' and refrain from being overly casual.


i wan 2 make cms pls cn u hlp asap

Formatting your mail and your replies

Realise that not all users use gmail, and include sufficient context to make sure that the user does not have to waste his time searching the archives to find out what you are talking about. This means quoting enough of the mail you are replying to make your reply understandable and replying under the quoted matter. Example:


The following code does not work.

(code here)
(error here)

two answers

> The following code does not work.
> (code here)
> (error here) 

you have left out a comma in line 7
> The following code does not work.
> (code here)
> (error here) 

correct the typo in line 3

The wrong way to reply

I tried, but it is still giving the same error.

who are you replying to?

the right way

> > The following code does not work.
> > 
> > (code here)
> > (error here) 
> you have left out a comma in line 7 

I tried, but it is still giving the same error.

Follow up

  • Always make an effort to say thank you.
  • If you feel someone did not understand your request (or gives an unrelated answer), then it's important you express this to them, and clarify further.

Report resolution

  • Always make an effort to make your findings public. This may be in the form of a Django core ticket,, blog post, youtube video etc. (Although sometimes, if the mailing list subject is descriptive enough, it may suffice to just have it in archive - which happens automatically)

Start answering questions

  • Give something back to the community by answering questions you feel confident in.

Real examples of how to ask questions properly

Real examples of how not to ask questions

Question is vague, with no thought behind it.

Question is vague, a simple Google would have yielded the answers OP needed.

OP did not include any code about how to re-produce the bug, and did not test on latest clean code for Django.

OP was extremely vague. See "Tom Evans" response for full reasoning on why OPs post is considered bad.

OP posted a question which was not related to Django/Python (or at the very least, had a very lose relation).

OP posted a question which Google answered very easily. Shows lack of intuition/laziness. Question also wasn't appropriate for this list.

How to answer questions on the list

  • we were all newbies once - if you feel a question is too trivial to answer, do not flame - ignore the post.
  • ideally everyone who uses django should know the basics of python, html, css, SQL and the http protocol. But we do not live in an ideal world. If a post shows lack of such knowledge, gently point the poster to resources that would help.
  • 90% of errors are explained in the last line of the traceback - this is not intuitive. The rest of the traceback needs an experienced hand to interpret. Educate users on the last line.
Back to Top