Help review tickets, get a prize!
Jacob Kaplan-Moss
We have a chronic problem: our new ticket review queue. We get roughly
50 new tickets each week, and we typically don't keep up with this
flow very well. Eventually, someone (Hi, Russ!) takes it on himself to
review the massive backlog, but that's damned painful.
Right now we only have 60 unreviewed tickets in the queue, so now's a
great time to get on top of this problem for once and for all.
Everyone on this list is qualified to help. Please read on to see how,
and the "prize" bit is at the bottom.
For the most part, reviewing these types tickets is an easy process.
Reviewers need to do the following:
* Verify that the reported problem is actually a bug or feature
request. Sometimes people end up at the ticket system when they should
be asking for help on django-users, so they need to be pointed in that
direction. Other times there's not enough information on the ticket to
reproduce it. But most of the time, it's really a bug or feature
request, and a quick comment saying "I can confirm this is a bug"
*really* helps when it comes time to try to fix the problem.
* Make sure the ticket's not a duplicate by searching the tracker for
existing tickets of the same nature.
* Make sure the metadata (ticket type, component, etc.) is correct.
* Move the ticket along the process (probably into into the "accepted"
or "design decision" stages).
It takes me about 5 minutes to review most unreviewed tickets. A few
take longer, but most are pretty quick. Again, this is totally
something anyone here can do. Yeah, you might run into a ticket you
just don't get, and it's fine to skip in and move along. Remember that
there's help in IRC (#django-dev) nearly all the time, though.
Of course, I'd be lying if I said that this was a whole lot of fun, so
here's where the prize bit comes in:
Starting right now, I'm offering a 5-for-1 deal on reviews. If you
have a ticket, patch, or feature request that you'd like *me* to
review, simply review 5 unreviewed tickets then post your review
request on this list with "[5-for-1]" in the subject. I'll prioritize
*your* request the next time I work on Django.
Of course, I encourage other core developers, and anyone else who's
capable, to join me in prioritizing these "5-for-1" requests, but this
isn't a BDFL action or anything -- just my way of trying to keep the
unreviewed queue as low as possible.
Jacob
Alex Gaynor
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Consider me in on the 5-1 offer.
Alex
--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
Jacob Kaplan-Moss
You can find a link to unreviewed tickets at
http://code.djangoproject.com/wiki/Reports (along with a bunch of
other cool canned queries).
Jacob
Carl Meyer
On 04/20/2011 04:27 PM, Alex Gaynor wrote:
> Consider me in on the 5-1 offer.
Same here.
Carl
TiNo
It takes me about 5 minutes to review most unreviewed tickets
Jeremy Dunck
For what it's worth, "Unreviewed" tickets generally is just making the
decision whether a design decision is needed, or whether the ticket
can be directly accepted as legitimate:
http://docs.djangoproject.com/en/1.3/internals/contributing/#ticket-triage
Many of these tickets will not yet have a patch, and in any case,
someone can validate tickets once they have entered the Accepted
stage; that decision is when the ticket moves to Ready For Checkin.
Jacob Kaplan-Moss
> Would you (or any other core dev / speed reviewer) mind sharing your
> workflow? Any scripts to create environments at certain revisions or
> something alike? Or to quickly run the relevant tests?
So first, I mostly review tickets against trunk. If someone's
reporting a bug against 1.2, and I can't reproduce it against trunk,
I'll mark "worksforme" and ask the reporter to reopen if the problem's
against trunk. I'd suggest you start there rather than worry about
multiple versions for now. (When I absolutely have to, I have a bunch
of virtualenvs for different versions, but most of the time reviewing
against trunk is fine).
Also remember that most of the time you just need to make sure the
thing's actually a bug and set the metadata correctly. Most of the
time:
* It's either clearly *not* a bug, in which case I mark it invalid and
politely tell the user to take it to django-users.
* It clearly *is* a bug, and there seems to be a fair bit of
information (steps to reproduce, the traceback, etc.); these I quickly
mark "accepted", fix the metadata, and move on.
* It's a feature request, which means it can be marked "design
decision needed" (and the metadata gets updated).
If you only want to handle tickets that fall into the above that's
*fine* and would already be a huge help.
If you *do* want to try to reproduce the bug, or if there's a patch
you want to try out, here's a few things I do that might help:
* I have a Django project called "scratch" that I've set up to easily
let me test new apps. Basically I just do the following in my settings
file::
from unipath import FSPath as Path
BASE = Path(__file__).parent.absolute()
...
INSTALLED_APPS = [
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
'django.contrib.admin',
]
INSTALLED_APPS += [p.name for p in BASE.listdir(filter=Path.isdir)]
This just automatically adds any apps in the current dir to
INSTALLED_APPS, so I can just `./manage.py startapp ticket1234`, write
some code in the app, and then run the server, tests, etc without
messing with the settings file.
(This uses Unipath (`pip install Unipath`) but you could do the same
thing with `os`.)
I use this every time I need to try to reproduce a bug.
* I have a package of test settings on PYTHONPATH. It's just a
directory with different settings files so I can do `runtests.py
--settings=testsettings.sqlite`, `--settings=testsettings.postgres`,
etc.
* I have a little script (https://gist.github.com/933233) called
`runtests` that'll quickly run tests using the above. For example, I
can do `runtests --db=postgres admin_views` to quickly run the admin
view tests.
* I have another little script I use to apply patches
(https://gist.github.com/933116) if I need to test them. It might not
work for anyone else -- I use git-svn, not svn directly -- but take a
look if you like.
Bit of a brain dump, I know, but at least this stuff is out there for
others to use if they like.
Jacob
Carl Meyer
On 04/20/2011 05:14 PM, TiNo wrote:
> It takes me, being a newbie at reviewing tickets, quite some more time.
> Would you (or any other core dev / speed reviewer) mind sharing your
> workflow? Any scripts to create environments at certain revisions or
> something alike? Or to quickly run the relevant tests?
It takes me longer than 5 mins per ticket, too. I tend to dive in pretty
deep to make sure I'm understanding the full context for a ticket before
accepting it. That said, here are some things I do for convenience; some
of them may be obvious:
- I have virtualenvs for all supported Python versions (2.4-2.7; trunk
has dropped 2.4 support, but I still may need it for backports), and
each one has my development copy of Django already installed in it (with
"pip install -e ." so it's actually using the working tree code and will
see my changes). Combined with "git checkout" this covers "creating
environments at certain revisions".
- I have stock settings modules for running the tests with each database
I have available (MySQL, SQLite3, Postgres), and I actually have these
packaged up with a setup.py and also installed in each Django-dev
virtualenv (with "pip install -e") so they're always on sys.path and
accessible as "testconf.sqlite" etc.
- I have a bare-bones "test project" with a settings module that has the
admin in INSTALLED_APPS and set up in urls.py, and an installed
"testapp" that already has __init__.py, models.py, and admin.py. So for
those cases where I need to try out something manually (often in the
admin), it's just a matter of copy-pasting some things into the
models.py and admin.py, syncing the db, and firing up runserver. And I
actually have this version-controlled so I can commit the "manual test"
setup for a given bug (in a branch named with the ticket number) in case
I need it later for working on the bug.
HTH,
Carl
Carl Meyer
On 04/20/2011 05:38 PM, Jacob Kaplan-Moss wrote:
> * It clearly *is* a bug, and there seems to be a fair bit of
> information (steps to reproduce, the traceback, etc.); these I quickly
> mark "accepted", fix the metadata, and move on.
So you don't necessarily reproduce it yourself before marking Accepted?
Carl
Jacob Kaplan-Moss
> So you don't necessarily reproduce it yourself before marking Accepted?
Mm, it depends. Sometimes I don't need to -- it's clearly a bug, and I
see everything I need to track it down. I generally trust that if the
user could be bothered to write a good, clear bug report that it's
really a bug and I don't need to reproduce it. It's not like moving it
to accepted and *then* finding that it's not really a bug is a
problem. Perfect is the enemy of the good, and all that.
All in all, I'd guess that of the "bug" category tickets I see I need
to take the time to reproduce about half of them. Maybe 2/3rds.
Jacob
TiNo
Aymeric Augustin
The offer described below hasn't been used for some time, but it still stands!
The unreviewed queue is quite high at the moment, so it's a good time
to get your feet wet :)
**tl;dr**
Tickets: https://code.djangoproject.com/query?status=!closed&stage=Unreviewed
How to: https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/
Stats: https://dashboard.djangoproject.com/metric/unreviewed/
Triage five unreviewed tickets and a core dev will look at a ticket or
patch of your choice.
--
Aymeric.
2011/4/20 Jacob Kaplan-Moss <ja...@jacobian.org>:
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
Aymeric.
charettes
Should I open a ticket?
Russell Keith-Magee
the resources to do this all the time. Rather than set the formal
expectation that the 5-for-1 deal will always be available, I'd rather
keep it as a "Sale now on!" feature that a core developer can announce
when they find themselves with some spare time.
Yours,
Russ Magee %-)
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> https://groups.google.com/d/msg/django-developers/-/tBPUKD3Q0msJ.