Hi Russell, Thanks for clarifications of the process, but it seems I explained some things wrong.
I see some issues have the following problems: 1) second core developer review takes a year, 2) reviewers like me who are not core developers don't know if they will be able to say something new a ticket without reading it, and how to find such list of tickets. When you have not much pairs of eyeballs, it's very important to have good tickets coverage, and if some tickets don't get reviewed in a year, it does mean these eyeballs distribution among tickets isn't good. By "curator" I meant core dev team member, who got feedback last time (or sometimes someone else who can perform core team person job). This is different from ticket owner (yes, few years ago the ticket owner was "curator", but now tickets are assigned to patch developer). When I mentioned "sorting by time" I meant time of ticket last change, not ticket creation. I explain it that we currently don't have any way to find "stale" tickets, which are waiting for some specific action, but no one knows what exact action. I see it like all developers can be divided into 2 categories: - core dev member, who can make serious decisions, and - regular developers, who can only check if patch works, if they like syntax, if there's no any simple logical flaw, or if patch doesn't work for them, but they can't approve if patch solves the problem is right way. Usually one want to know if they patch solve the problem correctly before they polished patch and it got to RFC. And in this decision making i see the big difference before regular and core dev developers. Basically I want to know if I can do something on ticket without reading it through. If I can't -- I want to tell that I can't review ticket and who can. So, yes, the additions I propose can be mostly done automatic, with few exceptions: - ticket creator marks if issue can be reviewed by any developer or only core dev (if decision making process is still ongoing). The only current alternative now is django-dev mailing, I'm not sure if such mailing should be done every time more core dev clarifications are needed -- if it is so, I'll go through a couple of my bugs and lots of other people bugs and start a dozen of threads here right now. - regular developer marks if they're done with reviewing issue, and if the only issues left are decision making ones -- transforming to DDN again might be considered as an alternative here. On Mon, Aug 16, 2010 at 8:28 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: >To me, this points to a fairly glaring logical fallacy. If a robot can fill in new "reviewing" fields based on existing data, then doesn't that mean that the existing data is sufficient to determine reviewing state? Except these two differences marked above, yes, but you can't sort trac issues based on such derived data. ...Or maybe I'm so selfish and tend to complicate things (both is true), and my small ticket-being-able-to-review / ticket-read ratio should be ignored as one of the life inconveniences. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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.
