On Thu, 2006-10-05 at 11:30 +0200, Jürgen Schmidt wrote: > G. Roderick Singleton wrote: > > On Thu, 2006-09-28 at 11:43 +0200, Frank Peters wrote: > >> Gerry, > >> > >> G. Roderick Singleton wrote: > >>> There seems to be some problems with the current DevGuide that are > >>> political and proprietary in nature. Sun produces this guide. While this > >> can you please elaborate? What kind of problems? > > > > Are you sure you want to know? I do not think the reasons need be > > discussed on this list. They have been discussed on another list and the > > result is this request to start preparing an OpenOffice.org Dev Guide. > > you have probably misunderstand us or me and if there are still some > open questions from your side please ask. I will try to clarify > everything and Frank pointed out again that the work on open sourcing > the DevGuide and other docs is ongoing. >
Thank you but no questions. > > > >>> guide has a five year head start, it seems to me that we might be able > >>> to create an acceptable guide and avoid the nonsense. > >> What do you mean by "nonsense"? > > > > Off list if you want details. > why off list, if you have criticism you should bring it up here that > everybody can share your view or that we can discuss it public. > Quite frankly I did not want to name names. I do not know you and everyone can have a bad day. I just figured the reasoning to be nonsense. > > > >>> Let's have some ideas. If there are any takers, I can set up a task and > >>> a master document with which to start. > >> Let me emphasize that producing a Developer's Guide from scratch > >> is far from being an easy task. The original dev guide (now > >> 1,000+ pages) was created by three full time authors over a period > >> of several months. Without close relationship to the developers > >> this is a hard thing to do. > > > > Have I said it would be easy? No. What I ask is that the idea be > > examined. Your comments are part of that evaluation process. > > > >> As mentioned in my previous replies (to later postings) we > >> will open source the dev guide in the mid future but it still > >> needs a considerable amount of maintenance work. So there will > >> be loads of opportunities to work on developer docs. > >> > > > > Well this would be good. If the doc project goes ahead and gets some > > decent words down. We could examine merging at that point or whatever. > > > >> Apart from that, we should start discussing a strategy around > >> this type of docs instead of just starting off. Even with a > >> dev guide there are still huge gaps in the dev doc space that > >> should be identified and closed: > >> > >> - we have the in-depth dev guide that is very detailed > >> and highly technical for the geeks among us. > >> - we also have the (StarOffice) BASIC guide as an entry level doc > > > > We are working on addressing this. > > > >> - there is Andrew Pitonyak's excellent macro document > > > > I agree it is excellent. However it is Andrew's and, at this point, we > > at the doc project have not approached him about formalizing it in the > > documentation set. We have chosen, rather, to host it. > > > >> - cross references VBA<->BASIC on docs.oo.o > > > > In the works. > > > >> - online help content for BASIC runtime functions > >> - and the hacker's wiki > >> > > > > We can have a look at these. > > > >> This looks sort of unsorted to me. If we could work out a plan > >> and identify what we would need to complement the existing > >> docs that would be great. Possible tasks in this area would > >> encompass > >> > >> - split up the dev guide to make it less monolithic > > > > You mean like a master doc and chapters? Excellent idea. I used the > > monolithic approach with the 1.1.x guide and found it unsatisfactory. > > The 2.x guide is master and chapters. > The DevGuide is already structured this way, one document per chapter > and a master document to combine them into one document. > I assume Frank mentioned more a real splitting into smaller guides. For > example one introduction, one UNO guide, one writer guide and so on. > Think about a DevGuide collection 1 - X > Very good. Still we cannot look at it except as published. Anyways the idea to start one of our own was a good one. What, I think, has evolved from our discussions is that we need to create a more basic document for those just starting. Like a primer one would use in grade school to learn reading or a digest. Now this would complement the existing Sun guide and be most useful to the folk trying to ramp up to what the Sun guide offers. > > > >> - merge BASIC guide and macro information > > > > Maybe useful, maybe not. Creating a document that addresses only > > OOoBASIC macros might not be the best approach. However, that > > considered, a macro handbook that goes beyond our existing HOW-TOs would > > be a definite asset. > > > >> - create a OOo macro cookbook > > > > Not sure about this one. On the surface, a good idea but I think that > > the limited target audience is well served by the wiki and lists. > > > >> - create docs for creating OOo extensions > >> > > > > Now this might be interesting. We, as a project, have not visited teh > > extensions/addon question for awhile. > > > >> I confess that some of the tasks depend on Sun open sourcing the > >> guides and I apologize for the delays but I can assure you that > >> we're working on this. > >> > > > > So I was told. Along with a suggestion that we should have a look at > > creating our own. > > you misunderstand the irony ;-) Sorry there were no smilies so I was obliged to regard the instruction as a valid thing to do. I proposed that here and the reaction has been positive but also has made us realize that reproducing the existing guide would not be practical. As I said above I believe we will focus on dissecting the Sun guide for elements that the less experienced can use and that keep the technical jargon to a minimum. > > It doesn't make sense to create a second DevGuide. We should definitely > combine our efforts on one guide. > For the moment, I think the approach we are discussing is probably more useful. The Sun guide is dense and big and, until sources are available, we at the doc project cannot offer much except some proofing and grammar checking. I am certain that doc project members will come forward to help in that manner. In the meantime, starting on a set of development starting guides is probably the best solution. -- G. Roderick Singleton <[EMAIL PROTECTED]> OpenOffice.org
smime.p7s
Description: S/MIME cryptographic signature
