GitHub PullRequestReviewCommentEvent at 2014-11-16 22:25:09
Repository: deps
Actor: timgraham
Payload: {"action":"created","comment":{"url":"https://api.github.com/repos/django/deps/pulls/comments/20413878","id":20413878,"diff_hunk":"@@ -0,0 +1,498 @@\n+=================================\n+DEP 1: DEP Purpose and Guidelines\n+=================================\n+\n+:DEP: 1\n+:Author: Adrian Holovaty, Jacob Kaplan-Moss\n+:Status: Final\n+:Type: Process\n+:Created: 2014-04-14\n+:Last-Modified: 2014-11-15 \n+\n+.. contents:: Table of Contents\n+   :depth: 3\n+   :local:\n+\n+What is a DEP?\n+==============\n+\n+DEP stands for Django Enhancement Proposal. A DEP is a design document\n+providing information to the Django community, or describing a new feature\n+or process for Django. DEPs provide concise technical specifications of\n+features, along with rationales.\n+\n+We intend DEPs to be the primary mechanisms for proposing major new features,\n+for collecting community input on issues, and for documenting design\n+decisions that have gone into Django.\n+\n+The concept and implementation of DEPs (and this document itself!) is a nearly\n+direct copy of `Python's PEP process <https://www.python.org/dev/peps/>`_ . If\n+you're already familiar with PEPs, you should be able to quickly grok DEPs by\n+reading the `differences between DEPs and PEPs`_.\n+\n+DEP Types\n+=========\n+\n+There are three kinds of DEPs:\n+\n+1. A **Feature** DEP describes a new feature or implementation\n+   for Django. Most DEPs will be Feature DEPs.\n+\n+2. An **Informational** DEP describes a Django design issue, or\n+   provides general guidelines or information to the Django community,\n+   but does not propose a new feature. Informational DEPs do not\n+   necessarily represent a community consensus or\n+   recommendation, so users and implementers are free to ignore\n+   Informational DEPs or follow their advice.\n+\n+3. A **Process** DEP describes a process surrounding Django, or\n+   proposes a change to (or an event in) a process.  Process DEPs are\n+   like Feature DEPs but apply to areas other than the Django\n+   framework itself.  They may propose an implementation, but not to\n+   Django's codebase; they often require community consensus; unlike\n+   Informational DEPs, they are more than recommendations, and users\n+   are typically not free to ignore them.  Examples include\n+   procedures, guidelines, changes to the decision-making process, and\n+   changes to the tools or environment used in Django development.\n+   Any meta-DEP is also considered a Process DEP. (So this document\n+   is a Process DEP).\n+\n+DEP submission workflow\n+=======================\n+\n+So, you'd like to submit a DEP? Here's how it works, and what to expect.\n+\n+There are a couple of terms you should be familiar with before reading the\n+rest of this document:\n+\n+The Technical Board\n+    There are several reference in this DEP to the **Technical Board**\n+    (sometimes just \"the Board\"). This refers to Django's `Technical Board\n+    <https://docs.djangoproject.com/en/dev/internals/organization/#technical-\n+    board>`_, the group of experienced and active committers who steer technical\n+    choices. Django's documentation lists `the current Technical Board\n+    membership <https://docs.djangoproject.com/en/dev/internals/roles\n+    /#technical-board>`_.\n+\n+Core Developers\n+    Similarly, there are several references to **Core Developers** (sometimes\n+    \"core devs\"). This refers to the members of Django's `core team\n+    <https://docs.djangoproject.com/en/dev/internals/organization/#core-team>`_,\n+    and specifically those with `commit access\n+    <https://docs.djangoproject.com/en/dev/internals/roles/#committers>`_.\n+\n+At a very high level, the DEP submission process looks like this:\n+\n+1. `Pre-proposal`_ — someone has an idea and starts collecting early input and\n+   feedback to see if it's worth writing a DEP.\n+\n+2. `Forming the team`_ — the DEP author rounds up the help they'll need to get\n+   the DEP considered.\n+\n+3. `Submitting the draft`_ — the DEP author writes a rough draft of the DEP and\n+   submits it via pull request.\n+\n+4. `Discussion, development, and updates`_ — the DEP and reference\n+   implementation are discussed, improved, and updated as feedback comes in.\n+\n+5. `Review & Resolution`_ — the DEP is reviewed by the Technical Board and\n+   either accepted or rejected.\n+\n+6. `Implementation`_ — the implementation of the proposed feature is completed\n+   by the DEP team.\n+\n+For details on each step, read on.\n+\n+Pre-proposal\n+------------\n+\n+The DEP process begins with a new idea for Django.  It is highly recommended\n+that a single DEP contain a single key proposal or new idea. Small enhancements\n+or patches often don't need a DEP and can be processed as following Django's\n+normal `contribution process\n+<https://docs.djangoproject.com/en/dev/internals/contributing/>`_.\n+\n+The more focused the DEP, the more successful it tends to be.  The Core\n+Developers reserve the right to reject DEP proposals if they appear too\n+unfocused or too broad.  If in doubt, split your DEP into several well-focused\n+ones.\n+\n+The DEP Author (see below for the formal definition of an Author)\n+should first attempt to ascertain whether the idea is DEP-able.  Posting to\n+`django- developers <https://docs.djangoproject.com/en/dev/internals/mailing-\n+lists /#django-developers-mailing-list>`_ is the best way to go about this.\n+\n+Vetting an idea publicly before going as far as writing a DEP is meant to save\n+the potential author time. Many ideas have been brought forward for changing\n+Django that have been rejected for various reasons. Asking the Django community\n+first if an idea is original helps prevent too much time being spent on\n+something that is guaranteed to be rejected based on prior discussions\n+(searching the Internet does not always do the trick). It also helps to make\n+sure the idea is applicable to the entire community and not just the author.\n+Just because an idea sounds good to the author does not mean it will work for\n+most people in most areas where Django is used.\n+\n+Forming the team\n+----------------\n+\n+Once a DEP has been roughly validated, the author needs to fill out three vital\n+roles. These roles will be required to get a DEP read, approved, and the code\n+developed, so you need to identify up-front who will do what. These roles are:\n+\n+Author\n+    The **Author** writes the DEP using the style and format described below\n+    (see `DEP format`_), shepherds the discussions in the appropriate forums,\n+    and attempts to build community consensus around the idea.\n+\n+Implementation Team\n+    The **Implementation Team** are the people (or single person) who will\n+    actually implement the thing being proposed. A DEP may have multiple\n+    implementors (and the best DEPs probably will).\n+\n+    Feature DEPs must have an implementation team to be submitted. Informational\n+    DEPs generally don't have implementors, and Process DEPs sometimes will.\n+\n+Shepherd\n+    The **Shepherd** is the Core Developer who will be the primary reviewer\n+    of the DEP on behalf of the Django team, will be the main point person\n+    who will help the Author assess the fitness of their proposal, and\n+    is the person who will finally submit the DEP for pronouncement by the\n+    Technical Board. When the implementation team doesn't contain someone\n+    who can commit to Django, the Shepherd will be the one who actually merges\n+    the code into the project. \n+\n+It's normal for a single person to fulfill multiple roles -- in most cases the\n+Author will be an/the Implementor, and it's not uncommon for the implementation\n+team to include the Shepherd as well. It's unusual but acceptable for a single\n+person to fulfill all roles, though this generally only happens when that person\n+is a long-time committer.\n+\n+Submitting the draft\n+--------------------\n+\n+Once the idea's been vetted, and the roles are filled a draft DEP should be\n+presented to django-developers. This gives the author a chance to flesh out the\n+draft DEP to make properly formatted, of high quality, and to address initial\n+concerns about the proposal.\n+\n+Following the discussion on django-developers, the proposal should be sent as a\n+Github pull request to the `django/deps <https://github.com/django/deps>`_ repo.\n+This PR should add a DEP to the ``drafts/`` directory, written in the style\n+described below. The draft must be written in DEP style; if it isn't the pull\n+request may be rejected until proper formatting rules are followed.\n+\n+At this point, a core dev will review the pull request. In most cases the\n+reviewer will be the Shepherd of the DEP, but if that's not possible for some\n+reason the author may want to ask on django-developers to ensure that this\n+review happens quickly. The reviewer will do the following:\n+\n+* Read the DEP to check if it is ready: sound and complete.  The ideas\n+  must make technical sense, even if they don't seem likely to be\n+  accepted.\n+\n+* Make sure the title accurately describes the content.\n+\n+* Check the DEP for language (spelling, grammar, sentence structure,\n+  etc.), markup (for reST DEPs), and code style (examples should match PEP 8).\n+\n+If the DEP isn't ready, the reviewer can leave comments on the pull request,\n+asking for further revisions. If the DEP's really in bad form, the reviewer\n+may reject the pull request outright and ask the author to submit a new one\n+request once the problems have been fixed.\n+\n+The reviewer doesn't pass judgment on DEPs.  They merely do the administrative &\n+editorial part (which is generally a low volume task).\n+\n+Once the DEP is ready for the repository, the reviewer will:\n+\n+* Merge the pull request.\n+\n+* Assign a DEP number (almost always just the next available number), and rename\n+  the DEP file with the new number (e.g. rename ``dep-process.rst`` to \n+  ``0001-dep-process.rst``)\n+\n+Developers with commit access to the DEPs repo may create drafts directly by\n+committing and pushing a new DEP. However, when doing so they need to take on\n+the tasks normally handled by the reviewer described above. This includes\n+ensuring the initial version meets the expected standards for submitting a DEP.\n+Alternately, even developers may choose to submit DEPs as a pull request.\n+\n+Discussion, development, and updates\n+------------------------------------\n+\n+At this point there will generally be more discussion, modifications to the\n+reference implementation, and of course updates to the DEP. It's rare for\n+a DEP to be judged on the first draft; far more common is several rounds\n+of feedback and updates.\n+\n+Updates to a DEP can be submitted as pull requests; once again,\n+a core developer will merge those pull requests (typically they don't\n+require much if any review). In cases where the Author has commit access\n+(fairly common), the Author should just update the draft DEP directly.\n+\n+Features DEPs generally consist of two parts, a design document and a\n+reference implementation.  It is generally recommended that at least a\n+prototype implementation be co-developed with the DEP, as ideas that sound\n+good in principle sometimes turn out to be impractical when subjected to the\n+test of implementation.\n+\n+DEP authors are responsible for collecting community feedback on a DEP\n+before submitting it for review. However, wherever possible, long\n+open-ended discussions on public mailing lists should be avoided.\n+Strategies to keep the discussions efficient include: setting up a\n+separate mailing list for the topic, having the DEP author accept\n+private comments in the early design phases, setting up a wiki page, etc.\n+DEP authors should use their discretion here.\n+\n+Review & Resolution\n+-------------------\n+\n+Once the author has completed a DEP, the shepherd will ask the Technical Board\n+for review and pronouncement. The final authority for deciding on a DEP rests\n+with the Technical Board. They may choose to rule on a DEP as a team, or they\n+may designate one or more board members to review and decide.\n+\n+[Having the shepherd (i.e. a core dev) ask rather than the author helps ensure\n+that the DEP the basic technical bar before it's called for review. It also\n+provides a fairly strong fitness test before the board is asked to rule on it,\n+making board rulings fairly easy. if the core developer shepherd is happy, the\n+board will likely be as well.]\n+\n+For a DEP to be accepted it must meet certain minimum criteria.  It must be a\n+clear and complete description of the proposed enhancement. The enhancement must\n+represent a net improvement. The proposed implementation, if applicable, must be\n+solid and must not complicate Django unduly. Finally, a proposed enhancement\n+must \"fit\" with Django's general philosophy and architecture. This last category\n+is the most imprecise and takes the most judgment, so if the Board rejects a\n+DEP for lack of \"fit\" they should provide a clear explanation for why.\n+\n+At this point, the DEP will be considered \"Accepted\" and moved to the\n+``accepted`` directory in the DEPs repo.\n+\n+A DEP can also be \"Withdrawn\".  The DEP author or a core developer can assign\n+the DEP this status when the author is no longer interested in the DEP, or if no\n+progress is being made on the DEP.  Once a DEP is withdrawn, it's moved\n+to the ``withdrawn`` directory for reference. Later, another author may\n+resurrect the DEP by opening a pull request, updating (at least) the author,\n+and moving it back to ``draft``.\n+\n+Finally, a DEP can also be \"Rejected\".  Perhaps after all is said and done it\n+was not a good idea.  It is still important to have a record of this\n+fact. Rejected DEPs will be moved to the ``rejected`` directory, and\n+generally should be updated with a rationale for rejection.\n+\n+DEPs can also be superseded by a different DEP, rendering the original\n+obsolete.  This is intended for Informational DEPs, where version 2 of\n+an API can replace version 1.\n+\n+Implementation\n+--------------\n+\n+Finally, once a DEP has been accepted, the implementation must be completed. In\n+many cases some (or all) implementation will actually happen during the DEP\n+process: Feature DEPs will often have fairly complete implementations before\n+being reviewed by the board. When the implementation is complete and\n+incorporated into the main source code repository, the status will be changed to\n+\"Final\" and the DEP moved to the ``final`` directory.\n+\n+DEP format\n+==========\n+\n+To save everyone time reading DEPs, they need to follow a common format\n+and outline; this section describes that format. In most cases, it's probably\n+easiest to start with copying the provided `DEP template <../template.rst>`_,\n+and filling it in as you go. \n+\n+DEPs must be written in `reStructuredText <http://docutils.sourceforge.net/rst.html>`_ \n+(the same format as Django's documentation). \n+\n+Each DEP should have the following parts:\n+\n+#. A short descriptive title (e.g. \"ORM expressions\"), which is also reflected\n+   in the DEP's filename (e.g. ``0181-orm-expressions.rst``).\n+\n+#. A preamble -- a rST `field list <http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#field-lists>`_ \n+   containing metadata about the DEP, including the DEP number, the names of the\n+   various members of the `DEP team <#forming- the-team>`_, and so forth. See\n+   `DEP Metadata`_ below for specific details.\n+\n+#. Abstract -- a short (~200 word) description of the technical issue\n+   being addressed.\n+\n+#. Specification -- The technical specification should describe the syntax and\n+   semantics of any new feature.  The specification should be detailed enough to\n+   allow implementation -- that is, developers other than the author should\n+   (given the right experience) be able to independently implement the feature,\n+   given only the DEP.\n+\n+#. Motivation -- The motivation is critical for DEPs that want to add\n+   substantial new features or materially refactor existing ones.  It should\n+   clearly explain why the existing solutions are inadequate to address the\n+   problem that the DEP solves.  DEP submissions without sufficient motivation\n+   may be rejected outright.\n+\n+#. Rationale -- The rationale fleshes out the specification by describing what\n+   motivated the design and why particular design decisions were made.  It\n+   should describe alternate designs that were considered and related work.\n+\n+   The rationale should provide evidence of consensus within the community and\n+   discuss important objections or concerns raised during discussion.\n+\n+#. Backwards Compatibility -- All DEPs that introduce backwards\n+   incompatibilities must include a section describing these incompatibilities\n+   and their severity.  The DEP must explain how the author proposes to deal\n+   with these incompatibilities.  DEP submissions without a sufficient backwards\n+   compatibility treatise may be rejected outright.\n+\n+#. Reference Implementation -- The reference implementation must be completed\n+   before any DEP is given status \"Final\", but it need not be completed before\n+   the DEP is accepted.  While there is merit to the approach of reaching\n+   consensus on the specification and rationale before writing code, the\n+   principle of \"rough consensus and running code\" is still useful when it comes\n+   to resolving many discussions of API details.\n+\n+   The final implementation must include tests and documentation, per Django's\n+   `contribution guidelines <https://docs.djangoproject.com/en/dev/internals/contributing/>`_.\n+\n+#. Copyright/public domain -- Each DEP must be explicitly licensed\n+   as `CC0 <https://creativecommons.org/publicdomain/zero/1.0/>`_.\n+\n+DEP Metadata\n+------------\n+\n+Each DEP must begin with some metadata given as an rST \n+`field list <http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#field-lists>`_ \n+The headers must contain the following fields:\n+\n+``DEP``\n+    the DEP number\n+``Type``\n+    ``Feature``, ``Informational``, or ``Process``\n+``Status``\n+    ``Draft``, ``Accepted``, ``Rejected``, ``Withdrawn``, ``Final``, or ``Superseded``\n+``Created``\n+    original creation date of the DEP (in ``yyyy-mm-dd`` format)\n+``Last-Modified``\n+    date the DEP was last modified (in ``yyyy-mm-dd`` format)\n+``Author``\n+    the DEP's author(s)\n+``Implementation-Team``\n+    the person/people who have committed to implementing this DEP\n+``Shepherd``\n+    the core developer \"on point\" for the DEP\n+``Requires``\n+    if this DEP depends on another DEP being implemented first,\n+    this should be a link to the required DEP.\n+``Django-Version`` (optional)\n+    for Feature DEPs, the version of Django (e.g. ``1.8``) that this\n+    feature will be released in.\n+``Replaces`` (optional)\n+    ... and ...\n+``Superseded-By`` (optional)\n+    These fields indicate that a DEP has been rendered obsolete. The newer DEP\n+    must have a ``Replaces`` header containing the number of the DEP that it\n+    rendered obsolete; the older DEP has a ``Superseded-By`` header pointing to\n+    the newer DEP.\n+``Resolution`` (optional)\n+    for DEPs that have been decided upon, this can be a link to the final\n+    rationale for acceptance/rejection. It's also reasonable for to simply\n+    update the DEP with a \"Resolution\" section, in which case this header\n+    can be left out.\n+\n+Auxiliary Files\n+---------------\n+\n+DEPs may include auxiliary files such as diagrams.  Such files must be named\n+``XXXX-descriptive-title.ext``, where \"XXXX\" is the DEP number, \"descriptive-\n+title\" is a short slug indicating what the file contains, and \"ext\" is replaced\n+by the actual file extension (e.g. \"png\").\n+\n+Reporting DEP Bugs, or Submitting DEP Updates\n+=============================================\n+\n+How you report a bug, or submit a DEP update depends on several factors, such as\n+the maturity of the DEP, the preferences of the DEP author, and the nature of\n+your comments.  For the early draft stages of the DEP, it's probably best to\n+send your comments and changes directly to the DEP author.  For more mature, or\n+finished DEPs you can submit corrections as GitHub issues or pull requests\n+against the DEP repository.\n+\n+When in doubt about where to send your changes, please check first with the DEP\n+author and/or a core developer.\n+\n+DEP authors with git push privileges for the DEP repository can update the DEPs\n+themselves.\n+\n+Transferring DEP Ownership\n+==========================\n+\n+It occasionally becomes necessary to transfer ownership of DEPs to a new author.\n+In general, it is preferable to retain the original author as a co-author of the\n+transferred DEP, but that's really up to the original author.  A good reason to\n+transfer ownership is because the original author no longer has the time or\n+interest in updating it or following through with the DEP process, or has fallen\n+off the face of the 'net (i.e. is unreachable or not responding to email).  A\n+bad reason to transfer ownership is because the author doesn't agree with the\n+direction of the DEP.  One aim of the DEP process is to try to build consensus\n+around a DEP, but if that's not possible, an author can always submit a\n+competing DEP.\n+\n+If you are interested in assuming ownership of a DEP, first try to contact the\n+original author and ask for permission. If they approve, ask them to open a pull\n+request transfering the DEP to you. If the original author doesn't respond to\n+email within a few weeks, contact django-developers.\n+\n+\n+Differences between DEPs and PEPs\n+=================================\n+\n+As stated in the preamble, the DEP process is more or less a direct copy of\n+the PEP process (and this document is a modified version of \n+`PEP 1 <https://www.python.org/dev/peps/pep-0001/>`_). \n+\n+Relative to the PEP process, we made the following changes in DEPs:\n+\n+- The workflow is Github based (rather than email-based as in PEP 1).\n+\n+  This is a simple enough change, but has a number of ramifications for the\n+  details DEPs of how DEPs work, including:\n+\n+    - DEPs use pull requests (and direct commits) as the workflow process","path":"final/0001-dep-process.rst","position":460,"original_position":460,"commit_id":"07499ebb23ffcf59d482cdb4914ea0b4a0988c7f","original_commit_id":"07499ebb23ffcf59d482cdb4914ea0b4a0988c7f","user":{"login":"timgraham","id":411869,"avatar_url":"https://avatars.githubusercontent.com/u/411869?v=3","gravatar_id":"","url":"https://api.github.com/users/timgraham","html_url":"https://github.com/timgraham","followers_url":"https://api.github.com/users/timgraham/followers","following_url":"https://api.github.com/users/timgraham/following{/other_user}","gists_url":"https://api.github.com/users/timgraham/gists{/gist_id}","starred_url":"https://api.github.com/users/timgraham/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/timgraham/subscriptions","organizations_url":"https://api.github.com/users/timgraham/orgs","repos_url":"https://api.github.com/users/timgraham/repos","events_url":"https://api.github.com/users/timgraham/events{/privacy}","received_events_url":"https://api.github.com/users/timgraham/received_events","type":"User","site_admin":false},"body":"also add periods to the first few items for consistency with the last few","created_at":"2014-11-16T22:25:09Z","updated_at":"2014-11-16T22:25:09Z","html_url":"https://github.com/django/deps/pull/9#discussion_r20413878","pull_request_url":"https://api.github.com/repos/django/deps/pulls/9","_links":{"self":{"href":"https://api.github.com/repos/django/deps/pulls/comments/20413878"},"html":{"href":"https://github.com/django/deps/pull/9#discussion_r20413878"},"pull_request":{"href":"https://api.github.com/repos/django/deps/pulls/9"}}},"pull_request":{"url":"https://api.github.com/repos/django/deps/pulls/9","id":24501498,"html_url":"https://github.com/django/deps/pull/9","diff_url":"https://github.com/django/deps/pull/9.diff","patch_url":"https://github.com/django/deps/pull/9.patch","issue_url":"https://api.github.com/repos/django/deps/issues/9","number":9,"state":"open","locked":false,"title":"New version of DEP 1","user":{"login":"jacobian","id":21148,"avatar_url":"https://avatars.githubusercontent.com/u/21148?v=3","gravatar_id":"","url":"https://api.github.com/users/jacobian","html_url":"https://github.com/jacobian","followers_url":"https://api.github.com/users/jacobian/followers","following_url":"https://api.github.com/users/jacobian/following{/other_user}","gists_url":"https://api.github.com/users/jacobian/gists{/gist_id}","starred_url":"https://api.github.com/users/jacobian/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jacobian/subscriptions","organizations_url":"https://api.github.com/users/jacobian/orgs","repos_url":"https://api.github.com/users/jacobian/repos","events_url":"https://api.github.com/users/jacobian/events{/privacy}","received_events_url":"https://api.github.com/users/jacobian/received_events","type":"User","site_admin":false},"body":"This is a more or less complete rewrite of DEP 1. I started with PEP 1, and\nmade as few changes as possible to modify it to fit our workflow. The\nchanges from PEP 1 are summarized at the bottom of the new DEP 1.\n\nThanks to Carl, Jannis, and Andrew for their input on this.\n\nThis PR also creates the new directory structure for DEPs, adds a DEP\ntemplate, and updates DEP 181 accordingly.","created_at":"2014-11-16T12:45:48Z","updated_at":"2014-11-16T22:25:09Z","closed_at":null,"merged_at":null,"merge_commit_sha":"b6a3512c72798200c4958aced468800cb8a4e342","assignee":null,"milestone":null,"commits_url":"https://api.github.com/repos/django/deps/pulls/9/commits","review_comments_url":"https://api.github.com/repos/django/deps/pulls/9/comments","review_comment_url":"https://api.github.com/repos/django/deps/pulls/comments/{number}","comments_url":"https://api.github.com/repos/django/deps/issues/9/comments","statuses_url":"https://api.github.com/repos/django/deps/statuses/07499ebb23ffcf59d482cdb4914ea0b4a0988c7f","head":{"label":"django:dep-1","ref":"dep-1","sha":"07499ebb23ffcf59d482cdb4914ea0b4a0988c7f","user":{"login":"django","id":27804,"avatar_url":"https://avatars.githubusercontent.com/u/27804?v=3","gravatar_id":"","url":"https://api.github.com/users/django","html_url":"https://github.com/django","followers_url":"https://api.github.com/users/django/followers","following_url":"https://api.github.com/users/django/following{/other_user}","gists_url":"https://api.github.com/users/django/gists{/gist_id}","starred_url":"https://api.github.com/users/django/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/django/subscriptions","organizations_url":"https://api.github.com/users/django/orgs","repos_url":"https://api.github.com/users/django/repos","events_url":"https://api.github.com/users/django/events{/privacy}","received_events_url":"https://api.github.com/users/django/received_events","type":"Organization","site_admin":false},"repo":{"id":18764735,"name":"deps","full_name":"django/deps","owner":{"login":"django","id":27804,"avatar_url":"https://avatars.githubusercontent.com/u/27804?v=3","gravatar_id":"","url":"https://api.github.com/users/django","html_url":"https://github.com/django","followers_url":"https://api.github.com/users/django/followers","following_url":"https://api.github.com/users/django/following{/other_user}","gists_url":"https://api.github.com/users/django/gists{/gist_id}","starred_url":"https://api.github.com/users/django/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/django/subscriptions","organizations_url":"https://api.github.com/users/django/orgs","repos_url":"https://api.github.com/users/django/repos","events_url":"https://api.github.com/users/django/events{/privacy}","received_events_url":"https://api.github.com/users/django/received_events","type":"Organization","site_admin":false},"private":false,"html_url":"https://github.com/django/deps","description":"Django Enhancement Proposals","fork":false,"url":"https://api.github.com/repos/django/deps","forks_url":"https://api.github.com/repos/django/deps/forks","keys_url":"https://api.github.com/repos/django/deps/keys{/key_id}","collaborators_url":"https://api.github.com/repos/django/deps/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/django/deps/teams","hooks_url":"https://api.github.com/repos/django/deps/hooks","issue_events_url":"https://api.github.com/repos/django/deps/issues/events{/number}","events_url":"https://api.github.com/repos/django/deps/events","assignees_url":"https://api.github.com/repos/django/deps/assignees{/user}","branches_url":"https://api.github.com/repos/django/deps/branches{/branch}","tags_url":"https://api.github.com/repos/django/deps/tags","blobs_url":"https://api.github.com/repos/django/deps/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/django/deps/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/django/deps/git/refs{/sha}","trees_url":"https://api.github.com/repos/django/deps/git/trees{/sha}","statuses_url":"https://api.github.com/repos/django/deps/statuses/{sha}","languages_url":"https://api.github.com/repos/django/deps/languages","stargazers_url":"https://api.github.com/repos/django/deps/stargazers","contributors_url":"https://api.github.com/repos/django/deps/contributors","subscribers_url":"https://api.github.com/repos/django/deps/subscribers","subscription_url":"https://api.github.com/repos/django/deps/subscription","commits_url":"https://api.github.com/repos/django/deps/commits{/sha}","git_commits_url":"https://api.github.com/repos/django/deps/git/commits{/sha}","comments_url":"https://api.github.com/repos/django/deps/comments{/number}","issue_comment_url":"https://api.github.com/repos/django/deps/issues/comments/{number}","contents_url":"https://api.github.com/repos/django/deps/contents/{+path}","compare_url":"https://api.github.com/repos/django/deps/compare/{base}...{head}","merges_url":"https://api.github.com/repos/django/deps/merges","archive_url":"https://api.github.com/repos/django/deps/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/django/deps/downloads","issues_url":"https://api.github.com/repos/django/deps/issues{/number}","pulls_url":"https://api.github.com/repos/django/deps/pulls{/number}","milestones_url":"https://api.github.com/repos/django/deps/milestones{/number}","notifications_url":"https://api.github.com/repos/django/deps/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/django/deps/labels{/name}","releases_url":"https://api.github.com/repos/django/deps/releases{/id}","created_at":"2014-04-14T14:59:32Z","updated_at":"2014-11-15T12:52:42Z","pushed_at":"2014-11-16T16:48:36Z","git_url":"git://github.com/django/deps.git","ssh_url":"git@github.com:django/deps.git","clone_url":"https://github.com/django/deps.git","svn_url":"https://github.com/django/deps","homepage":null,"size":411,"stargazers_count":115,"watchers_count":115,"language":null,"has_issues":false,"has_downloads":true,"has_wiki":false,"has_pages":false,"forks_count":11,"mirror_url":null,"open_issues_count":3,"forks":11,"open_issues":3,"watchers":115,"default_branch":"master"}},"base":{"label":"django:master","ref":"master","sha":"0128ae2124c6031f51541e982101bca3a3ee6983","user":{"login":"django","id":27804,"avatar_url":"https://avatars.githubusercontent.com/u/27804?v=3","gravatar_id":"","url":"https://api.github.com/users/django","html_url":"https://github.com/django","followers_url":"https://api.github.com/users/django/followers","following_url":"https://api.github.com/users/django/following{/other_user}","gists_url":"https://api.github.com/users/django/gists{/gist_id}","starred_url":"https://api.github.com/users/django/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/django/subscriptions","organizations_url":"https://api.github.com/users/django/orgs","repos_url":"https://api.github.com/users/django/repos","events_url":"https://api.github.com/users/django/events{/privacy}","received_events_url":"https://api.github.com/users/django/received_events","type":"Organization","site_admin":false},"repo":{"id":18764735,"name":"deps","full_name":"django/deps","owner":{"login":"django","id":27804,"avatar_url":"https://avatars.githubusercontent.com/u/27804?v=3","gravatar_id":"","url":"https://api.github.com/users/django","html_url":"https://github.com/django","followers_url":"https://api.github.com/users/django/followers","following_url":"https://api.github.com/users/django/following{/other_user}","gists_url":"https://api.github.com/users/django/gists{/gist_id}","starred_url":"https://api.github.com/users/django/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/django/subscriptions","organizations_url":"https://api.github.com/users/django/orgs","repos_url":"https://api.github.com/users/django/repos","events_url":"https://api.github.com/users/django/events{/privacy}","received_events_url":"https://api.github.com/users/django/received_events","type":"Organization","site_admin":false},"private":false,"html_url":"https://github.com/django/deps","description":"Django Enhancement Proposals","fork":false,"url":"https://api.github.com/repos/django/deps","forks_url":"https://api.github.com/repos/django/deps/forks","keys_url":"https://api.github.com/repos/django/deps/keys{/key_id}","collaborators_url":"https://api.github.com/repos/django/deps/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/django/deps/teams","hooks_url":"https://api.github.com/repos/django/deps/hooks","issue_events_url":"https://api.github.com/repos/django/deps/issues/events{/number}","events_url":"https://api.github.com/repos/django/deps/events","assignees_url":"https://api.github.com/repos/django/deps/assignees{/user}","branches_url":"https://api.github.com/repos/django/deps/branches{/branch}","tags_url":"https://api.github.com/repos/django/deps/tags","blobs_url":"https://api.github.com/repos/django/deps/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/django/deps/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/django/deps/git/refs{/sha}","trees_url":"https://api.github.com/repos/django/deps/git/trees{/sha}","statuses_url":"https://api.github.com/repos/django/deps/statuses/{sha}","languages_url":"https://api.github.com/repos/django/deps/languages","stargazers_url":"https://api.github.com/repos/django/deps/stargazers","contributors_url":"https://api.github.com/repos/django/deps/contributors","subscribers_url":"https://api.github.com/repos/django/deps/subscribers","subscription_url":"https://api.github.com/repos/django/deps/subscription","commits_url":"https://api.github.com/repos/django/deps/commits{/sha}","git_commits_url":"https://api.github.com/repos/django/deps/git/commits{/sha}","comments_url":"https://api.github.com/repos/django/deps/comments{/number}","issue_comment_url":"https://api.github.com/repos/django/deps/issues/comments/{number}","contents_url":"https://api.github.com/repos/django/deps/contents/{+path}","compare_url":"https://api.github.com/repos/django/deps/compare/{base}...{head}","merges_url":"https://api.github.com/repos/django/deps/merges","archive_url":"https://api.github.com/repos/django/deps/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/django/deps/downloads","issues_url":"https://api.github.com/repos/django/deps/issues{/number}","pulls_url":"https://api.github.com/repos/django/deps/pulls{/number}","milestones_url":"https://api.github.com/repos/django/deps/milestones{/number}","notifications_url":"https://api.github.com/repos/django/deps/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/django/deps/labels{/name}","releases_url":"https://api.github.com/repos/django/deps/releases{/id}","created_at":"2014-04-14T14:59:32Z","updated_at":"2014-11-15T12:52:42Z","pushed_at":"2014-11-16T16:48:36Z","git_url":"git://github.com/django/deps.git","ssh_url":"git@github.com:django/deps.git","clone_url":"https://github.com/django/deps.git","svn_url":"https://github.com/django/deps","homepage":null,"size":411,"stargazers_count":115,"watchers_count":115,"language":null,"has_issues":false,"has_downloads":true,"has_wiki":false,"has_pages":false,"forks_count":11,"mirror_url":null,"open_issues_count":3,"forks":11,"open_issues":3,"watchers":115,"default_branch":"master"}},"_links":{"self":{"href":"https://api.github.com/repos/django/deps/pulls/9"},"html":{"href":"https://github.com/django/deps/pull/9"},"issue":{"href":"https://api.github.com/repos/django/deps/issues/9"},"comments":{"href":"https://api.github.com/repos/django/deps/issues/9/comments"},"review_comments":{"href":"https://api.github.com/repos/django/deps/pulls/9/comments"},"review_comment":{"href":"https://api.github.com/repos/django/deps/pulls/comments/{number}"},"commits":{"href":"https://api.github.com/repos/django/deps/pulls/9/commits"},"statuses":{"href":"https://api.github.com/repos/django/deps/statuses/07499ebb23ffcf59d482cdb4914ea0b4a0988c7f"}}}}