The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Knowing the Greatest Bug Number

Looking at the idea of using years and months as part of numbering bugs for bug trackers.

Most open-source projects have a bug tracker, and bugs are numbered sequentially. Thus, knowing the highest existing bug number (GBN) is an important piece of information if you’re looking for what you believe is a new (globally, not just new to you) bug.

You do a search for bugs, and one of the things you see is their number. If you know roughly what the GBN is, you can tell at a glance whether the bugs in your search results are new or old. That will give you important information, as a bug from ten years ago, from a deprecated version that won’t even run with your current libraries, etc. is probably not your bug.

Of course, technically knowing the GBN isn’t sufficient. You must also have some vague idea of the reporting cadence. That is, if GNB is 600K, and you’re looking at bug 550K, the rough time to accumulate the intervening 50K bugs could be large or small. And the cadence changes, probably following an elliptical orbit (speeding up close to release, slowing down at the midpoint between releases).

The question is, would it make sense to change how bugs are numbered? Would it make more sense to have bugs numbered like: YYYYMM-NNN? Adding in DD would probably be too fine-grained, but months probably fit well for most projects.

Bug numbers do not have an inherent meaning. They are already security-compromised in terms of giving away the timeframe they were filed. (That can be avoided by squirreling away some numbers and filing them late, but it’s unlikely to be done in open source. Even if it were, you could still squirrel some date-stamped bug numbers.)

You would lose guess-the-date-for-bug-N contests, though you could technically still hold one, it would just be using bug numbers people don’t refer to as often.

You might also gain a benefit: developers would have the date-of-filing staring them in the face every time they referenced a bug. I don’t think that would really matter; software gets built as best it can. Most unfixed bugs aren’t from laziness, but from difficulty, lack of information, and lack of time.

The other side of that is the users who will say, “this bug is five years old.” They already exist, though, so it doesn’t seem like this adds to that problem.

But having a year-month-numbered bug can, in some cases, give an immediate idea of a project’s size. A bug like YYYYMM-1 won’t, but a bug like YYYYMM-2468 will. They’re getting at least thousands of bugs per month.

There might be some technical issues. Will a bug database handle a lookup as easily when fragmented into years and months? Should there be that dash or should it be YYYYMMNN? Will people think the Ns are days?

What other benefits would this scheme achieve? Could you type MMNNN for the current year in a search? Or NNN for the current month? Will people get frustrated when it’s the first day of the month and their bug now needs to be typed out? Could you use some shorthand for that case?

I think using partial dates rather than purely sequential bug numbers (at least as an alias; there’s probably value in keeping the regular, sequential numbers, too) may have some use, but what do you think?

Save Games in Gaming

An overview of save games and how they impact playing a game.

One of the features most story-based games have is the ability to save your progress. Although some game companies are more focused on multiplayer games, singleplayer isn’t going anywhere, and multiplayer may include some singleplayer components in the future.

But if you’ve played a handful of games with a save game feature, you probably noticed they all work a little bit differently. And those differences may actually impact your play style.

Up-to-you Save Games

The up-to-you style is where the game simply has a feature and you can save whenever. It doesn’t save for you, and often you can name the save games. This style seems adequate, but in my experience I would only use one or two out of dozens of available save slots.

Usually I would stick to one slot, and then if things got hairy or I thought I might want to keep the other as a known-good save, I would add another. After progressing far enough, I might repeat that process since the known-good slot had aged too much.

Up-to-us Save Games

This is the opposite extreme. The game saves when it wants, and you have no control over it. In this sort of game, I would tend to be increasingly cautious as I moved farther from the last save. I would know that if I failed a mission or died, I would have to go all the way back. That inhibits risk-taking, which is not what games are about.

Games can encourage risks and teach us about when risk is appropriate. But if the game administrivia function itself discourages risk, that limits the game experience.

Hybrids

A number of hybrids exist. You get automatic checkpoints, which protects you from having a lone save game in a situation where you can’t progress, but you can add your own on top of it, giving you some say, too. This model seems the best of those currently available.

The main pain point with hybrids is that you might tend to accumulate save games that aren’t useful in the future, but if the save data is small and disk space is abundant, it shouldn’t really matter.

The Sandbox Model

Some games aren’t normal story-driven games, but sandbox or open-world games. In these what’s generally saved is the state of your playthrough: your inventory and completed missions, plus some sort of general location. This seems to be a pretty strong model for this type of game, but it doesn’t necessarily translate to more linear games.


Early games didn’t have saving available, though some used elaborate codes, as consoles lacked storage. They also had limited lives, which meant you could have to start the whole game over if you died. We’ve come a long way since those days, but I’m hopeful that future games will have save options that are even more powerful and reduce the friction of playing the game.

The Evolution of Writing on the Web

Experimental post about how writing should evolve to fit the modern web surfer.

A non-functional wire sculpture of a toilet.
By CCRI Artdepartment

Why New Styles are Needed

  • Articles should be swifter for the web.
  • People want to read less as they have more to read.
  • Top ten lists and bullet-point articles make it easier to get through.
  • You can skip around between parts, pick up where you left off.

How Did We Write?

  • Old writing was based on a longer attention span.
  • It had deeper stylistic integrity that the form afforded.
  • Structures of sections of paragraphs of sentences of words.

The New Style, Evolved from the Old

  • Headings of bullets of sentences of words.
  • Pictures to anchor each part (not shown here).
  • Barer sentences, with less complexity.
  • Like a powerpoint put through a wringer.

The Old Style Lives On

  • Books and periodicals, along with some traditionalist sites.
  • Nice for articles you want to go deeper into.
  • Side-by-side old and new allows for reader choice.

Benefits of the New Style

  • Students learn outline forms more easily.
  • Reading comprehension goes up for the new form.
  • Discussion is simplified through easily-referenced sentences?
  • Improves collaborative editing and creation.

Downsides of the New Style

  • Students dislike the old style even more than they already did.
  • Comprehension of the old style diminishes further.
  • Discussions are based on less nuance (Fox Newsier discussions prevail).

I Dunno.

  • I’m curious whether this sort of writing style should become more dominant.
  • I think it has some benefits for the way people use the modern web.
    • Easier to read casually.
    • Possibly more accessible to AI.
    • Less opportunity for verbosity.
  • So I wrote this in a version of what the new style may be, to see what it’s like.
  • Oy vey. I’m hoping that there can be some balance. I do think language and writing styles need to evolve to fit the needs of readers, and long-winded writing can be a pain to read (especially as the number of things to read grows), but let’s hope it won’t be a bullet-point-riddled future.
  • One promising alternative is that AI will allow for real-time reorganization/editing of long texts to elicit the parts the reader is most interested in.