3 ms·

There are some interesting points in this article. A lot of people (including myself) have a few Django bugs fixed in their private working copies but they don

by ii 18y ago

There are some interesting points in this article. A lot of people (including myself) have a few Django bugs fixed in their private working copies but they don't contribute them back because the process is too complex. This doesn't mean that they are not willing to contribute. Barriers for contribution are way too high. It's true that you must continually fight people to help those people to fix their project. It shouldn't be so.

natrius 18y ago
How is it too complex? Instead of letting the fix stay in your working copy, why not attach the patch to the bug?
- ii 18y ago
  Because there is a 90% chance that your fix will be ignored. I had a small fix that was completely ignored and the other duplicate fix submitted 2 months later was merged into trunk only because it was made during the sprint and mine wasn't. I contributed few patches to Django in the past and every time I had to fight for them on trac or on forums. I just don't have time to do this right now.
- metajack 18y ago
  For me it was not an issue of complexity. We use trac internally and we contribute to other projects that have similar guidelines for contribution (namely Twisted Python). But the Django trac is quite hostile. Often your patch will be closed as a duplicate by a later patch. Sometime that later patch addresses a related but different problem. It's hard to get someone with "responsibility" to address the issue, even if the patch is fairly well done and rationale well documented. When I say "continually fight" I mean that the bug is closed with some bogus explanation, and I have to go reopen it and provide yet more explanation, only to have it closed again. Months later someone smacks their forehead and says "Oh! Well in that case I'll commit this now". I feel like I've been treated like a child who just learned HTML and not a developer trying to make contributions to the project. In comparison, Twisted bugs involve dialog, but the Twisted team doesn't go around closing bugs because they don't quite get what you're doing. They have strict code guidelines and policies, but at least they treat you respectfully the whole way through. It's not a fight. They also recently went through and committed many changes that had been abandoned by their authors or that the authors did not have time to finish tests for. This shows that they value their community's contributions a great deal. Django is a great project in many ways, but it has a lot of room to improve with release and community management.
  - ii 18y ago
    Wow. One of my patches (exactly the one I was whining about here ;) was just changed from "Unreviewed" to "Ready for checkin". Thank you very much, Jack. Your blog post really helped!

by ii 18y ago

natrius 18y ago

How is it too complex? Instead of letting the fix stay in your working copy, why not attach the patch to the bug?

ii 18y ago
Because there is a 90% chance that your fix will be ignored. I had a small fix that was completely ignored and the other duplicate fix submitted 2 months later was merged into trunk only because it was made during the sprint and mine wasn't. I contributed few patches to Django in the past and every time I had to fight for them on trac or on forums. I just don't have time to do this right now.
metajack 18y ago
For me it was not an issue of complexity. We use trac internally and we contribute to other projects that have similar guidelines for contribution (namely Twisted Python). But the Django trac is quite hostile. Often your patch will be closed as a duplicate by a later patch. Sometime that later patch addresses a related but different problem. It's hard to get someone with "responsibility" to address the issue, even if the patch is fairly well done and rationale well documented. When I say "continually fight" I mean that the bug is closed with some bogus explanation, and I have to go reopen it and provide yet more explanation, only to have it closed again. Months later someone smacks their forehead and says "Oh! Well in that case I'll commit this now". I feel like I've been treated like a child who just learned HTML and not a developer trying to make contributions to the project. In comparison, Twisted bugs involve dialog, but the Twisted team doesn't go around closing bugs because they don't quite get what you're doing. They have strict code guidelines and policies, but at least they treat you respectfully the whole way through. It's not a fight. They also recently went through and committed many changes that had been abandoned by their authors or that the authors did not have time to finish tests for. This shows that they value their community's contributions a great deal. Django is a great project in many ways, but it has a lot of room to improve with release and community management.
- ii 18y ago
  Wow. One of my patches (exactly the one I was whining about here ;) was just changed from "Unreviewed" to "Ready for checkin". Thank you very much, Jack. Your blog post really helped!