Perception of attitude in tickets

456 views
Skip to first unread message

Simon

unread,
May 10, 2013, 1:00:04 PM5/10/13
to django-d...@googlegroups.com
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 reading

Simon

Donald Stufft

unread,
May 10, 2013, 1:12:33 PM5/10/13
to django-d...@googlegroups.com
On May 10, 2013, at 1:00 PM, Simon <si...@exonar.com> wrote:

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.

It's actually the opposite. More people read and participate on the mailing list than on the ticket tracker. So posting to the mailing list is actually a good way to get _more_ people to see your issue.


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. 

There was no progress because no one was willing to champion the feature on the mailing list.


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.

If I recall DDN was recently gotten rid of for exactly this problem. It wasn't clear who had the right to make said design decision and it often languished waiting for Jacob to have time to make a decision.


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

Proposing features is fine and is useful. However there are a massive number of features and bugs that people can work on. You're right in that if you're just tossing ideas out there it's unlikely that they will get added because for each new feature you need someone willing to do the work to discuss it, champion it, and implement it. If these features are important to you then engage the process and help shape Django.


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.

That's why the ticket wasn't accepted immediately. It hasn't gotten past that because no ones stepped up to advocate for the feature.


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?

While using tickets is fine if the project tends to do so but Django does not. So a lot of people simply don't pay attention to the ticket tracker while far more people are involved in the mailing list.


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 reading

Simon

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


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

signature.asc

Aymeric Augustin

unread,
May 10, 2013, 1:39:20 PM5/10/13
to django-d...@googlegroups.com
On 10 mai 2013, at 19:00, Simon <si...@exonar.com> wrote:

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

If you read our contributing guide, you'll understand that it's the exact opposite.

If I wanted to drown an issue, I'd just let it sit there, and nothing would happen.

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

The mailing-list is on Google Groups, all you need is to paste a link to the discussion in a comment.

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

You don't bother reading (or acknowledging) the previous comments, you leave a passive-aggressive 2-lines comment, a committer takes the time to write 20 lines in response, and your reaction is "shrug, just another rant"?

Step back and try looking at it from the other side.

Or, as an exercise, triage a few dozen tickets here:
https://code.djangoproject.com/query?status=!closed&stage=Unreviewed&desc=1&order=changetime
Just figure out what each ticket is about and:
- move it to "Accepted", or
- close it as "needsinfo" or "invalid",
with a comment explaining your decision.

Once you've done, say, 25 tickets, read Russell's answer again, and remember he triaged several thousand tickets over the history of Django. Maybe you'll understand his perspective better.

At worst, you'll have helped us a bit :)

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

And that's why we eliminated DDN a few weeks ago.

I personally made a decision on several hundred tickets. I'm not asking for anything in return. Please just don't imply the core team is slacking. Such feedback is clearly pushing me towards spending less time on Django and more with my family.

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

Indeed "I would like a pony" doesn't work. Building trust with the developers, discussing alternatives with their advantages and drawbacks, proposing patches, and avoiding snarky comments works much better.

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

Thanks for sharing your experience. I hope you'll find a friendlier community.

--
Aymeric.



Luke Plant

unread,
May 10, 2013, 6:41:12 PM5/10/13
to django-d...@googlegroups.com
Hi Simon,

> 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
> <https://code.djangoproject.com/ticket/901#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.

I'm afraid I really couldn't disagree more with your characterisation of
this situation.

If you just read the ticket, you'll find that different core developers
asked people to move discussion to the mailing list *3 times*, and quite
politely.

Everyone who comments after that point either hasn't read or has decided
to ignore *3 requests* about how to get the ticket to progress. And to
add insult to the injury of having wasted people's time already, some
start adding comments about how feature requests for Django are a waste
of time.

This is the height of rudeness, and if all they got was a sanctimonious
reply, they got better than they deserved.

I'm not claiming that we couldn't do better in terms of our clarifying
our processes and so on, but I think you picked an example that
demonstrates exactly the opposite of what you claimed.

Best regards,

Luke

--
"God demonstrates his love towards us in this, that while we were
still sinners, Christ died for us." (Romans 5:8)

Luke Plant || http://lukeplant.me.uk/

Wim Feijen

unread,
May 11, 2013, 3:47:58 AM5/11/13
to django-d...@googlegroups.com
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 decision 
2. the workaround 
3. 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. 

For me, the best way to proceed seems to raise this ticket to the mailing list and I will do so in a separate thread. 

Core devs, Aymeric, Luke, know that I have high esteem for the django community and especially for you. I thank you for your time and dedication to Django, your responsiveness and willingness to help newcomers and discuss even trivial details, which I truely admire; and the friendly atmosphere and openess and willingness to take seriously almost every remark a know-nothing like me can make, which I value highly.

Simon, the "jacob" you are speaking about is Jacob Kaplan-Moss, one of the founders of django and since then our benevolent dictator, who has spent so much time on django and made this community as it is. In this case, maybe he could have spent a bit longer on his answer; but maybe he was triaging a hundred tickets and therefor a bit in a rush.

Best regards,

Wim 

Russell Keith-Magee

unread,
May 11, 2013, 8:06:21 PM5/11/13
to django-d...@googlegroups.com
On Sat, May 11, 2013 at 3:47 PM, Wim Feijen <w...@go2people.nl> wrote:
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 decision 
2. the workaround 
3. 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. 

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? 

In this case, the requested course of action was very clear, and was communicated clearly on three occasions. We also have a contributions document that clearly documents our development process. The reason we have this document is because we don't have the spare resources to reproduce the same discussion every time the same problem arises. We get a dozen tickets a day; and a good proportion of those end up being closed. 

So - as clear as we think we've made the process, clearly "the message" didn't get through here. How do we fix this? 

