Tony Collen wrote: > Carsten Ziegeler wrote: > > Due to my nice(?) rearranging of the docs we are not able > > to update our website without breaking some external links. > > And this is (to say it friendly) very bad. > > > > But we have updated/new docs that should be published asap. So > > how can we manage this? > > > > Stefano had an impressing (wild) idea at the GT which sounds > > very cool, but will unlikely not happen today or tomorrow. > > I personally wanted to update the site asap, at least with > > the next release for 2.1.3 - our great bug fix release. > > Hmm, what was Stefano suggesting? I'd be interested to know what > he's got turning in those gears in his brain :)
It is going to be great when virtual participants can be at the GT2004 (surely our "collaborative tools and techniques" experiment will have progressed by then. > > I wanted to start this RT to discuss some possibilities, so > > here are some: > > > > a) I revert the structural changes (cause in the end it's my > > fault) > > +1 for reverting for now. This is just a Random Thought at this stage, so it is a bit early to vote. Lets discuss options first. I too prefer to revert and i will try to help. We need to do this re-structure steadily and in the upcoming 2.2 module. > > b) We update and don't care about external links > > c) We update and care a little bit about external links and > > redirect a 404 to let's say the start page > > > > Thoughts? > > I think we need to make a giant list of all of our docs/pages, what they do, and > their current place > in the docs structure. There's a lot of stuff out of place, one thing I always > notice is the page > talking about DELI being switched off. For some odd reason, it just seems like this > page does not > belong there. We used to have that. There was an automatically generated table of contents which aggregated all of the book.xml files and made a list of every doc. It seems to have been removed but not replaced with anything better. Yes, such a list, and past discussions and previous "table of contents" (= structure) proposals will help us to sort it. > We might need to get away from the "developer" vs "user" notion, because depending > on how much about > Cocoon you already know, you might have to hack out a new generator (which would > seem to imply > information in the developer section) while you are really a user. +1 ... we have talked about that many times. Almost every user is a developer. Anyway "Trails" are better navigation method. > IMHO, the line between developer and user is blurred, and I think the docs need to > reflect this > somehow. Touching back to the idea of getting a giant list of all the docs, > something I might try > is to get a bunch of notecards, and write down each doc on them. If there's a > "line" of documents, > connect them all together, and shuffle them as a unit. Post-It notes might also > work well. This > way it's easy to move things around logically without disturbing the file system > structure until we > have everything sorted out. Come on down, you have some great ideas. > From the sounds of it, we're almost at a critical point with the docs. We NEED to > make it easy to > find things. I've always been of the opinion that the best site docs in the > open-source world exist > on www.php.net. They combine the "official" docs -- organized very well and > logically -- with > user-submitted comments, which is sometimes worth more than the real docs. This is > something we > need to explore for future versions of the site docs, I think, but it may not happen > until we have > Cocoon serving its own docs. Yes, surely we must be getting closer to EODF - eat our own dogfood. But still, Forrest is surely clever enough to do some of these requirements now. --David
