django-registration doesn’t have the best maintenance
I’ve been looking at using the django-registration library at work for one of our projects and initially, I was very very pleased. The project is written by a Django core developer so the code itself is excellent and the documentation is up-to-date and there are many others using it so I can be sure that it has very few bugs.
However, the way its maintenance has been handled hasn’t been as great as it could be. I know that since maintainer is a Django core developer, he’s busy with other issues but the fiasco that happened with adding Django 1.5 and class-based views support wasn’t fun and it’s time to talk about it in a constructive manner.
Dismissing Pull Requests and Lack of Communication
First, there were multiple pull requests to address the issue of Django 1.5 support. None of them were approved and there was a constant reply from the maintainer that the pull requests would be ignored and never merged in.
The issue here was that it wasn’t communicated anywhere that Django 1.5 support would be worked on at a sprint session at PyCon. Even when that was finally communicated, it wasn’t communicated widely enough. It also seemed like a bunch of contributions from developers around the world were ignored in favour of contributions made by people who could afford to attend the conference. The uncertainty of when the features would be added is what spawned all the pull requests, it’s why I ended up forking the project myself and patching in those features.
There was a pull request that garnered a lot of support. The pull request for adding Django 1.5 support had 24 people review and approve it. Clicking the “approve” button was judged as spam. The pull request was created in November 2012, and it was finally rejected a few months later. That kind of thing shouldn’t happen, it should have been rejected right as soon as possible and the docs should have been updated to make it clear that the feature was going to be added, there’s no need for a pull request. The reason for rejection should have been displayed clearly.
I would have recommended updating the project home page, project documentation and the README with the plans for adding Django 1.5 support and class-based views, linking to the conference page (when it became available) and auto-replying to new pull requests with the same message, “these features will be added, just wait a few weeks”.
It might have been a good idea to suggest that developers work on other issues or to code review the features once they’re implemented. Maybe mentioning an incentive such as, “if features and bugs X, Y and Z are fixed I’ll have more time with my co-developers to work on features A and B which are coming in the next few weeks”.
One Big Commit
Instead of following along with typical software developer standards, there was a single large commit that added both Django 1.5 support and class-based views. Maybe they’re linked, but this could have been made into smaller commits. This isn’t a merge of one branch into another, where the branch history would at least be saved, it’s one single commit into the master branch.
There are many many articles on why smaller commits are better than large commits. They’re much easier to code review, they’re easier to revert and fix if they’re incorrect, they give you a sense of the history of development.
It would have been nice if these two things were on separate branches. If they were worked on earlier, they could have been tested by brave members of the community who could offer some feedback and suggestions and then merged in later.
No Project Contribution Standards
I think the previous two issues are symptoms of this. The project is watched by ~100 people on bitbucket.org, version 0.8 has been downloaded ~13,000 times and version 1.0 has been downloaded ~26,000 times, and the Python Package Index says it’s been downloaded ~3600 times just in the last week!
When you have a project that has many users who are mainly developers, it’s super important to outline how they can contribute.
These two questions needed to be answered and should be outlined in a CONTRIBUTE file or in the README:
- how should developers submit code, should it be done via pull request or with email submissions?
- how should bugs be filed? on bitbucket? via email?
After multiple pull requests and multiple clicks of the “approval” button on various commits, the maintainer finally said, “no we won’t be using these patches, they will be ignored”. When you get to that point, the answers to those questions need to be put in a place where anyone can see them. Then you can just ignore the patches if they aren’t submitted the right and auto-reply, “read the ‘How to Contribute’ section in the README”.
Contributors and Users, You Need to be Be Patient Too
There are a lot of free/open source software projects out there that have one or two developers maintaining them. When the maintainer(s) are juggling work, hobbies, life, and the projects, they may be much much slower to respond than say, a coworker who sits in the cubicle next to you. Be patient! They’ll get to your requests and patches and bug fixes as soon as they can.
If it’s taking a long time to get your patch approved, ask the maintainer why and see if you can help in some other way and try to figure out a solution that will reduce uncertainty.
The maintainer of django-registration was tempted a few times to close the code repository to the public until the features on the roadmap were added. Some of the contributors did a good job in asking why the pull requests were rejected, but if they had some time they should have also asked if the maintainer needed some help in some other way to make the features happen.