On Thu, Nov 4, 2010 at 12:33 PM, Alex Kamedov <kame...@gmail.com> wrote: > On Fri, Oct 29, 2010 at 7:47 AM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> Honestly, I can't see the benefit in what you're proposing here. >> Before you spend a whole lot more time updating the patch to try and >> make and keep it trunk ready, you need to convince me (or another >> member of the core team) that the idea you're proposing is worth >> adding to trunk. Otherwise you're just going to be spending a lot of >> time maintaining a patch that won't ever get committed. > > Hm. In this case why this ticket is on accepted triage stage and assigned on > the one from core team developers a long time?
I can see that you have done what you have done in good faith. However, I think you have misread the tone around the ticket. The problem is that the state of a ticket in Trac can only be used as an indication, not as an absolute guide. We allow anyone to modify tickets, so just because a ticket is "accepted" doesn't necessarily mean that the idea has been accepted -- you need to pay attention to *who* has accepted the ticket. Tickets also decay over time; an idea that seemed great and was accepted a year ago may not be accepted today, because of other changes that have occurred in Django. Lastly, (and most applicable to this case), a ticket that has been partially addressed may not be updated to reflect an accurate state of the ticket. Looking at #8054 specifically: The ticket was accepted on 13 August 2008, after an initial period in design decision needed. The design discussion entirely revolves around the idea of methods/functions as list_display items, and, on 14 August 2008 (r8352), that's exactly what Brian committed. Brian followed that checkin with a comment: "Moving to post-1.0 for the API changing parts. This should be looked at with a ChangeList and templatetag refactor of the admin. Not sure when or how, but this is related." Since that time, there has been no core team member involvement or discussions. I'm not aware of any django-dev discussions about the feature. However, there have been a couple of people maintaining the original patch -- the one that Brian decided *not* to apply in the first place. Reading between the lines, this means that the ticket really isn't in an accepted state anymore -- at the very least, it's DDN, and probably wontfix. I don't know what Brian had in mind at the time, but he obviously wasn't happy with the proposed approach, and two years later, I agree. > It is my first experience to send my code in this community, this ticket was > related to my needs, and I followed only instructions from official Django > documentation. First off -- what you have encountered with this ticket isn't my idea of an ideal first contribution experience. I can see that you have done everything that the contribution guide said to do -- it's just that the contribution guide doesn't do a good job of capturing the esoteric nature of "reading" Trac tickets. In that respect, we (the core team) have failed you. I wholeheartedly apologize for that. I suppose the only practical advice I can give would be the following: * Trac isn't an absolute; the context is just as important as the literal message. You need to take into account who says things, when they said them, and the completely ambiguous who *hasn't* said things. * If you're going to engage in a big project, it helps to make sure that your idea has support first. This means getting someone to confirm that a bug is real before you spend a whole lot of time fixing the issue, and confirming that the core team currently supports a proposed feature before you implement it. These are both points that the contributions guide doesn't do a good job of reinforcing, and it probably should. Ticket #14401 is a work in progress discussing a new "contributions howto" that would cover some of the fuzzy issues around contributing to Django; I've just updated the draft text to cover the points I've raised here. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
