Added buildout stuff and made changes accordingly

--HG--
rename : profile/management/__init__.py => eggs/djangorecipe-0.20-py2.6.egg/EGG-INFO/dependency_links.txt
rename : profile/management/__init__.py => eggs/djangorecipe-0.20-py2.6.egg/EGG-INFO/not-zip-safe
rename : profile/management/__init__.py => eggs/infrae.subversion-1.4.5-py2.6.egg/EGG-INFO/dependency_links.txt
rename : profile/management/__init__.py => eggs/infrae.subversion-1.4.5-py2.6.egg/EGG-INFO/not-zip-safe
rename : profile/management/__init__.py => eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/EGG-INFO/dependency_links.txt
rename : profile/management/__init__.py => eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/EGG-INFO/not-zip-safe
rename : profile/management/__init__.py => eggs/py-1.4.0-py2.6.egg/EGG-INFO/dependency_links.txt
rename : profile/management/__init__.py => eggs/py-1.4.0-py2.6.egg/EGG-INFO/not-zip-safe
rename : profile/management/__init__.py => eggs/zc.buildout-1.5.2-py2.6.egg/EGG-INFO/dependency_links.txt
rename : profile/management/__init__.py => eggs/zc.buildout-1.5.2-py2.6.egg/EGG-INFO/not-zip-safe
rename : profile/management/__init__.py => eggs/zc.recipe.egg-1.3.2-py2.6.egg/EGG-INFO/dependency_links.txt
rename : profile/management/__init__.py => eggs/zc.recipe.egg-1.3.2-py2.6.egg/EGG-INFO/not-zip-safe
rename : profile/management/__init__.py => parts/django/Django.egg-info/dependency_links.txt
rename : taskapp/models.py => parts/django/django/conf/app_template/models.py
rename : taskapp/tests.py => parts/django/django/conf/app_template/tests.py
rename : taskapp/views.py => parts/django/django/conf/app_template/views.py
rename : taskapp/views.py => parts/django/django/contrib/gis/tests/geo3d/views.py
rename : profile/management/__init__.py => parts/django/tests/modeltests/delete/__init__.py
rename : profile/management/__init__.py => parts/django/tests/modeltests/files/__init__.py
rename : profile/management/__init__.py => parts/django/tests/modeltests/invalid_models/__init__.py
rename : profile/management/__init__.py => parts/django/tests/modeltests/m2m_signals/__init__.py
rename : profile/management/__init__.py => parts/django/tests/modeltests/model_package/__init__.py
rename : profile/management/__init__.py => parts/django/tests/regressiontests/bash_completion/__init__.py
rename : profile/management/__init__.py => parts/django/tests/regressiontests/bash_completion/management/__init__.py
rename : profile/management/__init__.py => parts/django/tests/regressiontests/bash_completion/management/commands/__init__.py
rename : profile/management/__init__.py => parts/django/tests/regressiontests/bash_completion/models.py
rename : profile/management/__init__.py => parts/django/tests/regressiontests/delete_regress/__init__.py
rename : profile/management/__init__.py => parts/django/tests/regressiontests/file_storage/__init__.py
rename : profile/management/__init__.py => parts/django/tests/regressiontests/max_lengths/__init__.py
rename : profile/forms.py => pytask/profile/forms.py
rename : profile/management/__init__.py => pytask/profile/management/__init__.py
rename : profile/management/commands/seed_db.py => pytask/profile/management/commands/seed_db.py
rename : profile/models.py => pytask/profile/models.py
rename : profile/templatetags/user_tags.py => pytask/profile/templatetags/user_tags.py
rename : taskapp/tests.py => pytask/profile/tests.py
rename : profile/urls.py => pytask/profile/urls.py
rename : profile/utils.py => pytask/profile/utils.py
rename : profile/views.py => pytask/profile/views.py
rename : static/css/base.css => pytask/static/css/base.css
rename : taskapp/tests.py => pytask/taskapp/tests.py
rename : taskapp/views.py => pytask/taskapp/views.py
rename : templates/base.html => pytask/templates/base.html
rename : templates/profile/browse_notifications.html => pytask/templates/profile/browse_notifications.html
rename : templates/profile/edit.html => pytask/templates/profile/edit.html
rename : templates/profile/view.html => pytask/templates/profile/view.html
rename : templates/profile/view_notification.html => pytask/templates/profile/view_notification.html
rename : templates/registration/activate.html => pytask/templates/registration/activate.html
rename : templates/registration/activation_email.txt => pytask/templates/registration/activation_email.txt
rename : templates/registration/activation_email_subject.txt => pytask/templates/registration/activation_email_subject.txt
rename : templates/registration/logged_out.html => pytask/templates/registration/logged_out.html
rename : templates/registration/login.html => pytask/templates/registration/login.html
rename : templates/registration/logout.html => pytask/templates/registration/logout.html
rename : templates/registration/password_change_done.html => pytask/templates/registration/password_change_done.html
rename : templates/registration/password_change_form.html => pytask/templates/registration/password_change_form.html
rename : templates/registration/password_reset_complete.html => pytask/templates/registration/password_reset_complete.html
rename : templates/registration/password_reset_confirm.html => pytask/templates/registration/password_reset_confirm.html
rename : templates/registration/password_reset_done.html => pytask/templates/registration/password_reset_done.html
rename : templates/registration/password_reset_email.html => pytask/templates/registration/password_reset_email.html
rename : templates/registration/password_reset_form.html => pytask/templates/registration/password_reset_form.html
rename : templates/registration/registration_complete.html => pytask/templates/registration/registration_complete.html
rename : templates/registration/registration_form.html => pytask/templates/registration/registration_form.html
rename : utils.py => pytask/utils.py

