FIXIT

gistfile1.txt

From csilvers, the original master of FIXITS:


1) The goal of a fixit is to address niggling concerns that bother you
time and again, but never enough to actually fix them.

As an example, I just got reviewed a changeset that gets rid of the
"Mismatch between XSRF header (None) and cookie (None)" lines that I
see all over the appengine error logs, and which as far as I can tell
convey no useful information (note: only in the case both values are
'None').  Now the logs are prettier and easier to read, by a little
bit.  This is the sweet spot for a fixit activity.

2) You can work on fixits with others, for more aggressive fixits.

Another perfect fixit-kind of activity would be to rewrite the
codebase to remove circular imports.  That's a lot of work, but if we
all worked on it together, we could plausibly get it done in a day.

3) Fixits are a time to do the things you "should" have done but never did.

Perfect fixit-type activities I see when I'm wandering around the
code: a lot of classes and methods could use docstrings, and even more
could use tests.  Look at some code you've written, and document
and/or test it!

Chris has written a lot of utility functions to make testing our
appengine code easier, and I'm adding some more in the next few days.
So if you decided your code was too hard to test before, now is a
great time to think again.

4) Fixits are a time to clarify unknowns.

We have several cases where we see weird behavior and don't exactly
know why: error messages in our logs that shouldn't be happening, etc.
They're not dangerous, per se, but they are confusing (and a bit
annoying).  Fixits are a perfect time to do a deep dive into what's
actually going on there, so at least we can understand (and document)
it, and ideally fix it.

5) Fixits are a time for cleanup.

Is there some code that makes you a bit sad every time you read it,
because it should be refactored?  But it's not in your main area of
work, so you let it slide?  Fixit days are days to *not* let it slide.

6) Code reviews are key.

Fixit days tend to have tons of small fixes.  That can get
overwhelming if the code reviews are piling up.  Take time off between
each of *your* fixit tasks to see if any fixit-related code reviews
are pending, and if so do them quick (if they look to be not-simple,
or not so 'fixit-related,' feel free to push back to some other day).

Feel free to make a big list of things, and feel free to work on them
in groups.  Few things are as satisfying as a good fix it!

(This was written by Craig back when he first introduced us to FIXITs.)