Keep in mind when you're making suggestions, we have a certain number of constraints. We're all volunteers, so we don't have the power to compel anyone to do anything. We dot have the resources to micromanage every decision, so we need to have processes that are essentially self-managing. And keep in mind that one of the outcomes of every discussion about adding a new feature is "no" - just because someone *really* wants something, and *really* thinks it's a good idea, that doesn't mean we have to agree.

--

Nick Phillips

unread,
May 12, 2013, 7:34:01 PM5/12/13
to django-d...@googlegroups.com
On Sun, 2013-05-12 at 11:03 -0700, Jason Reethisma wrote:
> @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...
>

As someone who uses Django, and lurks (mostly) on this list, I have to
say that I think you have got completely the wrong end of the stick.

The tone of your mail is not constructive, and is provoking a negative
reaction even in me (and I am not one who has been putting massive
amounts of time into building Django, keeping the tracker in order, and
trying to keep the community running smoothly). I don't want to think
about how such posts must make the likes of Russell, Jacob & co react -
I can only say that in the years I've been here they've done a superb
job keeping the frustration in check.

This community, to me, is notable for the professional and courteous
manner in which people making demands are directed toward what they need
to do to have a chance of getting what they want. I'm not saying it's
perfect, but it deserves rather more credit than you appear to be
giving.

If there is little to no chance that a particular feature will be
implemented, it seems to me that is better for all concerned to close
down the discussion fairly sharplish - the submitter then doesn't waste
time thinking they're going to get something done about it, and the
developers don't waste time explaining again and again and again why the
submitter's latest rehash of the same argument is not going to make any
difference (submitter wrong, bad fit for Django, philosophical issues,
whatever - some people just don't seem to get the message).

I suggest you take Russell's post at face value, by the way. "Looking
for a positive outcome".

Well, perhaps face value plus a head of frustration that he's hiding
fairly well.

Thanks again to all of you who are making it happen.


Cheers,


Nick
--
Nick Phillips / nick.p...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago

Russell Keith-Magee

unread,
May 12, 2013, 10:51:44 PM5/12/13
to django-d...@googlegroups.com
On Mon, May 13, 2013 at 2:03 AM, Jason Reethisma <jreet...@gmail.com> wrote:
@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.

My apologies if I wasn't clear - that wasn't what I was saying at all. What I meant is that we can't institute a process like "Every core developer must spend 4 hours per week triaging tickets or they will lose their core developer status". This would be a completely reasonable course of action if you were a paid employee -- your employer is just telling you what you have to do to get paid -- but that dynamic doesn't exist in a volunteer project. In a volunteer project the only reason the "hard" stuff gets done is because people volunteer to do it.
 
However, in this case, Jacob *did* give a detailed explanation:

"This seems like a needless function; it's already possible to just re-look-up the object from the database."

It was rejected because the need wasn't clear. Simon then reopened the ticket, and gave a detailed use case, to which Jacob responded:

"I'm really not convinced by Simon's use case -- adding "reload()" only saves you a single line of code. Let's do our best to keep Django as svelte as possible."

What more detail should Jacob have provided? The feature isn't that complex. It's not like he's got an opportunity to present a PhD thesis in relational algebra. It's a simple feature, which has been rejected because in Jacob's opinion, it can be achieved in other ways.

Jacob didn't explicitly call for a discussion on the mailing list. Perhaps he should have. However, when the ticket was reopened for the second time, James Bennett (ubernostrum) pointed at project policy to have these discussions on the mailing list.

What should James have done instead?

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

Sure, but Wim highlighted problems - he didn't suggest solutions. 

I agree that in this example, and in some others, the three problems described by Wim exist. 

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. However, it's clearly failing in some respects. We need the community to guides us on the *concrete* improvements we can make. 

This isn't political equivocating. Its a genuine call to the community to tell us how we can make things better.

Yours,
Russ Magee %-)

Aymeric Augustin

unread,
May 13, 2013, 3:04:20 AM5/13/13
to django-d...@googlegroups.com
On 13 mai 2013, at 04:51, Russell Keith-Magee <rus...@keith-magee.com> wrote:

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.

Not only do we think it works, but we have positive evidence that it does.

Wim Feijen did what we repeatedly suggested on the ticket that sparked this discussion: he started a discussion on this mailing-list. His post piqued the interest of Anssi, and as a result, the ticket is now accepted with a plausible implementation plan.

-- 
Aymeric.



Tom Evans

unread,
May 13, 2013, 5:13:10 AM5/13/13
to django-d...@googlegroups.com
Perhaps the issue is that there is a feeling that no-one is listening
to the community? This particular issue was shot down because a core
dev didn't like the style of the change. They felt that adding a
function to be explicit about reloading an object is wrong since it
bloats django.

This was decided 5 years ago, communicated in a single line. Any
attempt by the community to say "wait a minute, I'd really like this"
gets shot down and told to bring it here, or worse. 3 days ago, the
response was "If you want it, you have to make it happen."

Perhaps this wasn't clear, that was a member of your community trying
to make it happen. There have been several attempts over the past 5
years by people trying to make it happen. Each time someone has tried
to make it happen, after the initial attempt, the ticket has been
re-closed "BFDL already said no, just go away".

In this case, happy days, a few hours of discussion on the ML, and
this ticket is now accepted. You need to understand that not all of
your users are comfortable or capable of advocating on mailing lists,
but are happy to contribute to tickets. With this ticket, 5 years of
asking for this feature on the ticket was pointless, and this is what
the OP is railing against. You gave people a way to contribute, but
then ignore them. Perhaps "ML or GTFO" if not the right approach for
attracting contributors.

Cheers

Tom

Shai Berger

unread,
May 13, 2013, 6:46:58 AM5/13/13
to django-d...@googlegroups.com
Hi,

