Wandering Thoughts archives

The impact on you of making 'bad' bug reports

One of the reasons that making bug reports is stressful for people who can do them well is that we're aware of the quiet but very real social downside of submitting 'bad' bug reports in most contexts. One of the important practical benefits of making (good) bug reports is that it builds up your good karma with the people behind whatever you're reporting bugs on. This good karma makes it more likely that they will take you seriously in the future, interact nicely with you, and perhaps even fix your bugs or answer your questions. This is ultimately a matter of name recognition; the developers will see a report or a question from you and go 'oh yeah, I remember that name, that's going to be worth reading'.

Bad bug reports are the reverse. They flush good karma down the drain and build up bad associations in people's minds. If you submit bad bug reports, people are going to remember you but it won't be in a good way. You'll be remembered as someone who's not worth paying attention to, someone that they kind of wish wouldn't file bugs and argue with them about the bugs you've filed and so on, and all of this will make the developers less likely to do you any favours or work on your problems or whatever.

Unfortunately, people generally remember bad interactions much better than they do good ones. You can guess what the corollary here is, but I'll say it outright:

It's often better for you to not file a bug report at all than to file a bad bug report.

Unless you can make significant contributions (submitting good patches and so on), you accumulate good karma (aka 'name recognition') only slowly. One bad bug report can thus offset a whole lot of good ones.

These social consequences of 'bad' bug reports serve as an obvious disincentive to file bug reports at all. Unless you're very sure that you're filing a good report (but not too good), it's better to sit on your hands. You're probably not going to get a timely fix for your problem anyways and sitting on your hands definitely avoids the potential downsides.

(By the way, one of the signals that an abrasive bug reporting environment sends to outside people is that there are probably to be significant bad social consequences for making 'bad' bug reports. Unless you've found something that is 110% sure to be a real bug that the developers will care about and that you can report clearly and in an unarguable way, well, it's really better to stay silent.)

Now it's time to add more unhappy news. I put 'bad' in quotes deliberately, because in practice bad bug reports includes any bug report that the developers don't agree with. If you file bug reports that are closed as 'NOTABUG' or the equivalent, those build up bad karma; you're going to get remembered as someone who files bug reports for things that aren't actually bugs. This often extends to bug reports about things that the developers don't really care about, because the developers will remember you as someone who's pestering them about unimportant stuff. Of course all of this adds its own level of stress and tension to filing certain bug reports, especially if you're critiquing a design or API issue.

(I sort of wrote a version of this as a comment reply here a few years ago, but I've decided that it's important enough to be in an entry of its own.)

One of the problems with 'you should submit a patch'

Today I reported a relatively small issue in the development version of ZFS on Linux. In theory the way of open source development is that I should submit a patch with my problem report, since this is a small and easily fixed issue, and I suspect that a certain number of the usual suspects would say that I'm letting down up my end of the open source social compact by not doing this (even though the ZoL developers did not ask me for this). Well, there's a problem with this cheerful view of how easy it is to make patches:

It's only easy to make half-assed partially tested patches. Making well-tested good ones is generally hard.

In theory this issue and the fix is really simple. In practice there are a bunch of things that I don't know for sure and that I should test. Here's two examples that I should do in a 'good' patch submission:

• I should build the package from scratch and verify that it installs and works on a clean system. My own ZFS on Linux machine is not such a clean system so I'd need to spin up a test virtual machine.

• I should test that my understanding of what happens when an systemd.service ExecStartPre command fails is correct. I think I've correctly understood the documentation, but 'I think' is not 'I know'; instead it's superstition.

Making a patch that should work and looks good and maybe boots on my machine is about ten minutes work (ignoring the need to reboot my machine). Making a good patch, one that is not potentially part of a lurching drunkard's walk in the vague direction of a solution, is a lot more work.

(This is not particularly surprising, because it's the same general kind of thing that it takes to go from a personal program to something that can pass for a product (in the Fred Brooks sense). The distance from 'works for me' to 'it should work for everyone and it's probably the right way to do it' is not insubstantial.)

