That was actually exactly the way people should promote themselves into any moderatoring boards here - by saying what they can do and then, to prove that they know what they're talking of, giving an opinion about it. Well done!
But that doesn't mean I automatically also agree with you.
Well said, sir.
xitnalta wrote:I'm totally against it. Not because I would have more experience than you (I only live since '85 and started programming with 8 years, so I'm now only about 9 years "married" to computers ), but because I know (not only) HTML fairly well to know that it is not the best (and, I would argue, also not even a good) solution to this.
I've been waiting years to say this: I've been programming since you were in short pants! (Sorry, I couldn't resist)
But I see your point about HTML. Do you (or anyone else) know what format the current fancy manual is done in, the one produced and printed by NaN? If nothing else, knowing that would be good fodder for discussion.
xitnalta wrote:But please just join us by contributing to this thread about documentation formats (that I had to flame a bit, sorry, but you'll find out why).
I read that thread, but I wasn't sure why you got so upset. Not that you need to explain any further or anything; I don't want to start a rumble.
xitnalta wrote:You don't actually need to install and/or write DocBook XML locally at your machine to help authoring documentation if DocBook XML is used as the central format.
I'm not sure I understand. How would the original author know if s/he's delivering a usable document if they can't check it locally? Personally, I like to have some way to test-display a doc before delivery.
xitnalta wrote: The processing (converting author documents to DocBook XML, and generation of other formats) can be done centrally somewhere on blender.org (or by The Documentation Staff
A central 'clearing' staff makes a lot of sense to me.
xitnalta wrote:I envision that for writing Blender documentation, people should be able to contribute in the format that suits them best (and/or is easiest to check for errors in their work environment).
It could get a bit confusing for the Doc Staff if they're receiving stuff in a number of different formats, however. I suppose it might help to come up with (for instance) two or three 'accepted' formats for writers that would then be converted to whatever base format is agreed on. At least that way things wouldn't get out of hand. To go along with that, though, it would be best (IMHO) to define Author's Delivery Formats as being something that's easily-available and easy to install/setup/whatever.
xitnalta wrote:Stay tuned and feel welcome!