I've tried communicate with Brian via email before start discussion here. I take the email address from his github account. In email I ask he about his plans on this ticket, but don't get reply.
Originally I need to add some customization to admin change list requested by my clients. It's possible with some ways with current django.contrib.admin and I've need to found of the best of them. It's not related with template tags or something related with ticket #8054. To resolve my problem I have need to know about how admin change list is rendered. I thought, reviewing Daniel's patch is a short way to understand it. I like his idea. I port his patch on more newer version of Django, share it with community via Track and after some time from unfortunately communication with Brian try to promote it here. I don't know that I spent my time on no purpose. Anyway I've successfully done all my goals and in addiction learned about how django test suit is organized. If this ticket isn't useful for Django today, so this is life. On Thu, Nov 4, 2010 at 10:35 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > 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<django-developers%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- 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.