On Monday 13 May 2013, Tom Evans wrote:
>
> Perhaps this wasn't clear, that was a member of your community trying
> to make it happen. There have been several attempts over the past 5
> years by people trying to make it happen. Each time someone has tried
> to make it happen, after the initial attempt, the ticket has been
> re-closed "BFDL already said no, just go away".
>
> In this case, happy days, a few hours of discussion on the ML, and
> this ticket is now accepted. You need to understand that not all of
> your users are comfortable or capable of advocating on mailing lists,
> but are happy to contribute to tickets. With this ticket, 5 years of
> asking for this feature on the ticket was pointless, and this is what
> the OP is railing against. You gave people a way to contribute, but
> then ignore them. Perhaps "ML or GTFO" if not the right approach for
> attracting contributors.
>

I'm trying hard to get something positive out of this. There are two points I
see, which may be valid:

- For some users, "a mailing list" sounds like some arcane thing that requires
specialized, "old-people" software to access. For those users, it may make a
difference if we just point out that the mailing list is a Google Group and
they can post to it through the web; just add a link when we send them to the
mailing list. In ticket 901, links to the mailing list were only posted by
Wim, after he had raised the discussion.

- The mailing list (through mail or through the web) requires you to be
registered before you can post, while Trac allows anonymous posting. I am all
for the argument that if one can't be bothered to register, they can't be seen
as "trying to make it happen" -- it's just that the mailing list has one more
little bump on the way to making a statement.

Other than that, I really can't grasp how "go to the mailing list" is
interpreted as "go away".

HTH,
Shai.

Chris Wilson

unread,
May 13, 2013, 5:12:45 AM5/13/13
to django-d...@googlegroups.com
Hi all,

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.

If I may make a suggestion to be considered by the community:

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'd like to feel that reload() and first() are cases where a core
developer might choose to close a ticket with this new status instead of
WONTFIX. I would also hope that the core developers might be gentler with
newbies like me instead of scaring us off with a gruff one-word reply of
WONTFIX.

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.

Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

Donald Stufft

unread,
May 13, 2013, 7:18:34 AM5/13/13
to django-d...@googlegroups.com
> --
> 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.
>
>

I think the problem with voting on an issue is that it will make people feel justified in asking/demanding a feature that doesn't have a chance of going on. A bad idea with a 100 yes votes isn't going to get in any more than a bad idea with 1 yes vote.

That's not to say it's not an ok idea. I don't know if it is or not. But it is an issue and folks will feel like # of votes justifies bad ideas getting implemented.
signature.asc

Łukasz Rekucki

unread,
May 13, 2013, 8:20:40 AM5/13/13
to django-developers
On 13 May 2013 11:12, Chris Wilson <ch...@aptivate.org> wrote:
Hi all,


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.

If I may make a suggestion to be considered by the community:

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.

You can blame this on my lack of social skills, but I really don't see how it's rude. It's informative: in current state the issue won't be fixed. Yes, it is possible to change the status to Accepted, but only if new facts arise (i.e. change of ecosystem, change in design). Note that the current proposal for refresh() differs significantly from the original one and that's the reason for accepting, not a core dev's change of heart. You can't have *that* pony, but it doesn't mean you can have *any* ponies.
 

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 fear it will end the same way as "Design Decision Needed" aka. Limbo. It's a really horrifying state where the issue is nor dead nor alive and lingers for all eternity causing even greater frustration for both the reporter and developers. 


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.

In my experience, people will vote for issue without giving much thought about it because clicking on a webpage doesn't cost anything, while presenting reasonable arguments on a mailing list requires at least a little research.  Also, you would need negative votes and I suspect that would probably cause even more tension then "WONTFIX" status.

Although there is one major flaw in the voting system/tracker I sometimes see: -1 votes (setting WONTFIX is effectively a veto just like -1) without giving conditions for improvement to at least -0. Having a clear path of action (even a one that involves a lot of work) to convince the person vetoing your proposal is always better then just "No, I don't think it's useful".


--
Łukasz Rekucki

Jacob Kaplan-Moss

unread,
May 13, 2013, 11:10:49 AM5/13/13
to django-developers
Hi Tom --

It really sucks that when I say "if you have feedback please send it
over here", you hear "I'm not listening".

I'm sorry, but I don't have the mental bandwidth to follow 20,000
individual tickets. It's impossible. I just fucking can't do it.
Believe me, I've tried, and failed, many times. I'm sorry I'm such a
slacker.

I *do* have the bandwidth to follow a single mailing list. If you want
my attention, that's how you get it.

If you really want to help, if you really want to get a positive
outcome from this, then how about you give me a hand and follow (part
of) Trac for me? Watch some tickets, and if/when they get stalled
bring them here.

Jacob

Jacob Kaplan-Moss

unread,
May 13, 2013, 11:23:05 AM5/13/13
to django-developers
On Mon, May 13, 2013 at 2:12 AM, Chris Wilson <ch...@aptivate.org> wrote:
> The status WONTFIX sounds awfully rude to me.

I've thought so, too, but every time I've tried to come up with an
alternate name I've failed. Any suggestions?

