If no one has volunteered to maintain it in nearly a year since James 
stepped down, I think you'll have a tough time convincing us it's important 
enough to move into contrib. Also, the recent trend has been to remove 
things from contrib (comments, localflavor, formtools soon). 
django-registration has been viable as a third party package for a long 
time and I don't see a reason it couldn't continue as one.

On Friday, August 1, 2014 7:07:19 AM UTC-4, Robert Grant wrote:
>
> Hello all
>
> I've just started using Django for a serious project and am really 
> enjoying using it; thank you.
>
> I'm using Django 1.6 and Python 3.4. For user signups, everyone recommends 
> using django-registration. However this is not under active development 
> <https://bitbucket.org/ubernostrum/django-registration/wiki/Home> (still 
> works with a small code change) and as a budding Djangoer that worries me 
> twice:
>
> 1) as a developer, it makes my job much easier if standard functions are 
> provided. This is one of the (only) advantages of expensive corporate 
> tools; things such as registration and user management are well thought 
> through.
> 2) as a Django fan (edjangalist?) I can already see that one of Django's 
> big advantages is that decent user management comes built in. However it's 
> not complete, and django-registration plugs a big hole, as most websites 
> will need this feature.  Without it the user side of things becomes less 
> useful.
>
> Here's my proposal:
>
> Create a django.contrib.registration package.
> Pull into it the existing django-registration code and update it to work 
> with the latest version of Django.
> Keep it tightly in sync with changes to django.contrib.auth in the future.
> Add more flexibility, e.g. corporate options such as perhaps an admin user 
> can input email addresses of people to sign up, and the system generates 
> basic unactivated profiles that when triggered allow the users to then fill 
> in their remaining details (for example, this is how JIRA works). And/or 
> autodiscovery of users from LDAP settings and autopopulation of user models 
> from LDAP queries. This may be too unfocussed for the team though; it's 
> just a very nice to have!
>
> Anyway, that's my idea. I'm worried that as over time django-registration 
> drifts farther from the current version of Django, the amount of work 
> developers have to do every time will increase to the point where it's 
> better for them to roll their own than try and work out how Django 1.5 
> worked with django-registration and what they need to do to patch the 
> differences. This will lead to developers - who are attracted to Django 
> because of useful stuff such as this - abandoning the platform for ones 
> that provide benefits in other areas.
>
> Thanks for reading
>
>
> Robert Grant
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d000a15d-0723-41f5-a4b6-5ac18642e7df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to