Brendan Eich wrote:
Apology: this is a little rushed and disorganized. Please help organize an agenda, principles of DevMo operation,
One thing jumps out at me: is it too late to avoid calling it "DevMo"? Ick. Sounds like a lawnmower. :-)
Or a beverage store (http://www.bevmo.com/productlist.asp?area=home) -- what's wrong with that?
I'd like to call it "MozDev", but that name seems to be taken. We could call it "d.m.o" after "b.m.o"... I'm sure others can think of better names.
Try saying d.m.o. three times fast, over a phone, in a conversation where it might be confused with b.m.o.
Fantasai's been the voice crying in the wilderness on these issues for years. I nominate her :-)
Whoever it is should receive near-unequivocal mozilla.org backing for their decisions in their domain, like a module owner.
Need to hear proposals from would-be owners. I'm open to all comers.
- lowest/most-used toolbar has: DevMo | Topics | Library | Downloads | Samples | Subscriptions | Worldwide
Questions for discussion: What's the difference between "Topics" and "Library"? Why are "Samples" separated out?
Why have any top-level other than "Library"? So people can find stuff fast without having to parachute into the site and then back out and try again.
Library is a comprehensive, probably alphabetically listed archive. Topics is a guided tour by developer interest area, not by module, language, or standard. If the two really were the same, we could unify. It's interesting that MSDN did not.
Library is where I think we should start building first and fastest. The three-frame UI seems good to me, but if someone has a better idea, please post it.
MSDN has this horrible hacky "sync toc" button. Can we do that automatically?
Yes, please. Their DHTML tree widget has lots of problems. I do *not* propose that we clone it -- there are much better ones around, and we can optionally generate XUL to serve to Mozilla user-agents.
- How do we want to generate or otherwise maintain docs with consistent style elements, toolbar headers, etc.?
Surely some XML dialect? After all, we should eat our own dogfood. DocBook may be overkill, I don't know - we could define a simple subset and write a HOWTO.
Doron is already doing this for the DOM guide. I'll defer to him here.
- Do we want a wiki front end? Shaver has argued that we do, based on his recent experience.
In my experience, except for a few good apps like Wikipedia, wikis tend to produce the documentation equivalent of a BigBallOfMud, with broken links and circular references everywhere.
Yeah. Strong editors needed, the Wiki is just the front end, and maybe the patch-tool if Doctor isn't right.
As I understand it, despot's admin support doesn't let us do a load of things we'd want to - like delegation ("Bob, you can edit directory X, but not Y; Fred, you can edit Y and X but not Q"). Or if it does in theory, it doesn't scale.
It allows us to give access only to a list of people. That's good enough to start with. Let's not get too fancy yet.
CVS is also a particularly bad choice for a system where documents are going to be moving around a lot. Its limitations in that area are well-known.
Right, but what's better? Are we really going to jump on the Subversion bandwagon and multiply risks we have to take on just to do DevMo, apart from the repository risks, by the risk of not-CVS and newer-than-CVS?
- We have doctor (the "edit this page" link at the bottom of every page on http://www.mozilla.org/) for easy update -- but someone, as Asa said, should really extend doctor to use Mozilla's content-editable support. Myk?
This sounds like a re-inventing of the wheel to me.
Why? Doctor is here, it just needs new sidewalls.
Can we please use some content management software designed for managing web content? I don't give a stuff which one of the five thousand open source CMSes it is. But they all do the job they were designed to do better than CVS.
You mean like Zope, which last time this was tried, didn't keep version histories in any delta-encoded way, just blobs of old files in a db?
How much more risk are we adding? Remember, for independent events, the multiplication principle applies. If we are launching ASAP, why wouldn't we use what we have now?
/be _______________________________________________ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
