Hi Jacob,

Thanks for your feedback.

> For (1) check out http://code.djangoproject.com/wiki/Reports(it's
> linked in the nav). If there's anything missing there, please feel
> free to add it -- it's a wiki page. Let me know if you need help
> figuring out the linked query syntax.

I wasn't able to edit this page. Other wiki pages have an "Edit this
page" and "Attach file" buttons at the bottom, but not the Reports
page.

I was just going to add a link to tickets that are Accepted with a
patch that doesn't need docs, tests or improvement as tickets that
just need a fresh pair of eyes to review and either bump up to Ready
for checkin or back down to Patch needs improvement (with feedback).

I also noticed that 3 of the 4 existing links under "Tickets needing
some work" are incorrect. They indicate that they are accepted
tickets, but only one of these links is filtering by triage stage.

> Work on (2) began at some point over 
> athttp://code.djangoproject.com/wiki/TicketChangeHelp. It's pretty rough
> still, but once it gets better I'd love to link sections from the
> ticket page and/or move it into the docs directly.

This is good, but it looks like mostly copy and paste from the
"Contributing to Django" docs (duplication of data, also the Wiki is
not authoritative, especially when not authored by a core committer)
for the descriptions of each triage stage and patch flag, with the
addition of next steps. I'm also not sure if this Wiki page is linked
to from anywhere (e.g. actual ticket pages)?

Perhaps we'd be better off simply adding the next steps information to
the "Contributing to Django" docs directly, and to also update the
diagram there to include the various patch flags (has patch, needs
docs, needs tests, patch needs improvement) between the Accepted and
Ready for checkin triage stages?

At the moment all the docs / diagram say is that tickets which have a
patch with docs and tests are moved to ready for checkin, but a quick
search on trac revealed 358 tickets with this combination of triage
stage and patch flags. These tickets should all be either "patch needs
improvement" with feedback, or ready for checkin, right?

Perhaps we need another triage stage for these tickets, "Needs final
review" or something?

This is where I personally feel one of the big problems is with
perceived responsiveness of the core committers. These tickets are
sitting there as Accepted, and don't appear to require any further
action from the community or patch author (don't need a patch, docs,
tests or improved patch), and they are ignored by people wanting to
contribute and core committers alike.

> Ideally, I'd like each ticket page to have a "what's next?" box on it
> indicating where the ticket is and how to move it along. Technically
> this isn't hard -- we've got plenty of folks in our community who
> could write a Trac plugin -- but getting the language right is
> important. If we get that worked out to some extent I'll figure out
> what the next steps are technically.

Perhaps another boolean flag that simply says if the next step lies
with the patch author / community, or with the core committers?
Similar to regular support tickets which might say "waiting on
customer" or "waiting on support staff". This could help avoid
situations where the patch author thinks they've done everything they
need to do, satisfied all the requirements (docs, tests, code style),
and yet their ticket is never pushed up to Ready for checkin, which
only makes them less likely to contribute again in future and more
likely to simply fix or work around their problem locally instead and
save writing docs and tests for Django that go unused.

> For (3), well, feel free to bring things up here or on IRC, I s'pose.
> I'd really appreciate it if we didn't get 'em all brought up at once,
> of course. But yes, if there are tickets marked DDN that you feel are
> critical, please feel free to ask for a yay/nay.

Are only critical tickets eligible for a vote? I think there are a lot
of non-critical (even trivial) tickets that are stuck in DDN hell :)
Maybe we could organise regular DDN and Ready for checkin triage
sprints?

Also as DDN tickets must be decided by core committers, the community
and patch authors can't really do anything with these tickets and they
are stick in limbo. Perhaps there needs to be another flag to indicate
whether the core committers need more information or a proposal for
why a ticket should be included before they can make their decision,
or if it has been added to the queue of tickets to be decided on
(maybe with a position in the queue), and make sure that the queue is
worked through in order, and either sent back to the patch author for
more information or put to a vote if a decision can't be made?

-- 
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.

Reply via email to