[Project_owners] A MozDev Mission Statement?
davidf at sjsoft.com
Tue Sep 16 16:10:49 EDT 2003
Axel Hecht wrote:
> 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.
While I agree that this is useful, I don't see how the process below
would result in a "mission statement" for Mozilla. Surely Mozilla is
bigger than mozdev.org.
The mission of MozDev should be to create great applications using
Mozilla and extensions for Mozilla in its various forms ; a secondary
goal would be to help develop Mozilla so that making applications is
So to clarify, the process would result in certain goals for Mozilla/GRE
that would make life easier/better for application/extension developers.
I don't think it would be a useful way to try and identify Mozilla's
overall mission or general goals, but rather a useful way to provide
feedback to them on some of their current goals (Mozilla as a
> 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
> 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.
> Project_owners mailing list
> Project_owners at mozdev.org
More information about the Project_owners