There seems to be 2 key issues, as mentioned before:

1. Admin isn't moving forward fast enough.
2. It is hard to contribute.

It seems that there is enough resistance to not moving Admin out that it seems like it would be a bad idea if it was moved. However, I am sure many contributions haven't been submitted because
people aren't sure what they can do for admin.

There seems to be a lot of change right now and am partial to the wait and see approach. With the move to github I can forsee many many more contributions taking place than there are now, simply because it is easier to do so. I personally saw it as very daunting to contribute until I learned I could submit a pull request on github. I chose to test the waters with a simple documentation pull request,
but it was super simple in the end.

Maybe wait 6 months and see what evolves out of the move to github before taking a scalpel to the admin and trying to break it up? I mean sometime inaction _is_ an actual solution while letting dust
settle on multiple things.

Like Jonathan I am new here so feel free to ignore me if you want.

Thanks,
Buddy


On 2/14/12 9:02 PM, Juan Pablo Martínez wrote:
+1 to separate django and admin o other contrib app.
-0 to mantain another/alternative admin on contrib

It is understandable at first that was maintained at par for order and security in the project itself.

But today, after Django 1.3.1 I think it's time to review the situation of contrib.

With teams in each Django contrib application would be a little more flexible.

That is my humble opinion :)

Regards,

