On Wed, Jun 11, 2008 at 6:46 AM, Edgars Jēkabsons <[EMAIL PROTECTED]> wrote: > > There are 1116 active tickets right now, 341 of them haven't even been > reviewed and 201 of the remaining 775 tickets are waiting on a design > decision from the core developers or community. I can't even know if > any of those 542 tickets is getting fixed at all or not.
Trac contains all the information you need. If a ticket is open and it's not assigned to somebody, then it's a safe bet that nobody is looking at it. If it _is_ assigned to somebody, but there hasn't been any activity (comments/patch uploads etc) recently, it's also a safe bet that nobody is working on it. > I understand that I can help by triaging the 341 unreviewed, I can't > at the moment imagine doing design decisions in the name of the > community though. This is a triage process - we're not asking you to make decisions for the community - we're asking you to filter the fire hose of tickets and give us a trickle we can manage. If a ticket describes something that is clearly a bug, move to accepted (or ready for checkin if it's a trivial problem with a patch and tests ready to go). If it's a new feature, or it's not obvious if the existing behavior is wrong, move it to "design decision required". If the report is incomplete or incoherent, close it as 'worksforme' or 'invalid' with a request for more details. Remember, none of these decisions are final - if a core developer or other triager disagrees with your assessment, we can always move to a different state. We just need to work out which tickets need further attention, and which ones we can forget about. > Release or not, this situation clearly calls for a sprint :) It also calls for volunteers. These tickets don't fix themselves, and you don't need a formal invitation or sprint to give you permission to work on them. The Django contribution guide [1] contains more details, but there is lots you could do to help out: * Review tickets - read the ticket, verify that the problem described actually exists. Close the ones that aren't, and make sure that there is an easy to reproduce test case if the issue is real. If the issue is non-compliance with a standard, provide some links to the relevant standards documentation. * Write patches for accepted tickets - pick an area of interest, and start fixing bugs. Make sure you have test cases and documentation for everything you are fixing. If you don't have docs and tests, you'd better have a pretty good reason why not. * Keep patches up to date - find some issues that you would like to see resolved, and make sure that the patches attached to those tickets haven't gone stale (i.e., they still apply cleanly to trunk). * Identify trends in tickets. When there is a recurring trend in tickets, that issue will generally get developer priority. For example, the queryset refactor branch was the response to a large number of tickets that could be tracked to a common cause. Newforms was a similar response to tickets regarding the oldforms manipulators. However, identifying trends is difficult. Triagers who spend a lot of time in the ticket database are in the best position to identify these trends and bring them to the attention of the core developers. So - don't hang around waiting for an invitation - roll up your sleeves and help out! [1] http://www.djangoproject.com/documentation/contributing/ 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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
