[Project_owners] A MozDev Mission Statement?
axel at pike.org
Tue Sep 16 16:01:46 EDT 2003
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.
[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.
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".
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.
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
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?
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