FWIW, "won't fix" has a long history as a term of art in bug tracking;
it refers to issues that, while *valid*, aren't going to be fixed for
some reason or another. That's in stark contrast with "invalid" issues
which are for whatever reason not actually an issue. It's important to
be clear when you mark a ticket "won't fix" that it's a conscious
decision not to do something (rather than trying to pretend that the
something isn't actually a thing.)

So in some sense a "won't fix" state is always going to be pretty
blunt: it's saying that we acknowledge the issue but we're not going
to do anything about it. We can slap a prettier name on it, but we
should avoid anything that isn't clear about exactly what's going on.
In the long run it's better to be clear and say "sorry, we're not
going to do anything about this" (hopefully adding "because X Y Z")
than to say something nice but incorrect like "ooh great idea we'll
think about it!". This is why we killed DDN: it was a way for us to
dodge saying "no", and in the long run I think it's better to say "no"
outright than to pretend something has a chance when it clearly
doesn't.

I know Trac's frustrating, and I'm constantly looking for ways to
improve it. But there's only so much we can do in software when at the
end of the day the message we're sending is one that people aren't
always going to want to hear. There's always going to be some pushback
when we tell people that we won't or can't do what they want, and no
amount of labeling is going to fix that.

So let's do what we can to make it better, but we also need to not
think that there's going to be some magic technical fix to this
problem.

Jacob

AK

unread,
May 13, 2013, 12:06:59 PM5/13/13
to django-d...@googlegroups.com
On 05/13/2013 11:23 AM, Jacob Kaplan-Moss wrote:
> On Mon, May 13, 2013 at 2:12 AM, Chris Wilson <ch...@aptivate.org> wrote:
>> The status WONTFIX sounds awfully rude to me.
>
> I've thought so, too, but every time I've tried to come up with an
> alternate name I've failed. Any suggestions?



WONTFIX does sound rude to me, as well. Perhaps 'onholdindefinite' can
be used instead, the effective meaning is the same, just the term itself
is more polite. It seems that nobody looking at it would think "I'll
just wait for a while and surely it'll get fixed.". Instead, anyone
needing it would think "If it is to be fixed, it's clear someone has
to make a case for it." -ak

Luke Sneeringer

unread,
May 13, 2013, 12:11:57 PM5/13/13
to django-d...@googlegroups.com

On May 13, 2013, at 10:06 AM, AK <andre...@gmail.com> wrote:

> WONTFIX does sound rude to me, as well. Perhaps 'onholdindefinite' can
> be used instead, the effective meaning is the same, just the term itself
> is more polite. It seems that nobody looking at it would think "I'll
> just wait for a while and surely it'll get fixed.". Instead, anyone
> needing it would think "If it is to be fixed, it's clear someone has
> to make a case for it." -ak

Note: "won't fix" is used on many bug systems, not just Django. So, in choosing to go for a euphemism, you're also (unintentionally) obfuscating, because you're subtly communicating that it's somehow different than the standard "won't fix".

Best Regards,
Luke Sneeringer

Kirby, Chaim [BSD] - PED

unread,
May 13, 2013, 12:13:41 PM5/13/13
to django-d...@googlegroups.com
WONTFIX has a long history in software development. It also does (correctly) state intentionality that 'onholdindefinite' lacks. The intention of WONTFIX is "yes, this is possibly valid, but in the state this ticket is written it is being closed". Using anything else that doesn't close the ticket just lets it hang out as cruft.   

Michael Manfre

unread,
May 13, 2013, 12:19:27 PM5/13/13
to django-d...@googlegroups.com
I think it's better to follow the convention used by almost every other bug tracker and stick with WONTFIX. Changing the name will be confusing. I think the best route forward is to not take bug status wording as a personal offense and be happy that those that set the status almost always give an explanation as to why the case is being closed.

Regards,
Michael Manfre


Tom Evans

unread,
May 13, 2013, 12:56:26 PM5/13/13
to django-d...@googlegroups.com
On Mon, May 13, 2013 at 4:10 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> Hi Tom --
>
> It really sucks that when I say "if you have feedback please send it
> over here", you hear "I'm not listening".
>
> I'm sorry, but I don't have the mental bandwidth to follow 20,000
> individual tickets. It's impossible. I just fucking can't do it.
> Believe me, I've tried, and failed, many times. I'm sorry I'm such a
> slacker.

I don't think anyone is asking you to do this. This ticket in question
wasn't lacking bandwidth from committers, it was visited many times by
committers, who each time summarily dismissed the ticket - "We're not
doing this because x years ago, God said thus". There was enough
mental bandwidth for it to be covered 4 times over.

I'm aware that I'm simplifying a complex scenario by reducing it to a
single case, but this is the kind of response I've seen all over
tickets, emails and so on.

You're not the only person who has time constraints, each of has a
choice of what we work on in our spare time. When I read these sorts
of tickets, perfectly valid feature requests knocked down for
precisely no reason, why should I waste my time trying to jump through
these arbitrary hoops? The short answer is I don't, I work on my own
projects.

What I read in the OP was someone who felt in a similar situation.

>
> I *do* have the bandwidth to follow a single mailing list. If you want
> my attention, that's how you get it.
>
> If you really want to help, if you really want to get a positive
> outcome from this, then how about you give me a hand and follow (part
> of) Trac for me? Watch some tickets, and if/when they get stalled
> bring them here.

Ho hum, so a lack of engagement with parts of the community is my fault is it?

I have to stay current with Django to be competent at my job, which
means following these mailing lists. I also benefit from Django, so I
feel compelled to help out as I can, which I do by contributing to
users@.

When it comes to open source work, you can't compel people to work on
what you want them to work on, people will work on what they want to
work on. If you make it so that it is hard for them to work on it,
they won't work on your project. If you look objectively at both mine
and the OPs posts, ignore the bits that make you angry, maybe you will
see that you're losing potential contributors. Maybe you won't, I'll
go back to lurking.

This is your project, so how you structure it and accept feedback is
entirely under your control. You could set something up to mail
developers@ iff a ticket is re-opened after being closed if you want
the discussion on here and not on tickets. At the moment, you invite
people to make comments on tickets and then ignore them.

The problem that I thought this thread was discussing was "Why do lots
of people feel there is an engagement issue". If only I had known that
it was about finding mugs to do triage..

Cheers

Tom

Anders Steinlein

unread,
May 13, 2013, 1:16:30 PM5/13/13
to django-d...@googlegroups.com
On Sun, May 12, 2013 at 2:06 AM, Russell Keith-Magee <rus...@keith-magee.com> wrote:

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? 

I've been lurking on this thread (and list in general for that matter), and thought I'd throw in my $.02 as someone interested in, but not (yet) involved in, development of Django itself.

I very much understand the policy of having discussions on the mailing list (particularly in the view of duplicate/related tickets), but I also see (and sometimes myself feel) the frustration OP brought up.

Why allow comments on tickets at all when discussions are meant to happen here? I understand the need to comment on the specifics of patches/doing reviews, but from a (new) user's point of view, those are just comments like any other. When some comments are welcome, but others are not, how are new user's supposed to know where to discuss what?

How about allowing comments only from the patch author and committers? With a big fat informational text in place of the add comment section? How about adding a button/link directly to the Google Group with "open for discussion" or some such? Just throwing out some ideas here.

Regards,
Anders

Yo-Yo Ma

unread,
May 13, 2013, 1:55:01 PM5/13/13
to django-d...@googlegroups.com
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).
 

