Hi Russell, On Sat, Aug 14, 2010 at 2:03 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Sat, Aug 14, 2010 at 1:39 PM, burc...@gmail.com <burc...@gmail.com> wrote: >> I had few useful thoughts about changing the way Django development >> contributions gets accepted and committed -- but all I get from this >> mailing list that all attempts to improve any process is just a waste >> of time. > > That's not entirely fair. > > We're acutely aware of the fact that there is a backlog of tickets > that need attention. We're also aware that many people upload patches, > but then don't get any feedback on them. We want to improve this in > any way we can. > > If you have suggestions on how we can improve Django's development > process and address these issues, we're happy to hear them. > > However, that doesn't mean we're going to immediately implement a > suggestion just because it's been made. I don't know which suggestion > in particular you're referring to, but if you've made a suggestion and > we haven't acted on it, then I would suggest to you that this is > because we (the core team) didn't agree that your idea was as useful > or practical as you think it was. > > If you have a suggestion, please make it. We're listening.
Ok. I think the reviewing workflow should be improved in the way core developers, triagers and patch developers should get a list of tickets to work on. Please correct me if I'm wrong, but I don't see any mechanism that will allow you: a) to find issues that needs a review (not some issues, but all issues ordered by importance or date sent to reviewing) b) to mark issue as reviewed. c) to mark someone (core dev/someone else) as a curator on an issue, so core team doesn't repeat themselves reviewing each bug multiple times when it's not required. The problem issues don't get attention is that no one usually know they need their attention. Bug states don't help a lot: they mark the maturity of solution but not who's move is now. And current process from my point of view is a Monte-Carlo issue picking. It's not broken -- speed is almost the same (cause it's the speed of commit process), but absolutely no feeling of control. Also after the review/commit separation, we'll be able to tell exactly, if we need more reviewers, patch writers/rewriters, core dev team members or just committers. >> Core devs have no time even to accept working & looking good >> patches -- and rarely have time to review patches not looking good or >> working wrong! >> So why should I bother to write patches fast? > > I would point out that the core team aren't the only people that can > give feedback. Trac is an open resource for exactly that reason. Yes, this is one more point. Regular developers, like me, also don't know what to review, and for most of patches, they just can't write a review: they have high risk of writing wrong suggestion. Patch author or triagers usually know if people can write a review, but people can't find such issues. So probably "reviewers" bugs category should also exist, but should be also treated differently. If we agree with such a system, I can walk through all issues (probably with scripts), and write who needs to respond on each issue. Patch developers usually know whether everyone wants feedback from them, but I'd love if we were able to reduce core developers load with introduction of such system and adding more reviewers. Think of the following: every personal django branch on github can be considered as adding a reviewer & committer. Why not ask them to help with tickets? But then they need to know how they can help. We outline issues to write patches for, but not for review. Since tickets with needs_better_patch=1 could be both reviewed or not reviewed, I haven't find any way to get any reviewing queue. On implementation side, I consider two checkboxes with "[ ] needs public review" and "[ ] needs core dev review", and a button with "(Set me as a curator on this issue)", or maybe a text input for curator email. That way, DDN stage might not be needed -- it's just "unreviewed" + "needs core dev review". Date of last ticket update can be also added to the trac reports -- to sort tickets based on that date. A robot can be written to fill these fields based on other fields, comments authors, and knowledge of who are in core dev team. I would also consider an external service for reviewing and triaging, but that way you won't see review states in trac. -- 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.
