On Thu, 2006-09-28 at 15:23 +0200, Frank Peters wrote: > G. Roderick Singleton wrote: > > >> 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. > > > >>> 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. > > I don't see why the project that is supposed to approach this > should not know for what reason. I apologize if this was > discussed here before. Do you have a pointer? >
What is this? Frank if you want details, ask offline. All I will say to this is that I would like OOo to have its own DevGuide and other documents as well and avoid problems. > >>> 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. > > Why wouldn't we just build on what's there instead of restarting? > No sources. We are back full circle. No source from which to start for whatever reasons. This requires starting from scratch, does it not. > >> 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. > > That's good to know. Where are these works documented? > Can one see what's in the works and where it is? > They are accepted tasks for which the authors are taking full responsibility. > >> - 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. > > No, I mean creating several smaller guides addressing sub-topics. > The dev guide already is a master document but getting to be big > to be easily manageable both from an author's and from a reader's > point of view. > Ah. That would work but considering that we like to publish our larger documents on Lulu so as to generate some income for OOo, your small section idea would have to be examined to see how it fits. > >> - 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 > > What else would you like to include? > Python, perl, java are the ones that come to mind. Why do you want to be restrictive? > > 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. > > Why would that target audience be so limited? In my experience > most of the folks that do use macro functionality start off > based on examples. Most folks want extensions/addons that they simply install and they work. They do not want to create their own. Those that do want to create their own, there are the resources I mentioned. Or do you see every OOo user as a geek? In my experience, this is not so. So explain why you think that the situation, as I see, does not fit your model. > > I am not saying that the wiki is a bad place for this info. > We just should have a central access to this and not let the > folks wander around to find stuff. Not everyone is comfortable > with mailing lists. > You are talking to the converted. However, I have no control over the lists. I have tried in the past to provide a proper site map. If you have time, perhaps you could map out what we have. > >> - create docs for creating OOo extensions > > > > Now this might be interesting. We, as a project, have not visited teh > > extensions/addon question for awhile. > > On OOoCon2006, this was one of the central topics and from a > strategic point of view, it is planned to be the future for OOo. > It is a very exciting topic, also. Extensions would allow > folks to contribute without touching the inner circle of > OOo source code. Lots of functionality and little tools > could easily be distributed. And you may know from projects > like Thunderbird and Firefox, that a lot of these little goodies > are simple an easy, yet powerful helpers. Hmm, are TB and FF good examples? I find these more bloated than OOo. However, I will admit that addressing extensions/addons is probably worthwhile. Who did you have in mind? I ask because all my techie authors are tied up with on-going projects. Therefore it would have to be someone new. You are probably familiar with http://tinyurl.com/ohdbn (the task list) but I will bet others are not. We can add tasks whenever someone steps up and commits to completing the task. > > >> 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. > > Who made that suggestion? > Offline or find the other list. -- G. Roderick Singleton <[EMAIL PROTECTED]> OpenOffice.org
smime.p7s
Description: S/MIME cryptographic signature
