Subject | Make a wiki and centralize all info about firebird there |
---|---|
Author | woodsmailbox |
Post date | 2008-12-18T20:10:11Z |
Hi,
I've been using fb for a few years now and it always strikes me how
inconsistent its web presence is. Many sites, document formats,
mailing lists hosted by different engines with different capabilities,
you all know the picture.
Ironically, the info _is_ there and up-to-date, and you can usually
solve your problems if you are willing to search deep enough. So is
not the info that's missing but its accessibility. So many get the
perception of an obscure product just because there's no feeling of a
central, authoritative information repository. Those who do make it,
are bound to hit a second wall later on: the tons of info trapped in
huge mailing lists of extremely limited browsing and searching
capabilities.
For those of you who use php, postgresql, freebsd to name just a few,
you know that a good part their conversion rate goes to the way they
handle the issue on their websites.
The idea is simple but effective: instead of breaking and separating
the different **aspects** of the whole project (bug tracker, support
ml, manual, changelog, architect ml, etc.), make a single big online
documentation project, break that into **topical sections**, and put
all other aspects into each topic's page.
So for example, when I want to know about "global temporary tables", I
go to the section with the same name and I get: documentation,
supported versions, changelog, implementation notes, user comments,
examples, support questions and answers, related bugs, architectural
debate, cross-links to "related" sections etc. In the current state of
affairs, I'd call that "research".
Just a few more points:
Few users are interested in a long changelog of unrelated features
which they have to use as documentation.
All this is very achievable with a good wiki engine.
That's not marketing, merely accessibility.
As I said before, the info is there, so this is not about a
documentation effort either, but a redesign.
I've been using fb for a few years now and it always strikes me how
inconsistent its web presence is. Many sites, document formats,
mailing lists hosted by different engines with different capabilities,
you all know the picture.
Ironically, the info _is_ there and up-to-date, and you can usually
solve your problems if you are willing to search deep enough. So is
not the info that's missing but its accessibility. So many get the
perception of an obscure product just because there's no feeling of a
central, authoritative information repository. Those who do make it,
are bound to hit a second wall later on: the tons of info trapped in
huge mailing lists of extremely limited browsing and searching
capabilities.
For those of you who use php, postgresql, freebsd to name just a few,
you know that a good part their conversion rate goes to the way they
handle the issue on their websites.
The idea is simple but effective: instead of breaking and separating
the different **aspects** of the whole project (bug tracker, support
ml, manual, changelog, architect ml, etc.), make a single big online
documentation project, break that into **topical sections**, and put
all other aspects into each topic's page.
So for example, when I want to know about "global temporary tables", I
go to the section with the same name and I get: documentation,
supported versions, changelog, implementation notes, user comments,
examples, support questions and answers, related bugs, architectural
debate, cross-links to "related" sections etc. In the current state of
affairs, I'd call that "research".
Just a few more points:
Few users are interested in a long changelog of unrelated features
which they have to use as documentation.
All this is very achievable with a good wiki engine.
That's not marketing, merely accessibility.
As I said before, the info is there, so this is not about a
documentation effort either, but a redesign.