Boris Zbarsky <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Henrik Lynggaard wrote: > > Do you have any idea on what the time line is ? are we talking short > > term or long term > > Well, the idea came up about two days ago. The hope is to figure out a way to > do it soon (a week? something like that).
Great :-) > > It is a start, but think it should be a set of keywords, because > > different people need different starter bugs. Some want to get started > > with cplusplus while others might just need some with GUI (XUL etc) > > I'd think the component the bug is in covers this part.... I would disagree. If we consider a component like "Address book" , there are bugs that cover all ranges, namely there are some hardcore bugs, some good first cpp bugs, some patchmaker bugs, some XUL bugs. Basicly I cannot see from the component "Address book", with type of first bug it is. I would agree that some component can indicate that they are only one of the things, like "Mail Back End", but it is not something that can be said for all (most?) components.. > > We HAVE content. We have somewhere on the order of 10 documents just on the > layout engine. We have good documentation on strings, arrays, and hashtables. > We have various XPCOM documents, RDF docs, security docs, uriloader > documentation, etc, etc. > > The problem is that none of this is very easy to find. "stuff it in a wiki" > doesn't help find it. The good thing about wiki's are they are easily updated, so I think it would be good for a kind of catalog pages of the documentation. It would be quick to make ad-hoc overview pages. > > How about an simply list like > > > > FileComponent: Performs local file access <link to api> > > PreferenceComponent: Performs storage and retrieval of program > > prefereces <link to api> > > This list would have hundreds (if not thousands) of items in it. I see 93 IDL > files in xpcom/, and some of them define multiple interfaces... And these are > just the core XPCOM layer. I see 809 IDL files in the tree if I exclude the DOM > api and all of mailnews and editor. Just having a list won't cut it for this > stuff -- it needs to be categorized somehow... Well, lets start by getting the list, then lets sort it and put it in categories. Are you saying that all such API's are defined in the IDL files, if that is the case I might give it a try.. Are actual API should really be some sort of extract of the IDL files, like doxygen, javadoc or the like. I once found some doxygen extract from mozilla codebase http://unstable.elemental.com/mozilla/ but I'm not sure how uptodate it is and how it is administered. > There's a lot of stuff on the website that's not docs. Most of the website, in > fact. The website CVS is somewhere on the order of 60MB, last I checked... I was perhaps assuming that the content was somehow structured so that one could overcome it by looking at a minority of subfolders.Maybe it was a bad assumption.. Best Regards Henrik _______________________________________________ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