On Mon, Feb 13, 2012 at 3:23 PM, Jonathan Paugh <jpa...@gmx.us <mailto:jpa...@gmx.us>> wrote:

    There's a big rift here between what people want to do with admin and
    what people want to do with django itself. To summarize: the admin
    should be amazing by itself and chock full of features, while django
    should be empowering without getting in the way.

    I've seen a lot of good ideas for admin rejected recently because they
    couldn't fit into Django's overall vision. I don't think there is any
    way to resolve this rift: it will persist. Django and admin should be
    developed separately, likely by separate teams. They could still
    live in
    the same codebase, with an "subofficial" admin fork. Then, the
    official
    django repo could pull in changes according to some suitable policy.

    However, maintaining it as a separate project wouldn't hurt, either:
    In address to Anssi's concerns: conteaching pip is as easy as `pip
    install django-admin`, and the two projects could be tarball-ed
    together
    somehow. (Could it be that hard to teach setup.py to install another
    package from a subdir? Or to tar up them separately?) (And what is
    virtualenv? Do I need it to install admin? Let's address that in a
    separate tutorial, with a link and a notation.)

    Peace,
    Jonathan

    P.S. I'm fairly new here (~1 month), and my perspective is
    proportionally skewed.

    On 02/03/2012 02:07 PM, Ryan D Hiebert wrote:
    > I think that Django's admin app is a killer feature for two main
    reasons:
    > 1. It is automatically installed, and integrated into the tutorial.
    > 2. It is used all over in third-party apps, because they can
    expect it to be there.
    >
    > While I appreciate that there may be differences in core vs
    admin that may slow down development of the admin, I'm wary of
    removing it from the django install, thinking that it might hurt
    reason 2, even if it is integrated in the tuturial, and possibly
    even installed automatically.
    >
    > Although as far as the automatic install goes, I'm not sure how
    that would work. Would it be a dependency? That doesn't make sense.
    >
    > On Feb 3, 2012, at 6:21 AM, Max Thayer wrote:
    >
    >> The point about admin's appeal to new people is important, but
    externalizing it and keeping new people from ever seeing it are
    very different. Consider: admin isn't even enabled by default. You
    have to follow the tutorial on how to enable it. If admin weren't
    included in Django proper, we could just change the tutorial to
    "Apps are awesome; here's how to download and install one written
    by someone else." New users could meet pip sooner, and otherwise
    understand how to integrate with the broader python/django
    community's various creations.
    >>
    >> Actually, a friend of mine and I have been plotting out
    externalizing various parts of contrib, like admin and auth. Are
    any groups currently pursuing those goals as well?
    >>
    >> Best regards,
    >> Max
    >>
    >> On Fri, Feb 3, 2012 at 8:35 AM, Brendan Smith
    <bren...@nationalpriorities.org
    <mailto:bren...@nationalpriorities.org>> wrote:
    >> I give +1 to the idea of separating out the admin and letting
    people fork and modify to their hearts content
    >>
    >> I also still give my +1 to having it utilize less, but I am
    also cautious like others about prescribing bootstrap specifically
    , especially the JS since as others have pointed out is somewhat
    unstable right now and not very easy to use at times (took me a
    long time to figure out modals)
    >>
    >> Sent from my iPhone
    >>
    >> On Feb 3, 2012, at 1:25 AM, Harris Lapiroff
    <harrislapir...@gmail.com <mailto:harrislapir...@gmail.com>> wrote:
    >>
    >>> The Django admin is a major—if not *the* major—selling point to
    >>> budding developers. I worry that externalizing it (hence
    making it a
    >>> *separate* piece of software that needs to be discovered and
    >>> installed, which seems simple but can be quite a challenge to new
    >>> coders) might take away Django's non-expert appeal. When I started
    >>> using Django, I knew no python. The only reason I was able to make
    >>> that work was because of the Django admin. If the admin gets
    kicked
    >>> out, I think it should be made *very* obvious where to find one.
    >>>
    >>> I'd be wary of putting them in core but I think using
    Bootstrap and
    >>> Less for a new admin (whether internal or external) would make its
    >>> development much faster. Dependencies should not be a problem.
    I think
    >>> jQuery is a pretty apt analogy here. You probably won't write much
    >>> javascript for the Django admin without learning jQuery. You
    can if
    >>> you want to. But most people don't need or want to write
    javascript
    >>> for the Django admin anyway. I think a framework like Bootstrap it
    >>> would actually simplify adding new features. It provides so
    many CSS
    >>> classes that there's a pretty good chance your feature wouldn't
    >>> require you to write even a line of CSS. I was able to convert an
    >>> unstyled app that I've been working on to functionally using
    Bootstrap
    >>> in just about an hour after starting to learn it.
    >>>
    >>> That having been said, I'd still be cautious with Bootstrap.
    It is a
    >>> young piece of software that is incredibly impressive and mind-
    >>> bogglingly easy to use, but obviously still in flux.
    >>>
    >>> On Feb 2, 5:38 pm, Sean Brant <brant.s...@gmail.com
    <mailto:brant.s...@gmail.com>> wrote:
    >>>> On Thu, Feb 2, 2012 at 4:17 PM, Alex Gaynor
    <alex.gay...@gmail.com <mailto:alex.gay...@gmail.com>> wrote:
    >>>>
    >>>>> On Thu, Feb 2, 2012 at 5:01 PM, Adrian Holovaty
    <adr...@holovaty.com <mailto:adr...@holovaty.com>> wrote:
    >>>>
    >>>>>> On Thu, Feb 2, 2012 at 2:49 PM, Sean Brant
    <brant.s...@gmail.com <mailto:brant.s...@gmail.com>> wrote:
    >>>>>>> Is this up somewhere public? I've been fighting the urge
    to do this as
    >>>>>>> well. Using django-compressor with less on Heroku is a
    non-starter
    >>>>>>> since you can't install node. Having this as a Python
    module would be
    >>>>>>> handy.
    >>>>
    >>>>>> Not yet, alas, but hopefully soon.
    >>>>
    >>>>>> Adrian
    >>>>
    >>>>>> --
    >>>>>> You received this message because you are subscribed to the
    Google Groups
    >>>>>> "Django developers" group.
    >>>>>> To post to this group, send email to
    django-developers@googlegroups.com
    <mailto:django-developers@googlegroups.com>.
    >>>>>> To unsubscribe from this group, send email to
    >>>>>> django-developers+unsubscr...@googlegroups.com
    <mailto:django-developers%2bunsubscr...@googlegroups.com>.
    >>>>>> For more options, visit this group at
    >>>>>> http://groups.google.com/group/django-developers?hl=en.
    >>>>
    >>>>> Perhaps this is too far in the future looking.  But at a
    certain point the
    >>>>> admin must become a separate project.  One of the major goals of
    >>>>> newforms-admin ('lo those years ago) was to demote the admin
    from special
    >>>>> status, with hooks inside core left and right, to "just an
    app".  Let's
    >>>>> carry that to the logical conclusion: just an app *outside
    of Django*.
    >>>>
    >>>>> That gives the maintainers the freedom to reinvent it, and
    use tools like
    >>>>> less or bootstrap without it needing to be an issue of
    policy for all of
    >>>>> Django.  Because when I first read saw this thread my
    thought was, "Hmm,
    >>>>> what unholy mess of requirements am I going to need if I
    want to just run
    >>>>> the test suite.  Will I still be able to write new features
    in forms without
    >>>>> needing to learn what the hell less or compass is?".
     Several years ago, I
    >>>>> opposed using jQuery in the admin, on the principle that
    Django should be
    >>>>> completely free of entangling alliances.  I made that
    argument more or less
    >>>>> out of habit, just because I felt it was an argument that
    ought to be made,
    >>>>> but really I was pretty happy to get to use jQuery.  Now I'm
    saying, it's
    >>>>> pretty clear that admin 2.0 (or 3.0, or 4.0, anyone
    counting?) is going to
    >>>>> be a beast that far outstrips almost anything else in Djanog
    (besides the
    >>>>> ORM ;)) in complexity, with more dependencies, more
    associated tooling, and
    >>>>> more usecases (i.e. it's not just a tool for developers to
    use, it's also
    >>>>> something for end users of *our* users' apps to use).
     Keeping that in
    >>>>> Django itself is going to stunt it's growth, and it's going
    to suck for new
    >>>>> developers to Django who, like many of us (or at least
    myself), were and
    >>>>> still are, Python developers at heart, who can write some
    HTML, badly.
    >>>>
    >>>>> Alex
    >>>>
    >>>>> --
    >>>>> "I disapprove of what you say, but I will defend to the
    death your right to
    >>>>> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
    >>>>> "The people's good is the highest law." -- Cicero
    >>>>
    >>>>> --
    >>>>> You received this message because you are subscribed to the
    Google Groups
    >>>>> "Django developers" group.
    >>>>> To post to this group, send email to
    django-developers@googlegroups.com
    <mailto:django-developers@googlegroups.com>.
    >>>>> To unsubscribe from this group, send email to
    >>>>> django-developers+unsubscr...@googlegroups.com
    <mailto:django-developers%2bunsubscr...@googlegroups.com>.
    >>>>> For more options, visit this group at
    >>>>> http://groups.google.com/group/django-developers?hl=en.
    >>>>
    >>>> +1
    >>>>
    >>>> Given how flexible the admin is doing somethings is still pretty
    >>>> annoying. I feel like if it was a external project with its own
    >>>> release schedule more progress could be made. FWIW i'm
    experimenting
    >>>> with an admin interface that relies heavily on class based
    views. So
    >>>> far I like it. CBVs seem to have more useful hooks then the admin
    >>>> currently has. At the very least I think the new admin needs
    to not be
    >>>> backwards compatible with the current admin.
    >>>>
    >>>> So my vote is for django-admin2 as an external project.
    >>>
    >>> --
    >>> You received this message because you are subscribed to the
    Google Groups "Django developers" group.
    >>> To post to this group, send email to
    django-developers@googlegroups.com
    <mailto:django-developers@googlegroups.com>.
    >>> To unsubscribe from this group, send email to
    django-developers+unsubscr...@googlegroups.com
    <mailto:django-developers%2bunsubscr...@googlegroups.com>.
    >>> For more options, visit this group at
    http://groups.google.com/group/django-developers?hl=en.
    >>>
    >>
    >> --
    >> You received this message because you are subscribed to the
    Google Groups "Django developers" group.
    >> To post to this group, send email to
    django-developers@googlegroups.com
    <mailto:django-developers@googlegroups.com>.
    >> To unsubscribe from this group, send email to
    django-developers+unsubscr...@googlegroups.com
    <mailto:django-developers%2bunsubscr...@googlegroups.com>.
    >> For more options, visit this group at
    http://groups.google.com/group/django-developers?hl=en.
    >>
    >>
    >>
    >> --
    >> You received this message because you are subscribed to the
    Google Groups "Django developers" group.
    >> To post to this group, send email to
    django-developers@googlegroups.com
    <mailto:django-developers@googlegroups.com>.
    >> To unsubscribe from this group, send email to
    django-developers+unsubscr...@googlegroups.com
    <mailto:django-developers%2bunsubscr...@googlegroups.com>.
    >> For more options, visit this group at
    http://groups.google.com/group/django-developers?hl=en.
    >

    --
    You received this message because you are subscribed to the Google
    Groups "Django developers" group.
    To post to this group, send email to
    django-developers@googlegroups.com
    <mailto:django-developers@googlegroups.com>.
    To unsubscribe from this group, send email to
    django-developers+unsubscr...@googlegroups.com
    <mailto:django-developers%2bunsubscr...@googlegroups.com>.
    For more options, visit this group at
    http://groups.google.com/group/django-developers?hl=en.




--
juanpex

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to