Who? When? Why? What? Where? How? If you don't answer those questions, why bother blogging at all?
The "Five W's" as they're often called (and one H) are drilled into every journalism student as crucial for news-writing. Who is involved? When did it happen? Where did it happen? How and why did it happen? And, for all that's holy, what happened.
Every news story should answer these questions. So should every post on your blog. This doesn't mean that posts need to be boring, inverted-pyramid style jobs with just the facts. Use your own voice. Ramble if you like. Show us a few cat pictures with funny text. Bury the lede if you need, and write about whatever strikes your fancy. But for the love of $DEITY, tell us what happened, to who, why, when, how, and where.
I skim a lot of "Planet" Web sites for FLOSS projects from Debian to openSUSE looking for things to write about. Presumably, each blogger wants to convey some information to the rest of the world. Yet so many leave so much out.
A common sin is writing about a project update without bothering to give even a one-liner explaining what the hell the project is or does. Yes, I've even been guilty of this myself. Just today, I've run across at least three posts that discuss updates to this or that package, but utterly fail to say what the package is or does excepting the name. Now, if the assumption is that I follow that developer's blog religiously, then I would obviously know what that package is and the information would be unnecessary.
Don't assume that people will be reading your blog in the context of the project or be even slightly familiar with you or the project you're writing about. Like me, they may have come in via the planet feed for the first time and this is your first (and perhaps only) chance to catch that user's attention. Maybe they've come into your blog via a Google search result, or a link off of Twitter. They could come from anywhere, and you have this one chance to connect with the reader. Don't blow it by failing to explain what you're talking about. Every reader that says "oh, that's lovely, foo was updated. Wish I knew WTF foo did in the first place, but I'm a busy person and don't have time to dig into this. The developer obviously didn't care enough to explain, so it can't be all that inclusive a project" is a lost user.
For open source developers that write about something frequently, consider writing up some boilerplate text to stick in each entry about an update or new feature. Again, it doesn't have to be pretty. You don't need to be a fancy wordsmith to do the job: Just make sure that the reader knows who, what, where, when, why, and how. Consider just tacking something like this onto posts:
Project Foo is a widget that provides X, Y, and Z features for users of Bar. It's open source, and source is available over here, packages are there. The home site contains (link) documentation (link).
It would take less than five minutes to write up something like that, but it might just make the difference between losing or gaining a user -- and ultimately, a contributor.
Blogging 101: Take a Tip from Newswriting with the Five W's
Who? When? Why? What? Where? How? If you don't answer those questions, why bother blogging at all?
The "Five W's" as they're often called (and one H) are drilled into every journalism student as crucial for news-writing. Who is involved? When did it happen? Where did it happen? How and why did it happen? And, for all that's holy, what happened.
Every news story should answer these questions. So should every post on your blog. This doesn't mean that posts need to be boring, inverted-pyramid style jobs with just the facts. Use your own voice. Ramble if you like. Show us a few cat pictures with funny text. Bury the lede if you need, and write about whatever strikes your fancy. But for the love of $DEITY, tell us what happened, to who, why, when, how, and where.
I skim a lot of "Planet" Web sites for FLOSS projects from Debian to openSUSE looking for things to write about. Presumably, each blogger wants to convey some information to the rest of the world. Yet so many leave so much out.
A common sin is writing about a project update without bothering to give even a one-liner explaining what the hell the project is or does. Yes, I've even been guilty of this myself. Just today, I've run across at least three posts that discuss updates to this or that package, but utterly fail to say what the package is or does excepting the name. Now, if the assumption is that I follow that developer's blog religiously, then I would obviously know what that package is and the information would be unnecessary.
Don't assume that people will be reading your blog in the context of the project or be even slightly familiar with you or the project you're writing about. Like me, they may have come in via the planet feed for the first time and this is your first (and perhaps only) chance to catch that user's attention. Maybe they've come into your blog via a Google search result, or a link off of Twitter. They could come from anywhere, and you have this one chance to connect with the reader. Don't blow it by failing to explain what you're talking about. Every reader that says "oh, that's lovely, foo was updated. Wish I knew WTF foo did in the first place, but I'm a busy person and don't have time to dig into this. The developer obviously didn't care enough to explain, so it can't be all that inclusive a project" is a lost user.
For open source developers that write about something frequently, consider writing up some boilerplate text to stick in each entry about an update or new feature. Again, it doesn't have to be pretty. You don't need to be a fancy wordsmith to do the job: Just make sure that the reader knows who, what, where, when, why, and how. Consider just tacking something like this onto posts:
Project Foo is a widget that provides X, Y, and Z features for users of Bar. It's open source, and source is available over here, packages are there. The home site contains (link) documentation (link).
It would take less than five minutes to write up something like that, but it might just make the difference between losing or gaining a user -- and ultimately, a contributor.