Henrik Lynggaard wrote:

* No good place to start: When wanting to start contributing to mozilla there really is no good place to start.

- Common sence should tell you to start at your area of interrest. My personal interrest *might* be the actual rendering or enabling some of the more fringe techonlgies like SVG,MathML and the like (fringe as in not mozilla mainstream/core), but the learning curve for these areas are simply too steep for me to do anything usefull in an acceptable amount of time.

I'm actually working on trying to set up a forum for developers to point out bugs that have enough information on what needs to be done that the learning curve is significantly lowered. If this pans out, I'll be posting more about it.


- The helpwanted keyword: This keyword is not really usefull for people starting out.

Agreed. This is how the "[good first bug]" status whiteboard annotation arose...


* Something similar to the gnome love days http://www.gnomedesktop.com/article.php?sid=1669 I think it would be great if there were some experienced developers around to assists newbie developers. I know there are a few developers hanging out in the IRC channels, but there is no concentrated effort like the bug days.

True. There used to be more developers on irc before, but the incessant review requests largely drove them off, as far as I can tell. Perhaps if we had a strict ban on such (in view of the existence of the request tracker), some could be induced to come back for a day a week or something....


* We need more good overview documentation:

Agreed. The problem is how to organize it and how to link to it from where... I wrote some overview docs at some point, and I don't even think they're linked to from anywhere on the mozilla.org site, in the wake of the site redesign.


- The renderring model, which part plays which role etc. and with pointers to source modules so that we can find the code. More stuff like the Space Manager design docs

Like http://www.mozilla.org/newlayout/doc/gecko-overview.htm ?


I admit it could be put in a more readable format, and fleshed out with more text, with some pointers added. Let me know whether the basic information in this document is about what you're looking for; if it is, I'll do some reformatting.

- An overview of which XPCOM components/services are available and their APIs.

This would need to be organized somehow -- we have a LOT of such components/services.... Suggestions on how? This is really the most serious problem with the docs we have -- finding what you want is hard.


- It would be nice if someone would quickly skim most of the docs and place a big "out of date" marker on those that are such. Then later begins the process of making them up to date, but the most important is to know if they are out of date.

If someone can generate a list of docs involved (already nontrivial), this could probably be done.... I agree that it's worth doing.


- A new bugzilla keyword to indicate good first bugs.

Like already mentioned, there is a whiteboard annotation; a keyword would maybe be faster, but past that....


-Boris
_______________________________________________
mozilla-documentation mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-documentation

Reply via email to