Shai Berger

unread,
May 13, 2013, 2:07:21 PM5/13/13
to django-d...@googlegroups.com
Hi Tom,

On Monday 13 May 2013, Tom Evans wrote:
>
> You're not the only person who has time constraints, each of has a
> choice of what we work on in our spare time. When I read these sorts
> of tickets, perfectly valid feature requests knocked down for
> precisely no reason, why should I waste my time trying to jump through
> these arbitrary hoops? The short answer is I don't, I work on my own
> projects.
>
You are missing two crucial points:

> perfectly valid feature requests knocked down for precisely no reason

1) The feature requests you are talking about have all been considered and
rejected by committers. There is an assumption that committers do want to
improve Django and do not reject suggestions at a whim; that there is a reason
for the rejection. You may not like the reason, but that's a different story
and point.

> why should I waste my time trying to jump through these arbitrary hoops?

2) The "hoops" are not arbitrary. I see two points in the requirement to go to
the mailing list:

- The point mentioned many times in this discussion: The mailing list is much
more visible than any single ticket.

- Saving committers' time. While it's true that
> You're not the only person who has time constraints
committer time is the most scarce resource of the Django community. So if a
committer has already spent some time on a ticket, I'd rather have some other
people look at it before requiring committers' attention again.

My (non-committer's) 2 cents,

Shai.

Chris Wilson

unread,
May 13, 2013, 3:15:49 PM5/13/13
to django-d...@googlegroups.com
Hi Luke,
I think it *IS* different to the standard "won't fix". The standard one
implies "won't fix EVER" to me, whereas I think the way Django uses this
status is "won't fix until someone persuades on the mailing list." Which
could be expressed better than that, I'm sure. I did suggest a couple of
other options: NEEDINFO and DISCUSSION. I could suggest some more:
ITSAPONY? JUSTIFY?

I think we're lucky to have a community where it's possible to persuade
the BDFLs to change their minds, and unlucky to have an unfriendly-looking
bug tracker which dissuades people from trying.

Chris Wilson

unread,
May 13, 2013, 3:16:39 PM5/13/13
to django-d...@googlegroups.com
On Mon, 13 May 2013, Kirby, Chaim [BSD] - PED wrote:

> WONTFIX has a long history in software development. It also does
> (correctly) state intentionality that 'onholdindefinite' lacks. The
> intention of WONTFIX is "yes, this is possibly valid, but in the state
> this ticket is written it is being closed". Using anything else that
> doesn't close the ticket just lets it hang out as cruft.   

I'm OK with it being a closed state, if that helps. I'd just prefer a
slightly friendlier name for it.

Yo-Yo Ma

unread,
May 13, 2013, 3:47:15 PM5/13/13
to django-d...@googlegroups.com
There is a fundamental problem here, albeit one that is rooted in simple misunderstanding.

The burden of proof is on the originator of an idea (i.e., the ticket reporter). Arguments can be made against the idea in the ticket. Rebuttal is sent elsewhere. Regardless of the intention, this automatically creates contention (in some cases) because it appears as a double standard, as arbitrary discretion is used to draw a line in the sand (the point at which the discussion should be moved to the mailing list).

The solution could be either:

A) Allow for full discussion in a ticket (this may not be an option, based on the conversations I've read)

or

B) Disallow only technical (how to fix, code review, etc.) discussion in a ticket, and make it easy to get from a ticket to its discussion thread and back again.

Option A allows for easier collaboration on business aspects by incorporating technical considerations into the conversation at the expense of extra noise.
Option B allows for easier digestion of either tech or business at the expense of a lack of cohesion among both parties.

Aymeric Augustin

unread,
May 13, 2013, 4:35:11 PM5/13/13
to django-d...@googlegroups.com
On 13 mai 2013, at 21:15, Chris Wilson <ch...@aptivate.org> wrote:

> I think it *IS* different to the standard "won't fix". The standard one implies "won't fix EVER" to me, whereas I think the way Django uses this status is "won't fix until someone persuades on the mailing list." Which could be expressed better than that, I'm sure. I did suggest a couple of other options: NEEDINFO and DISCUSSION. I could suggest some more: ITSAPONY? JUSTIFY?

These are nuances, and nuances are better conveyed by comments in English than by states. If you look at tickets closed "wontfix", many also have a comment along the lines of "if you disagree please explain X and Y on the mailing-list".

Using a state instead of a full sentence would be less helpful. One-off contributors won't peruse the contributing guide to figure out what the state precisely means and what the next step is.

Having less states forces everyone to write complete comments, and I believe that's a good thing, even though it takes me a lot of time. It puts everyone on an equal footing, regardless of how familiar with the tracker they are.

--
Aymeric.

AK

unread,
May 13, 2013, 5:26:08 PM5/13/13
to django-d...@googlegroups.com
I should have mentioned that I know it's used on other bug systems, and
that I agree it's less clear. It's a tradeoff that you often have when
you try to be polite: the alternatives are usually more blunt and clear.
In this particular case, I don't think it's a problem because there are
only two choices here - either someone cares about the ticket being
fixed, or not.

If not, there's no problem. If yes, the main message will not be lost:
"this ticket isn't going to get fixed and you have to convince someone
if you want that to happen."

I agree 'onholdindefinite' is a bit awkward, I think it's a bit better
than wontfix but wontfix isn't terrible either.

-ak

AK

unread,
May 13, 2013, 5:40:34 PM5/13/13
to django-d...@googlegroups.com
> --


