I'm pleased to have teamed up with AT&T to bring you this illustrated guide to effective bug tracking.

The original issue description was "noise / static on line", and as we can see, AT&T have very effectively closed the ticket: There is no longer any noise, of any kind, on the phone line.

No electrons == no noise, so this is the absolute simplest and most effective fix possible. Always start with the simplest such fix, and be sure to close the problem ticket immediately on fixing. Do not followup with the issue reporter, or contact them in any way to explain how the issue was resolved.

While in the guts of the system fixing such a bug report, you'll probably see something that could be improved by some light refactoring. It's always a good idea to do that right away, because refactoring can often just solves an issue on its own somehow. (Never use your own issue tracking system to report issues to yourself to deal with later, because that would just be bonkers.)

But don't go overboard with refactoring. As we see here, when AT&T decided to run a new line between two poles involved in my bug report, they simply ran it along the ground next to my neighbor's barn. A few festive loops and bows prevent any possible damage by tractor. Can always refactor more later.

The only other information included in my bug report was "house at end of loong driveway". AT&T helpfully limited the size of the field to something smaller than 1 (old-style) tweet, to prevent some long brain dump being put in there.

You don't want to hear that I've lived here for 7 years and the buried line has never been clean but's been getting a bit more noisy lately, or that I noticed signs of water ingress at two of the junction boxes, or that it got much much worse after a recent snow storm, to the point that I was answering the phone by yelling "my phone line is broken" down the line consumed with static.

Design your bug tracking system to not let the user really communicate with you. You know what's wrong better than them.

And certianly don't try to reproduce the circumstances of the bug report. No need to visit my house and check the outside line when you've already identified and clearly fixed the problem at the pole.

My second bug report is "no dial tone" with access information "on porch end of long driveway". With that, I seem to be trying to solicit some kind of contact outside the bug tracking system. That is never a good idea though, and AT&T should instruct their linemen to avoid any possible contact with the user, or any attempts to convey information outside the issue tracking system.

AT&T's issue tracking system reports "Service Restore Date: 12/25/2018 at 12:00 AM" but perhaps they'll provide more effective issue tracking tips for me to share with you. Watch this space.

My offgrid, solar powered, zero-battery-use fridge has sucessfully made it through spring, summer, fall, and more than enough winter.

I've proven that it works. I've not gotten food poisoning, though I did lose half a gallon of milk on one super rainy week. I have piles of data, and a whole wiki documenting how I built it. I've developed 3 thousand lines of control software. It purrs along without any assistance.

Fridge0 consists of a standard chest freezer, an added thermal mass, an inverter, and computer control. It ties into the typical offfgrid system of a solar charge controller, battery bank, and photovoltaic panels.

This isn't going to solve global warming or anything, but it does seem much less expensive than traditional offgrid fridge systems, and it ties in with thinking on renewable power such as Low Tech magazine's Redefining Energy Security "To improve energy security, we need to make infrastructures less reliable."

I mostly wanted to share the wiki, in case someone wants to build something like this. And to post some data. Here's the summer and fall temperature data.

(More on temperature ranges here.)

I want to be upfront that this is not guaranteed to work in every situation. Here's that time that the milk spoiled. A tropical storm was involved. Most of the time milk stays good 2 to 3 weeks in my fridge.

Some things I might get around to doing eventually:

• Using a supercapacitor to provide power while shutting down on loss of solar power, instead of the current few minutes of use of batteries.
• Also running a freezer, dividing up solar power between them.
• A self-contained build with its own solar panels and electronics, instead of the current build that uses my house's server and solar panels.
• A full BOM or kit, just add solar panels and chest freezer to quickly build your own.

I probably won't be devoting much time to this in the upcoming year, but if anyone wants to build one I'm happy to help you.

git-annex v7 was released this fall, the culmination of a long effort to add some important new features to git-annex. Rather than go into details about it here, see this LWN article comparing and contrasting git-annex with git lfs.

For three years my work on git-annex had major support from Dartmouth's DataLad project, pushing it into use in the sciences, and driving large improvements in git-annex's API, concurrency support, etc. But that relied on government funding which has been drying up. Increasingly I have been relying on croudfunding from git-annex's users.

Now I'm entering a new phase, where DataLad users may also want to support git-annex. So far, McGill's NeuroHub project has committed to supporting its development (funded by the Canada First Research Excellence Fund, for the Healthy Brains for Healthy Lives initiative), but I hope others will too. A diversity of funding sources is best.

A survey of git-annex users is now underway, the first in three years. If you've not already, please participate in it to help direct my newly funded work.