Thomas de Groot <tho### [at] degrootorg> wrote:
> I find it a big problem that all information is scattered over the years
> and the newsgroups. So much is lost and sometimes re-discovered several
> times. There is the Documentation of course which represents the basic
> foundation of POV-Ray, but the extra info and expertise of individual
> users is not or hardly brought together comprehensively. It takes time,
> energy, availability, understanding. Not always present together for us
> poor users! ;-)

It certainly has been a long-standing issue that many of us have mused about.

Mr. Henderson seems to have methods to search the site.  That would be useful
for quickly digging through it all to uncover what one might be looking for
without resorting to an hour of searching and clicking a profusion of links.

We are where we are, with the state of the software, the development, and the
user-base.  And some of the topics and the expertise have been rendered outdated
by revisions in both software and methods.

As we have issues with accessibility for editing material (spam prevention, etc)
it might be useful to make a copy of the documentation onto a site where it CAN
be edited, and then create extra links and sections that help string it all
together.

I'm a fan of signs and checklists and spreadsheets - because you get all of the
organizational stuff out of the way and then the static object provides its own
directions.  It would be useful to come up with an efficient strategy to sift
through all of the posts and files and cull out any material that doesn't
provide important usage information.   Then a finer sifting and method of
organization could be designed.   People could follow along and review, tag, and
edit posts and files as they had time and inclination.  Very much like a WIKI.

That would be a part of the task dealing with preservation of the existing data
and expertise, with helpful cross-indexing links to make the old posts more
useful.  Maybe tag each added comment with a username and time/date.
That way everything could be sorted and processed in place, while preserving the
entirety of the original record.  Very often the valuable _history_ of the
development is lost, which might offer valuable clues to understanding purpose
and possible solutions/updates.

Another part might be just taking one specific topic - like radiosity, and
writing a user-generated documentation page, along with some working code to
illustrate the usage.  I like the code approach, because it's something that the
end-user/reader can get their hands dirty with, adjust settings and get
instantaneous feedback from, isn't purely speculative - since the parser and
software enforce its accuracy, and can encapsulate a wide number of variations
and combinations through #switch and #if.

Good, extensively commented code is probably the most efficient way to dispel
any misconceptions and get right down to the heart of USING whatever it's about.
 We've all had that section of documentation that we've read 30 times and are
still no closer to implementing a working line of code from.
The primary goal is not to have code that is efficient, or fast - but
instructive and explanatory.  Extra versions / #switch blocks can show how to
make the fundamental operation faster and more efficient, but those are in
addition to the primary code.

Post a reply to this message