Hello Charlie, Glad to meet you!
Trac says I’m the person who closed that ticket two years ago. I don’t remember it specifically but hopefully I can give you some context. When I closed that ticket, it hadn’t received any activity for two years. No one had reacted to the last comment which suggested to build the feature externally. There was no clear path of action within Django. Seeing that the ticket wasn’t getting much attention, if any, and wasn’t likely to go anywhere in its current state, I must have spent no more than a few minutes before deciding to drop it. The goal was to improve the signal / noise ratio in the ticket tracker. When there's over a thousand open tickets, some gardening helps keeping things under control, typically to keep it manageable to look for duplicates. I may have closed ten or twenty tickets in that session. A wontfix isn’t absolute, though. If the idea is interesting, it will come up again and could be reconsidered. Perhaps this particular idea is interesting. If you explain why you disagree with the current conclusions of the ticket — by now you must have spent more time thinking about it that I ever did, if you can convincingly address the arguments raised in comments — especially those by committers, and if the discussion results in a consensus for making changes to Django in this area, then you can reopen that ticket or open a new ticket. The latter is often more convenient when the original ticket is several years old or contains a confusing discussion. You can add a comment in the old ticket pointing to the new one and vice-versa. Django has evolved over more than ten years now and its current goals aren’t the same as when it was just open-sourced, or even when it only existed inside LWJ. Some features that you call inane are just quite old. They wouldn’t get added today; similar features wouldn’t get added either; but this isn’t necessarily a sufficient reason for removing them and break projects that use them. Sometimes we deprecate features that we consider undesirable but we try to do it conservatively. Thank you for the kind words about Django’s documentation. It’s always a pleasure to know that the tens thousands of hours put by thousands of volunteers into writing them are appreciated. In fact, Django’s documentation is well known for being one of the worst among popular open-source web frameworks. This is expected as the Python ecosystem at large simply sucks at documentation. In this sad situation, if we want to improve, we have no choice but to raise the bar on documentation that gets added. Otherwise we’ll just keep digging our hole. Complain about the poor quality of the documentation and advocating merging documentation patches regardless of their quality in the same sentence doesn’t strike me as logical. Okay, for the sake of clarity, I hope that: 1. everyone spotted the irony in the previous paragraph 2. you realize that your email wasn’t setting the tone for a constructive discussion, but hopefully we can bounce back :-) So, with regards to this particular ticket, what new arguments can you bring to the table and what’s your proposal for moving forwards? Please build upon the discussion in the ticket like I explained above. Specifically, please explain why this has to live in Django. djangopackages.com <http://djangopackages.com/> proves that tons of widely useful features live happily as third-party apps. Best regards, -- Aymeric. PS: We know that Trac's antispam isn’t very good but we had to reactivate it when spammers figured out how to use GitHub authentication. FYI, when I was managing the antispam, the spam / hame ratio was about 1000 : 1, so it isn’t exactly easy to configure. If anyone is experienced with Trac’s antispam and knows how to tune it, we’re all ears. > On 26 Jul 2016, at 22:30, Charlie Hayes <cosmo...@gmail.com> wrote: > > Ticket https://code.djangoproject.com/ticket/19447 > <https://code.djangoproject.com/ticket/19447> was resolved as wont fix. > > Although this PR is insufficient for our needs (we would also need localized > abbreviations), it would certainly be more useful than the nothing that > exists now. > > How does the Django team know how many developers would use a feature like > this when said developers never get a chance to use it? Django includes a lot > of inane features that many fewer developers would use compared to this. The > documentation for all of Django is already pretty bad (it's poorly organized, > poorly hyperlinked, uses bad examples, etc, regardless of what others say); > blocking a PR from acceptance because the documentation doesn't measure up to > the bar set in practice is illogical. > > Practically every site that prints numbers to the screen (read: all sites) > could benefit from features like this. If the work is incomplete, let someone > take over or explain what else needs to be implemented before acceptance is > gained. Closing it as won't fix is irrational and discourages the community > (and adoption of the framework). > > -Charlie > > PS: I can't add this as a comment to the ticket because: > > <https://lh3.googleusercontent.com/-rUzIzGN__wM/V5fHwbr3umI/AAAAAAAABt8/jxYrcFrzKKsA0sN9Ex5mnkT1vQSuBeIpwCLcB/s1600/trac.png> > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto:django-developers@googlegroups.com>. > Visit this group at https://groups.google.com/group/django-developers > <https://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/163e3b24-aa17-4f82-bc48-3104d3e0d203%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/163e3b24-aa17-4f82-bc48-3104d3e0d203%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/BAA89208-D946-4096-8F1C-31F18B69F49C%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
