Hi,When I started using Python a couple of months ago, a quick Google for frameworks turned up a lot of results for Django so I decided to give it a spin.I'd like to give some feedback on my experience to date. There are a lot of features I really love, some that are a little quirky and some that are downright inflexible. None of this will be news - it's the same for every framework. That said, I started to have doubts when I was attempting to find solutions/workarounds to the problems I encountered.Today was the 5th or 6th time that I've ended up at the ticket system and seen people saying "This would really help me" and a core developer saying "I don't see the need" (rather arbitrarily IMHO) and closing as wontfix. This is invariably followed by people asking for reconsideration which in turn gets a "use the mailing list" with varying degrees of rudeness.While I'm sure it's not the real reason, sending people to the mailing lists feels like a way of brushing disagreement under the carpet. There's no obvious way to follow on from the discussion in the ticket to the relevant discussions in the mailing list (if any) and visitors coming by years later now have to go and hunt through an archive to find out if there's any chance of a change.
I feel that the general attitude expressed in some of the tickets is poor. The one which prompted this post is https://code.djangoproject.com/ticket/901. I think comment 20 is a good demonstration of my point. A couple of users were getting frustrated at the lack of discussion/progress which resulted in a fairly sanctimonious rant.
Some other tickets I've ended up on have proposed patches and seem to have sat in "Design decision" for years, which again gives the impression that the core team didn't like it so just sort of ignored it until it went away.
So, to be honest, the impression I'm getting WRT new features in Django is "Don't bother proposing it 'cos it's not going to happen".
There are StackOverflow questions (another) on the topic and numerous other sources pointing at this particular ticket wondering why it hasn't been implemented. The only reason I can see is that "jacob" wasn't convinced by the (first) use case.
Now, I admit that I'm probably seeing the worst side of the problem, there are probably hundreds of other features which did get in (which is why there's documentation not tickets for me to find) but that doesn't make the situation I'm seeing better, just smaller.Perhaps the fact that people keep posting on closed tickets shows that the current flow to the mailing lists isn't a good one? Maybe either add a "Start a topic about this ticket" link or maybe even just allow discussion to continue on the ticket as many others do?
I'm unlikely to use Django moving forward. There are a number of reasons and I'd be lying if I said this was the biggest but it was a factor in my decision.Anyway, I wanted to take a few minutes and share the impressions I've had to date - perhaps this way, others will have a better experience in future.Thanks for readingSimon
--
You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Hi Simon, Luke and Aymeric,Simon, first of all, thanks for your feedback.Core developers, I think Simons comment is a thing we should take seriously. A ticket was closed and people didn't understand the process and re-opened it. I believe we could have explained more clearly:1. our decision2. the workaround3. how exactly the mailing list works.Instead this ticket ended up into an argument about re-opening this ticket, where people apparently weren't familiar with the process and did not know the proper steps to raise this to the e-mailing list which was of course the best step to get this ticket any further.
--
@Russell
"can't compel anyone to do anything"... you can compel people to NOT do something, such as, "don't close a ticket as won't-fix without giving a detailed explanation of why it should be closed".
Saying that people cannot be compelled is an excuse to not take action.
Ignoring the 3 outlined problems in the post you replied to while pretending to ask for suggestions from the community is just a form of equivocation. Politicians do it all the time...
The core team has implemented a process that we think works. It has changed over time, and is something that we feel is practical to implement, and achieves the goals we're aiming to achieve.
Hi all,If I may make a suggestion to be considered by the community:
On Mon, 13 May 2013, Russell Keith-Magee wrote:
This isn't political equivocating. Its a genuine call to the community to tell us how we can make things better.
The status WONTFIX sounds awfully rude to me. It's like saying "That's a pony and you can't have one, ever." It implies a terminal finality which actually isn't meant in some cases, because it is possible (as we've seen) and even sometimes recommended by a core developer, for a sufficiently determined person to push for change on the mailing list and make it happen.
Perhaps there's a case for a status like "DISCUSSION" or "NEEDINFO" when a feature might be accepted if sufficient evidence for it comes to light, but that evidence isn't there yet.
I think there is value in people "voting" for a feature on the ticket if they don't feel up to arguing the case on the mailing list (which is a trial by fire, and not for the faint hearted). Whoever is brave enough to take up the issue on the mailing list can point to the number of votes on the ticket as evidence for a desire for the feature, and hence its usefulness. And voting on the ticket instead of here saves a lot of "me too" noise on the mailing list.
Looking for a positive outcome here -- my question to the community, and especially those that feel that we've been unresponsive here: how do we improve the situation?
How about allowing comments only from the patch author and committers?
Would it be possible to customise trak at all to make the workflow clearer?
I'm thinking if someone tries to open a ticket that was closed by a committer then they should get an intermediate page pointing them to this group and asking them to confirm before the ticket is reopened.
I don't know if Trak is customisable to that extent, or if this would even be effective, but it would be nice to get something out of this.
Thanks,
Pete
--
You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
How about allowing comments only from the patch author and committers?
The problem I see with this is that original bug reporters, aside from the aforementioned groups, are usually the ones most engaged in these comments, and eliminating them from the process will only serve to further disjoint the technical dialog (e.g., "It's still not fixed" should probably go in the ticket, not here).
Hi,When I started using Python a couple of months ago, a quick Google for frameworks turned up a lot of results for Django so I decided to give it a spin.I'd like to give some feedback on my experience to date. There are a lot of features I really love, some that are a little quirky and some that are downright inflexible. None of this will be news - it's the same for every framework. That said, I started to have doubts when I was attempting to find solutions/workarounds to the problems I encountered.Today was the 5th or 6th time that I've ended up at the ticket system and seen people saying "This would really help me" and a core developer saying "I don't see the need" (rather arbitrarily IMHO) and closing as wontfix. This is invariably followed by people asking for reconsideration which in turn gets a "use the mailing list" with varying degrees of rudeness.While I'm sure it's not the real reason, sending people to the mailing lists feels like a way of brushing disagreement under the carpet. There's no obvious way to follow on from the discussion in the ticket to the relevant discussions in the mailing list (if any) and visitors coming by years later now have to go and hunt through an archive to find out if there's any chance of a change.I feel that the general attitude expressed in some of the tickets is poor. The one which prompted this post is https://code.djangoproject.com/ticket/901. I think comment 20 is a good demonstration of my point. A couple of users were getting frustrated at the lack of discussion/progress which resulted in a fairly sanctimonious rant.Some other tickets I've ended up on have proposed patches and seem to have sat in "Design decision" for years, which again gives the impression that the core team didn't like it so just sort of ignored it until it went away.So, to be honest, the impression I'm getting WRT new features in Django is "Don't bother proposing it 'cos it's not going to happen".There are StackOverflow questions (another) on the topic and numerous other sources pointing at this particular ticket wondering why it hasn't been implemented. The only reason I can see is that "jacob" wasn't convinced by the (first) use case.Now, I admit that I'm probably seeing the worst side of the problem, there are probably hundreds of other features which did get in (which is why there's documentation not tickets for me to find) but that doesn't make the situation I'm seeing better, just smaller.Perhaps the fact that people keep posting on closed tickets shows that the current flow to the mailing lists isn't a good one? Maybe either add a "Start a topic about this ticket" link or maybe even just allow discussion to continue on the ticket as many others do?
I'm unlikely to use Django moving forward. There are a number of reasons and I'd be lying if I said this was the biggest but it was a factor in my decision.Anyway, I wanted to take a few minutes and share the impressions I've had to date - perhaps this way, others will have a better experience in future.Thanks for readingSimon
On 15/05/13 19:36, ptone wrote:That's a good idea. The purpose of this wiki page is to make it easy for
> I wonder if a slightly more concise version of this should be added to
> the triaging docs instead of a wiki page (fine place to draft it though).
>
> https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#closing-tickets
>
> I feel that the wiki pages aren't very discoverable, and unless we are
> talking about patching trac to include this, such a comment won't carry
> the official weight of being in the project docs.
triagers to link to - I personally hate having to go and find the right
page in the docs, but I can remember to do "DevelopersMailingList"
instead of "developers mailing list".
--