1 files changed, 102 insertions, 0 deletions

diff --git a/parts/django/docs/faq/contributing.txt b/parts/django/docs/faq/contributing.txt
new file mode 100644
index 0000000..81c06f3
--- /dev/null
+++ b/parts/django/docs/faq/contributing.txt
@@ -0,0 +1,102 @@
+FAQ: Contributing code
+======================
+
+How can I get started contributing code to Django?
+--------------------------------------------------
+
+Thanks for asking! We've written an entire document devoted to this question.
+It's titled :doc:`Contributing to Django </internals/contributing>`.
+
+I submitted a bug fix in the ticket system several weeks ago. Why are you ignoring my patch?
+--------------------------------------------------------------------------------------------
+
+Don't worry: We're not ignoring you!
+
+It's important to understand there is a difference between "a ticket is being
+ignored" and "a ticket has not been attended to yet." Django's ticket system
+contains hundreds of open tickets, of various degrees of impact on end-user
+functionality, and Django's developers have to review and prioritize.
+
+On top of that: the people who work on Django are all volunteers. As a result,
+the amount of time that we have to work on the framework is limited and will
+vary from week to week depending on our spare time. If we're busy, we may not
+be able to spend as much time on Django as we might want.
+
+The best way to make sure tickets do not get hung up on the way to checkin is
+to make it dead easy, even for someone who may not be intimately familiar with
+that area of the code, to understand the problem and verify the fix:
+
+    * Are there clear instructions on how to reproduce the bug? If this
+      touches a dependency (such as PIL), a contrib module, or a specific
+      database, are those instructions clear enough even for someone not
+      familiar with it?
+
+    * If there are several patches attached to the ticket, is it clear what
+      each one does, which ones can be ignored and which matter?
+
+    * Does the patch include a unit test? If not, is there a very clear
+      explanation why not? A test expresses succinctly what the problem is,
+      and shows that the patch actually fixes it.
+
+If your patch stands no chance of inclusion in Django, we won't ignore it --
+we'll just close the ticket. So if your ticket is still open, it doesn't mean
+we're ignoring you; it just means we haven't had time to look at it yet.
+
+When and how might I remind the core team of a patch I care about?
+------------------------------------------------------------------
+
+A polite, well-timed message to the mailing list is one way to get attention.
+To determine the right time, you need to keep an eye on the schedule. If you
+post your message when the core developers are trying to hit a feature
+deadline or manage a planning phase, you're not going to get the sort of
+attention you require. However, if you draw attention to a ticket when the
+core developers are paying particular attention to bugs -- just before a bug
+fixing sprint, or in the lead up to a beta release for example -- you're much
+more likely to get a productive response.
+
+Gentle IRC reminders can also work -- again, strategically timed if possible.
+During a bug sprint would be a very good time, for example.
+
+Another way to get traction is to pull several related tickets together. When
+the core developers sit down to fix a bug in an area they haven't touched for
+a while, it can take a few minutes to remember all the fine details of how
+that area of code works. If you collect several minor bug fixes together into
+a similarly themed group, you make an attractive target, as the cost of coming
+up to speed on an area of code can be spread over multiple tickets.
+
+Please refrain from emailing core developers personally, or repeatedly raising
+the same issue over and over. This sort of behavior will not gain you any
+additional attention -- certainly not the attention that you need in order to
+get your pet bug addressed.
+
+But I've reminded you several times and you keep ignoring my patch!
+-------------------------------------------------------------------
+
+Seriously - we're not ignoring you. If your patch stands no chance of
+inclusion in Django, we'll close the ticket. For all the other tickets, we
+need to prioritize our efforts, which means that some tickets will be
+addressed before others.
+
+One of the criteria that is used to prioritize bug fixes is the number of
+people that will likely be affected by a given bug. Bugs that have the
+potential to affect many people will generally get priority over those that
+are edge cases.
+
+Another reason that bugs might be ignored for while is if the bug is a symptom
+of a larger problem. While we can spend time writing, testing and applying
+lots of little patches, sometimes the right solution is to rebuild. If a
+rebuild or refactor of a particular component has been proposed or is
+underway, you may find that bugs affecting that component will not get as much
+attention. Again, this is just a matter of prioritizing scarce resources. By
+concentrating on the rebuild, we can close all the little bugs at once, and
+hopefully prevent other little bugs from appearing in the future.
+
+Whatever the reason, please keep in mind that while you may hit a particular
+bug regularly, it doesn't necessarily follow that every single Django user
+will hit the same bug. Different users use Django in different ways, stressing
+different parts of the code under different conditions. When we evaluate the
+relative priorities, we are generally trying to consider the needs of the
+entire community, not just the severity for one particular user. This doesn't
+mean that we think your problem is unimportant -- just that in the limited
+time we have available, we will always err on the side of making 10 people
+happy rather than making 1 person happy.