[Project_owners] A MozDev Mission Statement?

David Fraser davidf at sjsoft.com
Tue Sep 16 16:10:49 EDT 2003

Axel Hecht wrote:

> 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.

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 
easier/more effective.
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 
development platform)


> 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.
> _______________________________________________
> Project_owners mailing list
> Project_owners at mozdev.org
> http://mozdev.org/mailman/listinfo/project_owners

More information about the Project_owners mailing list