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. :-)
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.
All that open source motherhood and apple pie aside, it's vitally important that we have an editor-in-chief who will set prose and web content style rules, rally writers and other editors to urgent tasks, police the prototype site for bugs, and lead in driving the buglist to zarro. Volunteers?
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.
- 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?
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?
- 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.
- 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.
The key problem with Wikis is that they make it very hard to be certain whether the information you are looking for actually is, or isn't, in there somewhere. You can hunt for hours and go round in circles very easily.
- What should we use for the repository? CVS is easy for us to set up, and a known quantity with admin support (http://despot.mozilla.org/).
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.
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.
- 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.
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.
Gerv _______________________________________________ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
