> It may not be the right tool for _you_. :) But it may very well be the
As long as a GUI tool can produce the code we currently have (it may be complex but that's in part due the syntax of DocBook) then it would be a tool, definitely. If the tool forces a simplification and lessening of tags and XML constructs in use, whose end result mean final rendering in a lesser format or having to update the same information in multiple locations, then it may not be the right tool anymore. For instance, the entities we use aren't always fun to update, but we do so in order to update a piece of text once that gets used in the book more than once (URL components, version numbers, etc). Those mechanisms need to stay in place to avoid having to do (and subsequently forget to do) double work. If this doesn't make sense let me know and I'll elaborate. > right tool for someone else, and make it easier for new contributors > to add changes to the book. New contributors shouldn't be adding anything to the book without it first being verified, tested and finally edited. New contributors should submit proposals and proposed changes to the list. The book will not become a free-for-all style ala Wikipedia where that kind of style is welcomed and even useful. That kind of "free for all" style should be part of the wiki. The final actual official book we produce has to undergo quality control. After something new has been submitted and agreed by the project's developers it would be a good addition, then we can worry about XML-ifying that data. Unless the contributer has figured out the XML already and we can use that as a base to save some time. If you look at most every other project - John Doe doesn't just modify a project by having his (random) changes and wishes included. They are decided upon by the developers. This is not a bad thing. If somebody wants to become an LFS developer (what we call a book editor among other things), then they need to learn our code, comply with those standards and contribute for a while. Just like in any other project, their developers need to be able to program in that project's chosen programming language and style. I realize the LFS project isn't the same but *some* of those basic principles still apply. > draws it up and is able to convey the right ideas, they've done 80-90% That's what I was getting at. That person who does 90% of the work can easily do so and submit the text to lfs-dev list or write it up on a wiki page. That doesn't *have* to mean this person should also commit to SVN at will which ends up in the "read online" links. If there is indeed an issue with style, English language barriers and technical skillset issues, then that initial write up should be edited by a book editor before it appears in the book itself. To me it sounds like you're saying anybody should or would be able to commit anything they desire to the book's content. ----- That discussion aside I do agree the XML code as it currently stands is cumbersome and it would benefit from a change of some sort. The purpose of that change is to make it easier for project developers to main the project. Not to make it easier for random people to start adding content more easily. Wiki pages don't count. Those areas would be great for users to work in, have other people including us developers comment to it, and further enhance. Then when the time is right, we can grab that stuff and put it into the LFS book itself. At the end of the day if somebody doesn't understand how to use <para> tags (which are the most frequently used ones), then a final editor can just add those during the inclusion of that person's changes. And include other tags that make sense. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
