It's Important.

Just as Code Style, API Design, and Automation are essential for a healthy development cycle, Repository structure is a crucial part of your project's architecture.

When a potential user or contributor lands on your repository's page, they see
a few things:

Project Name

Project Description

Bunch O' Files

Only when they scroll below the fold will the user see your project's README.

If your repo is a massive dump of files or a nested mess of directories, they
might look elsewhere before even reading your beautiful documentation.

Dress for the job you want, not the job you have.

Of course, first impressions aren't everything. You and your colleagues will
spend countless hours working with this repository, eventually becoming
intimately familiar with every nook and cranny. The layout of it is important.

Test Suite

Once a test suite grows, you can move your tests to a directory, like so:

tests/test_basic.py
tests/test_advanced.py

Obviously, these test modules must import your packaged module to test it. You
can do this a few ways:

Expect the package to be installed in site-packages.

Use a simple (but explicit) path modification to resolve the package properly.

I highly recommend the latter. Requiring a developer to run
setup.py develop to test an actively changing codebase also
requires them to have an isolated environment setup for each instance of the
codebase.

Some people will assert that you should distribute your tests within your
module itself -- I disagree. It often increases complexity for your users;
many test suites often require additional dependencies and runtime contexts.

Makefile

Location: ./Makefile
Purpose: Generic management tasks.

If you look at most of my projects or any Pocoo project, you'll notice a
Makefile laying around. Why? These projects aren't written in C... In short,
make is a incredibly useful tool for defining generic and platform agnostic
tasks for your project.

Sample Makefile:

init:
pip install -r requirements.txt
test:
py.test tests

Other generic management scripts (e.g. manage.py or
fabfile.py) belong at the root of the repository as well.

Regarding Django Applications

I've noticed a new trend in Django applications since the release of Django
1.4. Many developers are structuring their repositories poorly due to the new
bundled application templates.

How? Well, they go to their bare and fresh repository and run the following,
as they always have: