Users Don't Care About Bug Fixes

We were trained to always write a "what's new" list when we ship a new version of our product. User have come to expect these lists, as you see them even in app stores. Each app update comes with a "release history" that's supposed to tell you why you should bother updating.

This, in itself, is a good thing. Problem is, people who write these lists often confuse "what's new" with "what we've been working on since the last version". Users (and this is a gross generalization, but still) do not care how your team has been spending its time between versions. They care about what's new. Shiny new things.

The worst offense in this respect is including bug fixes as part of the release history. Sure, you've spent 80% of your time fixing bugs and 20% actually adding new functionality - but users don't care. Yes, yes, of course some do, like the ones that reported some of the bugs, but they're really the exception. Your release history is a marketing document aimed at getting more people to upgrade to the latest version and convert inactive users to active ones. Most users could care less about how many bugs you've fixed along the way. In fact, nice going, advertising the fact that you have shipped so many bugs to begin with... Sure, it's reality, but reality isn't the point. You're not logging, you're advertising.

So don't include a list of every single bug you've fixed. For God's sake don't include bug IDs! But most pointless of all is to just write "various bug fixes". O... k... what's the value in that? Why are you sharing this with users? It's not their fault that you only managed to squeeze one new feature into this release. Adding this "but we really worked hard to fix a lot of problems you may not even have noticed" excuse is just silly.

We've done this in the past, I'll admit. No more. If you can spin a bug fix as a positive improvement to functionality (e.g. things run faster), then go ahead - but don't force it.

One exception to this rule is for mega-bugs. Bugs that were so horrible, they caused half your users to flee your product. It makes sense to mention those, but really only those. 

Think of every addition to the release history as adding another line to your product's CV. 
What goes into a CV? 
Good idea: mention the ways you've grown during your last job.
Bad idea: mention that anger management course they forced you to take. That's the sort of "bug fix" you can keep to yourself.

New Feature: Export Your Projects

Sadly, not every single person in the world uses Gigantt. Not yet. 
It's a travesty.
But don't despair, early adopter! You can now export your plans from Gigantt to a variety of popular file formats, which you can then share with your clients or co-workers who haven't yet jumped on board the Gigantt train.

Here are the export formats we currently support:

Microsoft Project (XML) - The ubiquitous project-management tool we all love to hate.

Excel (CSV) - Comma Separated Values. A simple textual format that can be opened by Excel or any text editor.

Image (PNG) - This is like printing your screen into an image that you can then attach to emails/PowerPoint/etc. You even get a chance to preview your plan and tweak it before saving it as an image file.

image preview

HTML - Gigantt will export your plan into a single, interactive HTML file in the shape of a task-tree. You can then view it in any browser.

JSON - The "source" format Gigantt uses internally to save your projects. It's a very programmer-friendly text format. Software developers should find it easy to use for developing their own export formats.

DOT - This one is just for fun. It exports the "shape" of your plan so that it can be rendered as a DAG in GraphViz. This is a very technical format that only software developers find relevant.

These are the formats we're starting with. We plan to add more. Go ahead and try it out. If you'd like us to add support for any specific format please let us know.

It's Tasks All The Way Down...

Gigantt is a project management tool that does not know what a project is. It's all just tasks. Tasks that can contain other tasks.

"Turtles Tasks all the way down"

It makes everything much simpler, really. You don't need to define projects, milestones or versions. It's up to you to build your task hierarchy in any way that makes sense to you.

Consequently, plans in Gigantt don't really have names. Or, more accurately, the name of the plan is just the name of its top task. 

Renaming a plan

Rename it and you've renamed your plan.

Normally, when you create a new plan, the top task is assigned to you, and so is any additional sub-task you create. You're the default owner, in other words, of any top level sub-task. We've recently added a way to change this. So if you want to assign the top task of the plan to somebody else you can do it by visiting the This Plan dialog inside the menu.

Changing the default owner of top-level tasks

This comes in handy, for example, when the person who created the plan is no longer part of the project.

Our fractal approach to projects, where it's all just tasks containing other tasks, makes Gigantt simpler to learn and more flexible.