Resolved: wontfix is not productive

[Charlie Hayes]

Ticket 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:

[Daniele Procida]

On Tue, Jul 26, 2016, Charlie Hayes <cosm...@gmail.com> wrote:

>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.

Please don't be rude.

You'd like the almost entirely unpaid volunteers in the team to listen sympathetically to your concerns; don't begin by insulting their work.

Most people think that Django's documenation is exemplary. I don't think you'll find anyone who shares your opinion of it. In any case, a great deal of once again almost entirely unremunerated effort has gone into it, just like the rest of Django.

You may even be right about the need for this feature, but no-one on the team is paid enough to deal with people who insult them, so it doesn't matter whether you are or not.

>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).

Feel free to reopen the proposal with a clear picture of what you think is needed and how you think the need should be met, but be prepared to state the case well. And more courteously please. Nobody on the team is obliged to deal with the expression of your anger.

Daniele

[Aymeric Augustin]

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 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.

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/163e3b24-aa17-4f82-bc48-3104d3e0d203%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marcin Nowak]

On Tuesday, July 26, 2016 at 11:16:18 PM UTC+2, Aymeric Augustin wrote:

> Specifically, please explain why this has to live in Django.

Because Django has an implementation which can be extended without rewritting a whole thing from scratch?

Well... it is your decision about "including batteries" into the framework, making it full-stack...

I like quite opposite design, personally, but here is a guy who did useful improvement and his work was dropped because of... including another useful battery. 

I know that every line of code needs to be maintained and you're very careful with adding new features. 

But maybe there is a good time to think about decoupling Django?

BR,

Marcin