Perhaps a good rule would be: if you ask someone to raise the issue on
mailing list, a link to the google group page must always be given in
the same comment. It's reasonably easy and it's a lot more inviting to
give the link vs. "There's a mailing list out there somewhere, go and
find it, why don't you?" -ak

Peter

unread,
May 13, 2013, 6:21:04 PM5/13/13
to django-d...@googlegroups.com
I have a thought on an action we could take out of this that might be constructive.

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

Joe Tennies

unread,
May 13, 2013, 7:55:14 PM5/13/13
to django-d...@googlegroups.com
As a fellow lurker (sorry I've been using Flask more recently), I think this could simply be fixed via a form response. Here's a simple example:

This bug is being marked as "WONTFIX" because <reasoning>

Please realize that every API/feature added to Django needs to be maintained across several versions. The more public APIs that are exposed to users, the more difficult it is to refactor and add other features. This request currently lacks enough merit to exceed the cost it will add to the maintenance of Django.

Possible solutions:
* Create a separate library to implement this feature. With enough use, the merit may be more obvious.
* Start a discussion on https://groups.google.com/group/django-developers. Please note that a stronger case will be needed to overturn this decision, though the community may be able to help build that case. That community may be best reached on https://groups.google.com/group/django-users or on IRC at #django on irc.freenode.net.

Even the reasoning in the comment and the above via a link would help (to allow the form to be updated if someone words it better). (can you make the "WONTFIX" link to that description or do a mouse over comment box?


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





--
Joe Tennies
ten...@gmail.com

Anders Steinlein

unread,
May 13, 2013, 9:26:49 PM5/13/13
to django-d...@googlegroups.com
On Mon, May 13, 2013 at 7:55 PM, Yo-Yo Ma <baxters...@gmail.com> wrote:
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).

I actually meant the one opening the ticket as opposed to patch author, thinking momentarily that they are one and the same. Ticket openers, patch authors and committers should be allowed to comment in such a setup.

A.

Jacob Kaplan-Moss

unread,
May 13, 2013, 9:27:48 PM5/13/13
to django-developers
On Mon, May 13, 2013 at 9:56 AM, Tom Evans <teva...@googlemail.com> wrote:
> I don't think anyone is asking you to do this. This ticket in question
> wasn't lacking bandwidth from committers, it was visited many times by
> committers, who each time summarily dismissed the ticket - "We're not
> doing this because x years ago, God said thus".

Look, that's not what we said. If you insist on finding the most
negative characterization for our words and motivations, I don't
really see why we should engage you further.

Can you please try to assume some good faith on our part?

Jacob

Ryan Hiebert

unread,
May 13, 2013, 10:15:22 PM5/13/13
to django-d...@googlegroups.com
If Trak is customizable enough, it might be good to have the ticket template always have a link to the Google Group. Label it "Google Group/Mailing List", and then a comment that says "let's move this discussion over to the mailing list" can be a simple click on a link, and you're at the mailing list. Hopefully, that could help to eliminate the overhead associated with getting the discussion to the right place to make progress.

ApogeeGMail

unread,
May 13, 2013, 7:23:12 PM5/13/13
to django-d...@googlegroups.com
hi all:

Long time lurker. Would like to say that I have benefited greatly from the expertise on the group, and to extend my thanks to all the developers who have contributed with such undying enthusiasm to Django and the simple users and noobies on this list and the users group.

Having been in SW development for 30+ years, I think the approach of the BDFL is one of the best I have ever seen.

So, Thanks to all, from those you listen and lurk!!

Richard

Daniele Procida

unread,
May 14, 2013, 6:56:26 AM5/14/13
to django-d...@googlegroups.com
On Mon, May 13, 2013, Łukasz Rekucki <lrek...@gmail.com> wrote:

>> 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.
>>
>
>You can blame this on my lack of social skills, but I really don't see how
>it's rude.

Maybe it's not rude, but it is off-putting. Perhaps there are some proposals that really do deserve to have the door closed firmly in their faces - that's what "WONTFIX" suggests to me, even if it's not what's intended.

Daniele

Sam Solomon

unread,
May 14, 2013, 7:18:40 PM5/14/13
to django-d...@googlegroups.com
As an outsider with very little data (so you can ignore this if you strongly disagree), I sort of agree with the notion that "WONTFIX" could be sending a different signal that it is being used for.

WONTFIX to me would mean, "We acknowledge that this is an annoyance for some people, but we're not going to fix it no matter what you or anyone else says".

Maybe a compromise is using a variation on the same terminology but softening it to "PROBABLYWONTFIX" when it's something that you don't think is a serious problem but could theoretically be swayed with a good proposal and other people stepping up to submit patches and fight for the feature.

"WONTFIX" would still be appropriate for firm "no, never, this isn't just a poorly stated proposal, it's either too difficult or is actually counter to our overall goals even though it is a valid 'issue'".

Some references of WONTFIX in the wild/in other contexts/discussions:


http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use "WONTFIX is used for things that are valid requests, but that the team can't do"

Cal Leeming [Simplicity Media Ltd]

unread,
May 14, 2013, 8:41:54 PM5/14/13
to django-d...@googlegroups.com
Hello all,

I just spent around 90 minutes reading through everyones comments (word for word), and writing up a reply offering my two cents.

First off - a few years back someone introduced a 5-for-1 system where if you triaged five other tickets, you could request for a core dev to give detailed attention to any ticket of your choice. I think this is an EXCELLENT way of giving something back to the community, keeping the ticket queue down, and getting the results that you need.

From core devs point of view - Posting a discussion to django-developers and raising a ticket in Trac are not for the lighthearted. If you want something in the core, you better have a good argument for it and be prepared to follow it through to the bitter end. If you simply post a suggestion without justification, then you can't expect the core dev to sign it off, they are not mind readers. It's also generally accept that although the core devs are polite, they will give you their brutally honest truth which can sometimes be misinterpreted as rudeness. The core devs are not here to be friendly, they are here to keep Django alive.

From users point of view - One of the responses from the core developers was, look if you want this feature, help us make it happen. But the majority of users are not familiar with the internals of how Django works, and would find it difficult to contribute the quality of code (if at all) required for inclusion into the core. Sometimes people want to help and contribute, but the process can be confusing and engaging with the core devs in a discussion can often be a frustrating thing for those who are new to the world of open source contributions.

However, Tom raises a very good point when he said "why should I waste my time trying to jump through these arbitrary hoops? The short answer is I don't, I work on my own
projects". Personally, I have become extremely frustrated at some of the decisions and lack of attention being shown on some of these tickets in the past. But it could also be argued that I should have stood my ground and put forward a solid argument.

Yo-Yo Ma raises an important point of "The burden of proof is on the originator of an idea", and this is in-line with my above comments. Shai also raises a good point, that core devs time is scarce and often would like some other people to give tickets a flick over before going back to it.. core devs do not have time to give each ticket their full attention. Imho, if you want the extra time, you have to earn it (either in contributing, or putting forward a solid argument). Look at it like this, for every 5 minutes you put in, you can get back roughly 1 minute from a core dev (YMMV). 

I think really this all comes down to a lack of understand about the Django etiquette, and users feeling like the core devs are not really giving them the attention they expected. 

Therefore, I propose the following recommendations;

* Make the 5-for-1 (or 10-for-1) system official, not many people seem to realise this exists. This will give incentive to core devs to spend a bit longer on a ticket, maybe even throwing in a pleasentry or two (optional). I often found that if I assisted with other tickets and showed myself to be proactive on the ML, then my tickets would usually get the attention of a core dev faster and/or with more detailed response.

* Explain what wontfix means to users, and what they can do to change it (without having to read page after page of contribution instructions). Perhaps some sort of automated response that explains all this, and points the user to the mailing list. Until Kirby explained what wontfix meant a few posts back, I had assumed it meant "this is not acknowledged".

To summarize my thoughts in a simple bullet point list;

* Core devs are not here to be friendly, expect polite yet brutal honesty, with no pleasantries.
* If you want 5 minutes of core dev time, spend 1 hour triaging tickets and link with proof (5-for-1).
* Trac could be so much better
* Explain what wontfix means to users, and that they need to present a solid argument with proof to get it looked at again

Cal

On Fri, May 10, 2013 at 6:00 PM, Simon <si...@exonar.com> wrote:
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 reading

Simon

Luke Plant

unread,
May 15, 2013, 6:20:41 AM5/15/13
to django-d...@googlegroups.com
Hi Joe,


On 14/05/13 00:55, Joe Tennies wrote:
> As a fellow lurker (sorry I've been using Flask more recently), I think
> this could simply be fixed via a form response. Here's a simple example:
>
> This bug is being marked as "WONTFIX" because <reasoning>
>
> Please realize that every API/feature added to Django needs to be
> maintained across several versions. The more public APIs that are
> exposed to users, the more difficult it is to refactor and add other
> features. This request currently lacks enough merit to exceed the cost
> it will add to the maintenance of Django.
>
> ...

I think we need something shorter that developers can remember, i.e.
that we can type ourselves without resorting to a canned response,
1which can be off-putting, especially if some of it doesn't apply.

So I've gone ahead and created a wiki page, which can be longer and more
friendly, and require a shorter response on the actual ticket, something
like this:

Closing as WONTFIX because ...

If you want to persuade us otherwise, please bring it up on the
DevelopersMailingList

The page:

https://code.djangoproject.com/wiki/DevelopersMailingList

That's my draft, feel free to edit. We don't want it too long, as that
is intimidating by itself, but some of the points you make might would
be good additions

What do people think?

Luke

--
"I asked mom if I was a gifted child. She said they certainly
wouldn't have paid for me." (Calvin and Hobbes)

Luke Plant || http://lukeplant.me.uk/

Shai Berger

unread,
May 15, 2013, 7:20:29 AM5/15/13
to django-d...@googlegroups.com
On Wednesday 15 May 2013, Luke Plant wrote:
>
> So I've gone ahead and created a wiki page, which can be longer and more
> friendly, and require a shorter response on the actual ticket, something
> like this:
>
> Closing as WONTFIX because ...
>
> If you want to persuade us otherwise, please bring it up on the
> DevelopersMailingList
>
> The page:
>
> https://code.djangoproject.com/wiki/DevelopersMailingList
>
> What do people think?
>
> Luke

+1

Shai

Aymeric Augustin

unread,
May 15, 2013, 12:56:09 PM5/15/13
to django-d...@googlegroups.com

On 15 mai 2013, at 12:20, Luke Plant <L.Pla...@cantab.net> wrote:

> So I've gone ahead and created a wiki page, which can be longer and more
> friendly, and require a shorter response on the actual ticket, something
> like this:
>
> Closing as WONTFIX because ...
>
> If you want to persuade us otherwise, please bring it up on the
> DevelopersMailingList
>
> The page:
>
> https://code.djangoproject.com/wiki/DevelopersMailingList
>
> That's my draft, feel free to edit. We don't want it too long, as that
> is intimidating by itself, but some of the points you make might would
> be good additions
>
> What do people think?


That's very helpful.

Actually we already have a few wiki pages for this purpose:
https://code.djangoproject.com/wiki/TicketClosingReasons

They have varying levels of detail, and some could use an
update. I suggest moving the page you just created there,
so it's easier to locate it in the future.

This is also a reminder to triagers that these answers exist.
I agree with Luke that they should be used in combination
with a short and specific explanation.

--
Aymeric.



ptone

unread,
May 15, 2013, 2:36:25 PM5/15/13
to django-d...@googlegroups.com
Luke,

Thanks for taking a stab at improving things, I think one thing is not in question - everyone is willing to make improvements best we can.

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


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.

One line I do feel needs a tweak:

"while the suggestion is good in theory, it lacks enough merit to exceed the cost it will add to the maintenance of Django"

The truth is, there are some suggestions that are just flat out incompatible. I'm fine to be gracious and thankful for the time someone takes to offer a suggestion, but that doesn't mean that all suggestions are automatically meritorious.

Saying that in as kind a way as possible is tough - but only fair.

-Preston

Jacob Kaplan-Moss

unread,
May 15, 2013, 8:51:50 PM5/15/13
to django-developers
As suggested to me (privately) by Tom Evans, I've started trying to
keep an eye on tickets that bounce back and forth between open and
wontfix. If a ticket "bounces" a few times it's probably a sign that
there's something going on, and we may want to proactively start a
mailing list thread rather than waiting for "someone" to do it.

https://www.djangoproject.com/trac/bouncing/ is that view; I hope
you'll help me keep an eye on it and bring stuff here if it needs
bringing.

Thanks again for the suggestion, Tom.

Jacob

Jacob Kaplan-Moss

unread,
May 15, 2013, 8:56:50 PM5/15/13
to django-developers
On Tue, May 14, 2013 at 5:41 PM, Cal Leeming [Simplicity Media Ltd]
<cal.l...@simplicitymedialtd.co.uk> wrote:
> * Make the 5-for-1 (or 10-for-1) system official, not many people seem to
> realise this exists. This will give incentive to core devs to spend a bit
> longer on a ticket, maybe even throwing in a pleasentry or two (optional). I
> often found that if I assisted with other tickets and showed myself to be
> proactive on the ML, then my tickets would usually get the attention of a
> core dev faster and/or with more detailed response.

Consider it done - I'll take any and all 5:1 requests personally, and
I'll shame.... uh... *encourage* other core devs to do the same.

What do you think we should do to make it more "official"? Add it to
the contribution docs? Put it on the code.d.c somewhere?

Jacob

Cal Leeming [Simplicity Media Ltd]

unread,
May 15, 2013, 9:06:33 PM5/15/13
to django-d...@googlegroups.com
The fact that one of the core founders of Django has responded to say "Consider it done", is probably about as official as it can get.

I have gone ahead and written up a section explaining how the 5-for-1 system works, any amendments or additions would be welcomed.


The more people that know about this, the better.. if everyone could try and mention it in passing conversations on IRC, or on stale tickets/discussions etc. 

Hope this helps

Cal

Luke Plant

unread,
May 16, 2013, 7:16:57 AM5/16/13
to django-d...@googlegroups.com
On 15/05/13 19:36, ptone wrote:

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

That's a good idea. The purpose of this wiki page is to make it easy for
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".


> One line I do feel needs a tweak:
>
> "while the suggestion is good in theory, it lacks enough merit to exceed
> the cost it will add to the maintenance of Django"
>
> The truth is, there are some suggestions that are just flat out
> incompatible. I'm fine to be gracious and thankful for the time someone
> takes to offer a suggestion, but that doesn't mean that all suggestions
> are automatically meritorious.

I guess we would normally use INVALID for something that was just a bad
idea, whereas WONTFIX recognises there is a valid issue, but we're not
going to do anything about it. I've already removed reference to INVALID
on that page, but I'll tweak the text - feel free to make more changes.

Luke

--
"If something is hard, it's not worth doing." (Homer Simpson)

Luke Plant || http://lukeplant.me.uk/

Russell Keith-Magee

unread,
May 16, 2013, 8:29:06 AM5/16/13
to django-d...@googlegroups.com
On Thu, May 16, 2013 at 7:16 PM, Luke Plant <L.Pla...@cantab.net> wrote:
On 15/05/13 19:36, ptone wrote:

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

That's a good idea. The purpose of this wiki page is to make it easy for
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".

Patching Trac sounds like a really good idea to me. While I completely appreciate the intent of these wiki messages, the way those messages are "deployed" at the present strikes me as something that could easily be interpreted as rude. I'd like to see a much more "humane" usage of these messages, so that new users to Trac don't feel like they're interaction with Django as a project isn't a mechanical rejection.

Yours,
Russ Magee %-)

Cal Leeming [Simplicity Media Ltd]

unread,
May 16, 2013, 8:35:27 AM5/16/13
to django-d...@googlegroups.com
I was going to mention this before, but wasn't sure how to word it.

Russell has hit the spot though, giving the user a more personal experience, not just automated (or manual) copy-pasta.

Cal

--

Luke Plant

unread,
May 16, 2013, 10:44:38 AM5/16/13
to django-d...@googlegroups.com
On 16/05/13 13:29, Russell Keith-Magee wrote:

> Patching Trac sounds like a really good idea to me. While I completely
> appreciate the intent of these wiki messages, the way those messages are
> "deployed" at the present strikes me as something that could easily be
> interpreted as rude. I'd like to see a much more "humane" usage of these
> messages, so that new users to Trac don't feel like they're interaction
> with Django as a project isn't a mechanical rejection.

What kind of patching Trac are we talking about? I'm aware of two
suggestions I think:

1) If someone tries to re-open a ticket, we change it so they see some
message about the mailing list.

2) When a ticket is closed, a message is automatically added.

To me, both of these seem *more* mechanical and unfriendly than a
message that is composed by hand (which may link to an existing wiki
page or other docs). The first particularly will lead to people closing
tickets as WONTFIX without sufficient explanation, and the user getting
a 'doorslam' feeling (and probably won't get to the point of attempting
to re-open a ticket).

Regards,

Simon Litchfield

unread,
May 30, 2013, 9:21:32 AM5/30/13
to django-d...@googlegroups.com
Sorry I'm late back to the party boys and girls. 

Trivial as it may be, it's really just communication that's the only issue here, and I'm glad this has prompted a review. We all mean well and we're eager to help. The solutions Cal, Russ, Luke and co have discussed sound great. 

BTW- there are two Simon's here. I'm "simon29" from the original ticket, not "Simon" from this thread.
Reply all
Reply to author
Forward
0 new messages