Help the Help

Today was the GNOME Docs meeting day, a planning session for things to come in the doc world of GNOME.

We needed to plan a little bit of work for the coming months (one or two months, not much more), and we decided to focus ourselves on small applications help, something in the order of small games, the calculator, and so on. This will be a good exercise for writing help for an application, and a good learning moment to learn Mallard and topic based writing.

Speaking of games help, since Mario Blättermann ported the Tetravex documentation from Docbook to Mallard, we said: “Why don’t we start from that, and see how we can expand it and work on it?”. Tetravex is not that complex game, and should be pretty easy (and fun) to work on what Mario created.

We wrote down a basic structure for how a game help should (probably) be structured, and it goes in the form of:

• Gameplay (Introduction)
  • Basic Gameplay and winning scenario
• Strategy
  • Multiple pages if necessary
• Multiplayer
• Tips and Trick

It’s a really basic structure, probably it’s not complete and it will need to expand as we move forward and we reach new kind of games, but for a starter, we think that should work. I’m not going to explain each of them, I think they are pretty straightforward and self-explaining.

So, if you out there would like to start a new experience in the wonderful world of GNOME Doc writing with a light task, we might need your help in writing games help.

Get in touch with the GNOME Doc team at: http://live.gnome.org/DocumentationProject.

Of the Importance of Documenting

It’s not secret that I started a new job and that I’m now working for a closed-source company (even if sometimes I have to work with my beloved Linux, but unfortunately that’s rare).

Before starting, I thought I would have found some great docs, describing the works of others, API documentation, internal guidelines, flow-charts, diagrams, whatever; I thought I would have found the basic “infrastructure” that makes a developer work.

I was wrong.

Actually there is documentation, but it’s only the end-user documentation, no real internal documentation. No documentation to help you speeding up with your work, to understand how things work. No (useful) comments in the code.

What would have taken you 5 days of work to accomplish, (exaggerating) will take you two weeks: you have to ask someone else in the company, but maybe they don’t remember or didn’t write that particular piece of code, or didn’t work on that implementation.

Documentation is important, from the end users to the developers, if you want your project to self sustain, if you want to ease the life of other people, and if you want your project to live a long and prosperous life. People were not in your head (and are not in your head) when you wrote that strange thing. 1-2 years from now you could be working for another company, what would be of other people who are trying to understand what you wrote? How would people easily understand how things work in a complex environment?

But luckily, things they are a-changin’. They are now realizing that they need documentation, that they need documentation in the code, and that they need to document things. A small victory.

Lesson learned: next time you do a job interview, if you don’t know the company, ask what are their internal standards, guidelines, and if there is documentation. You can understand a little bit of the level of professionalism of it.