[Project_owners] A MozDev Mission Statement?

Axel Hecht axel at pike.org
Tue Sep 16 16:01:46 EDT 2003


Hi,

as the thread started by Pete indicated, there is some need to discuss 
directions and visions regarding the Mozilla project. As it has been 
pointed out, not everything said in that thread is really supposed to go 
thru this mailing list, but I would think that a MozDev mission 
statement could help. Or at least a organized feedback on some virtual 
Mozilla Foundatin mission statement.

Doing that would require collecting some feedback from project owners in 
a first step, IMHO. I bet we could make a difference to what is in the 
GRE, if we had a precise use-case for it. We could as well try to get 
developers to focus on stabilizing particular parts of the code, if they 
turn out to be common pain in our asses.

So I'd like to ask project owners to answer a bunch of questions about 
their projects. Hang on hang on hang on. I'd first like to see if I ask 
the right questions.

Project name:
[Subproject name, if applicable:] (I know that some projects host more 
than one thing)

Project targets: [ ] SeaMonkey
                  [ ] Mozilla Browser (Firebird)
                  [ ] Mozilla Mail (Thunderbird)
                  [ ] Mozilla IRC (ThereIsABirdNameForThisButWhich)
                  [ ] Mozilla Calender
                  [ ] Toolkit based standalone application
                  [ ] __________
Please check all that apply. I could envision mozblog moving from a 
SeaMonkey extension to a toolkit app, for example. Spellchecker (I know, 
it's in the tree now, but just as an example) would have checked at 
least the first three.

Project requirements:

a) Modules.
Please give a list of modules that your project builds upon. Take XPCOM, 
XPConnect, DOM2 and CSS for granted. (Is that list good?) Note stuff 
like XPFE, toolkit, necko and esp. extensions, both cvs.mozilla.org or 
stuff like jslib. If it matters, add which are SeaMonkey modules and 
which are Firebird or Thunderbird modules.

a2) Which of those modules have been causing you maintainance grief. 
Please give numbers, like, "N adjustments to codechanges since 1.0, M 
adjustments to codechanges since 1.4".

b) Contracts.
Please give a list of contract IDs that your project builds upon. Only 
mention those you explicitly use. Mention JS constructors like 
XMLHttpRequest or XSLTProcessor, too.

b2) grief stats. Please give the same numbers as above.

c) Interfaces.
Please give a list of interfaces that your project builds upon.
Take CSS, DOM2 and DOM3 core for granted.

c2) grief status. Please give the same numbers as above.

Death of projects.
If you abandoned a Mozilla-related project due to API problems, please 
explain
a) which API moved to frequent, if that was the reason, or
b) what you wanted to do, which did not work. Was it a bug? #?


Yes, this is quite a bunch of work for you project-owners, but if we get 
some vision of what we expect from Mozilla as a platform as well as from 
Mozilla as an internet application (Browser, Mail, IRC), we might 
actually be some good help to drivers in finding a way.
Having detailed grief stats should enable us to give module owners a 
feedback on what people actually use outside the tree.
And it might even help you to think about where your project is right 
now, and where you could see it in the future.

Are there any important points I missed?

Axel

Disclaimer: Don't try to get me into taking documentation into this. I 
do documentation for Mozilla on and off, I participated in documentation 
projects like moz.zope.org and I commented on more than one thread about 
that in the newsgroups. If you think that coding Mozilla is hard, do an 
extension. If you think that doing an extension is hard, write docs. 
It's not so much a matter of "if", but more of "who thinks how and where 
and how integrated and another attempt dies".
It is something that the devil would be jealous off. If he himself 
didn't set up the documentation situation as it is. But I really think 
we, the human scum, scored 1:0 here.



More information about the Project_owners mailing list