On 11/13/2011 3:43 PM, John Thornton wrote: > Kent, > > The guidelines I was working under was: > If the image was based on a dxf file retain that file so changes could > be made if needed in the future. > Use png images when possible (always use png was the actual guideline). > > I have no idea what the guidelines for 2.5 is as it has been completely > changed... > > I tried to keep/move all images and dxf files in the /images directory. > > I'm sure that many if not most of the screen shots are out of date and > need replacing with 2.5 screen shots. > > I'm happy to work on this, but I'm not until I get some assurance that > all my work is not going to be tossed in the trash again. > > John > Hi, John.
Your frustration is palpable even at my distance. I wish I knew enough of what has been happening to be able to offer assurances, but I don't so I can't. At this point, I'm just trying to help get this "stuff" into shape so we can put out something credible for 2.5 but also have a useful base to work with in future. I may be completely off base here, but it seems from email traffic I've seen that there are two basic issues in play simultaneously. The first issue is the big one in my book. How should this material be organized? Should it be one humongous document? Many documents? Either way, how should the material be organized in the document(s)? Should material be used in more than one place? Should the primary mode of access to information be screen browsing or hard-copy reading? (Sure, pdf allows for inter- and intra-document linking but it is not as facile as hyperlinking in html, which causes one to want to organize material more linearly. Similarly, it is usually a nightmare to try to print off a complex html document as a hard-copy reference.) You certainly have been involved in this issue. I don't feel qualified to comment since I have not been intimately involved either in the generation of the documentation or in its use. The second issue is the transition in production technology from lyx to asciidoc. I actually think this was a good idea but I can see how frustrating a process it has been to the "content managers." There's been many a slip twixt the fork and lip, to quote my grandmother. What should have been a self-contained issue has become intertwined with the first issue because material has moved around, disappeared, reappeared as the 2.4.7 files get worked over. (It was Jon Elson's alarm that got me looking into this.) This is issue that I'm trying to sort, making sure we have the material in good enough shape to move forward. The image-file guidelines you cite are very reasonable. I would extend them to include retaining any graphical-source file, not just dxf files, if it is necessary to allow future rework without recreation of the artwork from scratch. What I would like to see restricted is the variety of formats referenced in the resulting document(s)---formerly, via the lyx files, now via the txt files. I don't recall seeing a guideline to always use png, but that's the kind of call I'm pushing for. As for 2.5 documentation guidelines, I'm hoping to nudge "us"* toward them. The relevant files in the source distribution (README, etc.) are hopelessly inadequate. I read elsewhere that Chris Radek is the 2.5 release manager. Call me a dumb engineer, but in my working days, the person with that title was the one to make the call if there weren't guidance from above (and be careful what you wish for when you ask for guidance from above! See almost any Dilbert cartoon.). Thanks for pointing out that the screen captures are probably out of date. I might have thought of that eventually :-) I'll check as many as I can but so should everyone. Regards, Kent *That is us as in "we have met the enemy and he is us" from Walt Kelly's Pogo comic strip. ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
