Thanks! I might add that, for someone who just wants to jump in and do some random good for the project I found it hard to find pointers to "easy but necessary (perhaps slightly boring) tasks" on Trac.
Maybe I'm just an edge case :-) On Feb 1, 6:05 am, Russell Keith-Magee <[email protected]> wrote: > On Tue, Feb 1, 2011 at 11:45 AM, Brian Neal <[email protected]> wrote: > > On Jan 31, 7:35 pm, Russell Keith-Magee <[email protected]> > > wrote: > > >> The core team aren't the only people who can review tickets. In fact, > >> all you need is for someone who isn't you to review your ticket and > >> say that it looks good (by Django's standards -- which means > >> documentation, tests, PEP8 etc). Once you've reviewed a ticket and > >> you're happy, you can promote it to RFC -- which puts it much closer > >> to being committed. > > > Russ, the advice you gave above doesn't quite jive with what is here: > >http://docs.djangoproject.com/en/dev/internals/contributing/#triage-b... > > > "Please don’t promote tickets to “Ready for checkin” unless they are > > trivial changes – for example, spelling mistakes or broken links in > > documentation." > > > I held off on marking something RFC because of that. Can you please > > clarify? Thanks. > > Darn... i've been hoisted by my own petard... :-) > > That particular section of the docs is, to use the technical term, > wrong. :-) It was written back when we had the intention of > maintaining a formal triage team. That idea has proved itself > unworkable, because it doesn't actually remove the bottleneck, it just > makes the neck of the bottle ever so slightly wider. > > So, over time, the rules have drifted, until we're at the point we are > now. We've just been slack about updating the documentation of those > rules. There's even a ticket (#14401) that covers the need to do so. > Let's call this one more reminder of things I need to do. > > Here's a rough version of what that section needs to say: > > Trac is a community-tended garden of issues. Sometimes there are > weeds, sometimes there are flowers and vegetables that need picking. > We need your help to sort out one from the other. > > Like all gardens, we can aspire to perfection, but in reality, there's > no such thing. In the most pristine garden there will still be snails > and insects. In a community garden, there will also be helpful people > who, with the best of intentions, fertilize the dandelions and poison > the roses. The job of the community is to self-manage, and try and > keep these problems to a mimimum, and educate those coming into the > community so that they can become valuable contributing members of the > community. > > Similarly, while we aim for Trac to be a perfect representation of the > state of progress on Django bugs, we acknowledge that this simply wont > happen. By distributing the load of Trac maintenance to the community, > we accept that there will be inaccuracies and mistakes made. Trac is > "mostly accurate", and we give allowances for the fact that sometimes > it will be wrong. > > So how should you interact with Django's Trac install? > > Be bold, but err on the side of caution. If you're uncertain if a > ticket is RFC, don't mark is as such. Leave a comment instead, letting > others know your thoughts. If you're mostly certain, but not > completely certain, you might also try asking on IRC to see if someone > else can confirm your suspicions. > > Start small. It's easier to get feedback on a little issue than on a big one. > > Wait for feedback, and respond to feedback that you receive. Don't > just barge in and mark 50 tickets RFC in a sitting -- especially if > this is your first time. Mark one or two tickets, and wait to see if > the core committers agree. If they commit, then you know your analysis > was correct; if they bounce back to Accepted, they will provide > feedback letting you know what was missing. Address that feedback, and > try again. > > Be rigorous. When we say "PEP8, and must have docs and tests", we mean > it. If a patch doesn't have docs and tests, there had better be a good > reason. Arguments like "I couldn't find any existing tests of this > feature" don't carry much weight -- while it may be true, that's an > indication that you should be the person to write the very first tests > for that feature, not that you get a pass from writing tests > altogether. > > I hope that clarifies things; I'll try and update the contribution > docs to reflect this sort of sentiment. > > 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.
