Participating in any Open Source project can be frustrating if things do not move along as quickly as you would like. Django is a fairly popular project, whose developers are volunteers with limited resources, and with a pretty big commitment to stability and backwards compatibility, so there will always be people who get frustrated. This blog post is intended to help people in that situation be helpful, and to not actually make things worse.

To provide an example, a comment was posted on a bug 8426 yesterday. No offence to the poster – it's actually a fairly minor example – but it illustrates why comments like that one will be ignored, and may even work in the opposite direction:

1. The bug is definitely in the category of minor, in the grand scheme of things, since it is only about how help text looks in forms, and the ability to style it – which you already have complete control of by subclassing Form. It is in fact a feature request. But the comment makes it sound like a dire problem. In fact, adding “I need it die hard!” just makes the commenter sound unreasonable.

2. The previous comment had actually explained what needs to be done to move things on, but the commenter hasn't shown any evidence that they have read it. They want other people to invest time, but are not willing to invest time themselves.

3. The main pain point from the commenter's point of view is probably the need to patch Django to include this fix. That doesn't really sway Django developers, for the following reasons:

   • For any bug/feature, it is always possible that someone may say it is a ‘must have’ – we quite understand that a customer may simply require certain behaviour. But this doesn't make it high priority for us – if it did, everything would be high priority, which makes ‘high priority’ meaningless.

   • If the main pain point is having to patch Django, that is true for any fix that is a ‘must have’. There are much bigger pain points with some bugs – like the lack of any available patch, or the need for a design decision to address the problem, where the design decision will make an impact on other areas of your code.

   • There are tools that make it easier to apply patches. I often run Django projects from patched versions of Django. The way I have done this is to fork the Mercurial BitBucket Django mirror, and add my own fixes, usually into named branches. Since I'm a committer, these usually get merged back into Django (though occasionally they are just thrown away). Merging from Django trunk is then extremely easy.

     I know that some people don't know how to do these things, and many people will wait for a release for everything. But if you can wait for a release, or if you can't learn the relatively simple tools that would allow you to maintain a fork, it can't be that high priority, can it?

     For reference, making your own Mercurial branch for this, assuming a clean patch and a Linux/Unix system, is as simple as:

     $ hg clone http://bitbucket.org/mirror/django
     $ cd django
     $ hg branch my_fixes
     $ patch -p1 < /path/to/correct/8426.diff
     $ hg commit -m "helptext CSS class for help text in forms"
     

     To pull in new changes from trunk into your repository and branch:

     $ hg pull && hg merge -r default && hg commit -m "Merged from trunk"
     

So, all in all, adding a comment like the above expresses frustration, but doesn't persuade us that it is high priority, and doesn't help us move forward. With this bug, it was on Version1.1Features as a 'small bug' that doesn't really need discussion. So, a helpful thing to post would be something like:

It's now post 1.2 so we are out of feature freeze, and this was procedurally accepted for 1.1 as a small bug, so I don't think it needs discussion. I've checked the patch, and it still applies to trunk, and the test suite passes with no failures. Is there any reason this can't go straight in?

As it happens, the latest patch did not apply cleanly to trunk, I had to manually apply some bits.

In addition, there are other things I would check as a committer. For instance, backwards compatibility: is this going to interfere with styling in the admin, or the other way around? Answer: probably not, because the admin doesn't use those methods to render forms, and other pages are unlikely to include admin CSS files. However, the admin CSS does use a 'help' class – shouldn't we stick with that name rather than add another for exactly the same use case? Or, is a 'help' class too generic, and will it end up clashing with existing HTML on people's pages? (In the end, I decided to stay with 'helptext': 1) for that latter reason, 2) because that's how it was in the accepted ticket, and 3) because that will make people who have already patched their source happy.)

These are all things that need to be checked, and which take time, and someone who was really desperate would have done some of these things. I have now committed it, mainly to avoid the complaint “it took longer to explain why you didn't commit it than it would have taken to commit”, but it should be noted that comments like the one above usually have the opposite effect on committers.

Anyway, I hope this post helps give some insight into why some comments are less than helpful, and what are the more constructive avenues. I won't claim that we always have the excuses laid out here – there are many more important tickets that have languished for way too long for no good reason. But the first thing to check is that you have followed our contributing guidelines and made things as easy as possible for the core developers.