Richard, >> how? it suggests that someone who understands that there's a problem >> should help solve that problem. >> >This is, in a sense, a circular argument. The one recognizing the problem, >in this case, at least, is least prepared to do anything about it.
Not quite. If he's willing to ask and understand/try/check/test/whatever the offered answers, he might then very well be able to describe this particular item. >> > 2) Such requests typically come from _users_, not necessarily >> > developers. >> >> who better than a user to help with documentation? after all, it's >> users that know what questions need to be answered. >> >While inherently true and correct, this is misleading. Those who need the >documentation the most are new, actually would-be, users, like me, who'd use >a product if there were sufficient "instructional material" to make it >readily useable. Most of the would-be users use SDCC and similar out of necessity - there's no alternative given a certain budget (namely, $0). Only a few chose SDCC because of other qualities of open-source software (e.g. possibility to add a feature), but that's sort of a necessity as well. And, most of these users, who WILL use SDCC anyway, need and will figure out this and that, given the incomplete documentation. It's just then up to their willingness to add these snippets they found out, to some general pool of knowledge. This - incremental and unorganized approach to documentation - is again something you don't really like, but this might turn out to be the only way how to get to ANY documentation. Take it or leave it. >This doesn't mean >that he ends up with a chess game when he intended to write an >income-tax-preparation tool, Oh, but why not? Now, THIS would be REAL FUN indeed! :-) >SDCC's maintenance has been pretty consistent, but I'll bet there have been >plenty of episodes of cursing, and of asking, "Why on earth did he do THIS >?" Yeah; exactly as it happens so often in very well funded and thoroughly organised projects. The problem (recognised and studied in deep detail by Mr Murphy) is, that it's only after those years when you find out which parts of your work were straightforward and crystal clear, and which were complex and obscure - and, of course, it's exactly the opposite of what you thought BACK THEN when the documentation was written... :-) Jan Waclawek ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