Almost all of the time that people say 'you should submit a patch' they don't actually mean 'you should submit a starting point'. What they really want is 'you should submit a finished, good to go patch that we can confidently apply and then ship'. At one level this is perfectly natural; someone has to do this work and they'd rather you be that person than them (and some of the time you're in a theoretically better position to test the patch). At another level, well, it's not really welcoming to put it one way.

(It also risks misunderstandings, along the same lines as too detailed bug reports but less obviously. If I give you a 'works for me' patch but you think that it's a 'good to go' patch, ship it, and later discover that there are problems, well, I've just burned a bunch of goodwill with the project. It doesn't help that patch quality expectations are often not spelled out.)

There are open source projects that are genuinely not like this, where the call for patches really includes these 'works for me' starting points (often because the project leadership understands that every new contributor starts small and incomplete). But these projects are relatively rare and unfortunately the well is kind of poisoned here, so if your project is one of these you're going to have to work quite hard to persuade skittish people that you really mean 'we love even starting point patches'.

(Note that this is different from saying basically 'bug reports are only accepted when accompanied by patches'. Here I'm talking about a situation where it seems easy enough to make a patch as well as a bug report, but the devil is in the details.)

The problem with proportional fonts for editing code and related things

One of the eternal attractive ideas for programmers, sysadmins, and other people who normally spend a lot of time working with monospaced fonts in editors, terminal emulators, and so on is the idea of switching to proportional fonts. I've certainly considered it myself (there are various editors and so on that will do this) but I've consistently rejected trying to make the switch.

The big problem is text alignment, specifically what I'll call 'interior' text alignment. Having things line up vertically is quite important for readability and I'm not willing to do without it. At one level there's no problem; automatically lining up leading whitespace is a solved issue, and other things you can align by hand. At another level there's a big problem, because I need to interact with an outside world that uses monospace fonts; the stuff I carefully line up in my proportional fonts editor needs to look okay for them and the stuff that they carefully line up in monospace fonts needs to look okay for me. And automatically detecting and aligning things based on implied columns is a hard problem.

(I used to use a manual page reader that used proportional fonts by default. It made some effort to align things but not enough, and on some manual pages the results came out really terrible. This experience has convinced me that proportional fonts with bad alignment are significantly worse than monospaced fonts.)

This is probably not an insoluble problem. But it means that simply writing an editor that uses proportional fonts is the easy part; even properly indenting leading whitespace is the easy part. In turn this means that you need a very smart editor to make using proportional fonts really a nice experience, especially if you routinely interact with code from outside your own sphere. Really smart editors are rare and relatively prickly and opinionated; if you don't like their interface and behavior, well, you're stuck. You're also stuck if you're strongly attached to editors that don't have this kind of smarts.

(The same logic holds for things like terminal programs but even more so. A really smart terminal program that used proportional fonts would have to detect column alignment in output basically on the fly and adjust things.)

So I like the idea of using proportional fonts for this sort of stuff in theory, but I'm pretty sure that in practice I'm never going to find an environment that fully supports it that works for me.

(For those people who wonder why you'd want to consider this idea at all: proportional fonts are usually more readable and nicer than monospaced fonts. This entry is basically all plain text, so you can actually look at the DWikiText monospaced source for it against the web browser version. At least for me, the web browser's proportional font version looks much better.)

Why keeping output to 80 columns (or less) is still sensible

When I talked about how monitoring tools should report timestamps and other identifying information, I mentioned that I felt that keeping output to 80 columns or less was still a good idea even if meant sometimes optionally omitting timestamps. So let's talk about that, since it's basically received wisdom these days that the 80 column limit is old fashioned, outdated, and unnecessary.

I think that there are still several reasons that short output is sensible, especially at 80 columns or less. First, 80 columns is still the default terminal window size in many environments; if you make a new one and do nothing special, 80 columns is what you get by default (often 80 by 24). This isn't just on Unix systems; I believe that eg Windows often defaults to this size for both SSH client windows and its own command line windows. This means that if your line spills over 80 columns, many people have to take an extra step to get readable results (by widening their default sized window) and they may mangle some existing output for the purposes of eg cut and paste (since many terminal windows still don't re-flow lines when the window widens or narrow).

Next, there's an increasingly popular class (or classes) of device with relatively constrained screen size, namely smartphones and small tablets. Even a large tablet might only be 80 columns wide in vertical orientation. Screen space is precious on those devices and there's often nothing the person using the device can really do to get any more of it. And yes, people are doing an increasing amount of work from such devices, especially in surprise situations where a tablet might be the best (or only) thing you have with you. Making command output useful in such situations is an increasingly good idea.

Finally, overall screen real estate can be a precious resource even on large-screen devices because you can have a lot of things competing for space. And there are still lots of situations where you don't necessarily need timestamps and they'll just add clutter to output that you're actively scanning. I won't pretend that my situation is an ordinary one; there are plenty of times where you're basically just glancing at the instantaneous figures every so often or looking at recent past or the like.

(As far as screen space goes, often my screen winds up completely covered in status monitoring windows when I'm troubleshooting something complicated. Partly this is because it's often not clear what statistic will be interesting so I want to watch them all. Of course what this really means is that we should finally build that OS level stats gathering system I keep writing about. Then we'd always be collecting everything and I wouldn't have to worry about maybe missing something interesting.)