Re: Launching PostgreSQL KB Project Mark 2

> On the other hand, I wouldn't blame you if you thought that
> the latest KB effort was liable to founder and die and that
> you needed to have a back-up.
> It wouldn't be the first one.  But in that case I'd suggest
> looking at adapting something existing (like Bricolage,
> Framewerk, Drupal, etc.) rather than coding up from scratch.
> If you keep your requirements simple, at least one of these
> should suffice, and has the tremendous advantage of having
> external code maintainence, documentation, and help.

I did look at this. It was my evaluation that it would take me *more*
work to adapt something like Drupal to my requirements, than to code
from scratch. It's not as easy as one would like it to be to make these
CMSes integrated into something existing. They tend to be designed to be
the "master system" that can plug in your own custom modules in, not to
be one of those custom modules.

And if I use one of those systems, I can't use hte features that are in
our *current* framework. So there's a downside with it from that
perspective as well.


And just to clearify - it's not like I've spent a lot of time on this.
It has taken a long time, but there's not really a lot of active coding
time for it. And I don't expect it to be much more.


> One of the big issues -- in fact, THE big issue -- with
> increasing participation in WWW administration is the total
> and complete lack of documentation for any WWW decisions,
> infrastructure, or code.  While I can understand lagging in
> documenting stuff (like, I have a draft of the release PR
> procedure I have yet to discuss online despite being on my
> HDD for a month), it's extremely irrational for people on
> this list to pitch a fit at potential contributors for not
> psychically understanding what WWW wants or not reading the
> WWW list back to the beginning of time.

There are *some* docs. Not much, clearly not as much as ther eshould be.
But ther *is* basic documentation of how the system works. It's in the
README file in cvs. Sure, it would be nice with more, but the stuff
that's in the README file was enough to bootstrap me into the code - and
this is actually the first project I've ever coded PHP on.

This is for the actual technical system. There is, AFAIK, zero
documentation on the *design* - things like how to use the CSS classes,
what elements to use where etc. To me, this has been a much bigger
problem.

This is probably also partially because whlie the PHP code that runs the
site is fairly simple, the CSS stuff is a lot more complex than most
others I've seen (partially because of the wlel-defined behaviour of PHP
vs the ill-defined behaviour of most browsers). That could also be
because I understand the PHP stuff a lot better, and that tends to make
it look easier :-)


> infrastructure.  For example, we've been running on the new
> web site code for almost 2 years, and
> how many translations of the site have there been?   Exactly
> none.  Why?
> Zero documentation on how to translate the site.

No. There is documentation on that. It's in the README file in CVS.

I think the problem is more that the translation process has been set up
by someone who doesn't do translation. And there is nobody on the active
web team today that do it.  AFAIK the system as it stands *works*, but
it may not be ideal from a translators point of view. To correct that,
we need someone who both has the technical know-how to adapt the system
(and the will to learn what has to be adapted) *and* knows what actual
translator requirements are.


> If our project can insist that all database code patches come
> with full documentation, I think maybe it's time that we
> start insisting that all WWW patches come with documentation.

Not a bad idea in general. Though we'd have to start from the bottom,
which is with the frameworks etc.


//Magnus