Re: [Zope-dev] the Zope Framework project
On Thu, Mar 5, 2009 at 3:04 AM, Hermann Himmelbauer du...@qwer.tk wrote: Am Mittwoch 04 März 2009 07:52:09 schrieb Chris McDonough: Tather than reply in kind here, let me summarize: I'm glad we agree more than we disagree, and I apologize if I've attributed to you beliefs that you don't have. It's heartening to hear that you're in favor of most of the things I'm also in favor of. But we do have real differences in opinion I think. I'd rather be constructive than obstructionist here: at the end of each item below I ask for an opinion based on a suggestion. 1) I'm not in favor of a single steering group for the *entirety* of all Zope software. We've tried a similar thing in the past (via the foundation structure); it didn't work and I'm not sure how we'd expect things to turn out any differently this time. Instead, perhaps the focus of groups should be on some much smaller subset of Zope-related software (e.g. the zope.interface+zope.component group, the zope.schema group, the ZODB group, etc). Could we consider this? What I don't see in your proposal is, how these subset-groups would be coordinated, which leads to the following: - How would these groups be formed? If there's nobody who encourages people to do so, - Higher level package/groups may have a hard life in case basic packages/groups are not coordinated and all go their own way. - How does some foreigner know, if a package is actively supported, umaintaned, deprecated etc.? How does he know, what packages exist, what they are good for and the like? For instance, I yesterday wrote that I use lovely.remotetask, then I was asked on the list why I did not use the (maybe better) zc.async package. Know why? I did not know that it existed. - I think, Zope 3 is not only about some seperate packages, but about a complete programming experience. Thus there needs to be some integrating force, that draws together all these packages, writes some documentation / tutorial / website etc. - Newbies won't be attracted by single packages. Instead, they want something complete. Who would be interested in Plone if it would consist of various packages that people would have to draw together by themselves, without decent documentation? To my mind, one key point is attracting more users. And that can only be done if we try to view things from an external, newbie-perspective. Some Ruby on Rails / Java / Turbogears programmer will only be attracted by some big picture but probably not by a collection of some subpackages. So, my impression is that there is a need for some steering group, that will, however, encourage people to form groups around packages and maintain them. I envision a Council of Elders with student representation. The Elders either know, or know who knows the history and current state of affairs, the students know the struggles of the newbies. They could provide welcome wagon, triage, and guide service for navigating the Zope wilds. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - zope-...@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 6:24 AM, Hermann Himmelbauer du...@qwer.tk wrote: Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro: On Tue, Mar 3, 2009 at 00:16, Martijn Faassen faas...@startifact.com wrote: Who is going to make that decision to encourage this? Allow this? You? Me? Who? Right now, *nobody* is making such decisions and nobody can properly get away with saying they allow it. Leadership is a way to get out of it. I think open source in general has shown two things: 1. Communities can mostly take decisions without having official authorities to do so. This is hyper democratic. 2. When they can't, usually committees can't either. In those cases somebody with a deciding vote is needed. This isn't democratic at all, but efficient. Exactly. And that's what we currently don't have. +1, though a simple discouraging of utterance can't accomplish it by itself. What you need is active leadership that encourages such experimentation. I don't know about that. I agree with you that there hasn't been active leadership for a while. But look what has happened without this active leadership. * We have two cool new Zope 3 based frameworks. One which throws out the whole concept of ZCML for doing configuration by radical code introspection, and as a result making the Zope Framework immensely more accessible. And another one which experiments with revamping the way Zope publishes things, and a related effort of rewriting the whole publisher. Both frameworks have during these experimentation reached big audiences and gained widespread if still experimental acceptance in the community. True - but to me it seems that this happened because someone took leadership in this scenario. * Zope 2 has been eggified. * Buildout has totally massacred all other forms of deployment of Zope projects. All that is true and very positive, but what has not happened and maybe never will that way, is the aggregation of all those Zope 3 efforts, documentation, website and the like. And that is something very important in order to attract a broader user base. Who decides to kill something off? If it doesn't get maintained, is dead. I guess you want somebody to make it official. I'm not sure it's necessary in a component based reality. With Zope 2 eggified for example, ZClasses gets a separate module, and it lives as long as somebody maintains it. It's then just a matter of deciding if it should be a part of the release or not, which the release manager(s) decide. That's fine for one thing: Newbies don't know which packages are maintained and which are not. They find themselves confronted with a bunch of packages and don't know what they should use and what not. Example: zope.formlib vs. z3c.form. For instance, I decided to use lovely.remotetask - but I recognized that the last commit is quite some time ago and don't really know if it's actively used/maintained. I'll chime in as a newbie. It seems many of the comments preferring ad-hoc to structure come from we know what we are doing, we can take care of ourselves I think Zope has the goal of attracting new users, and the proposal has potential to make Zope more inviting to the uninitiated. Zope is very diffuse, making it a challenge to grasp. I know I would benefit from any initiative which sought to provide an overview role. Thanks, Kent Who decides we should have a documentation website for a widely used component. Those who writes the documentation in question. :) In some way, that's already done - nearly every package has some doctest, which does often cover the package specifics very well. However, I remember the days I looked at z3c.form: I recognized that I needed to get to know the following other packages: - interfaces/adapters - z3c.pagelet - z3c.template - (and quite some more) This was very cumbersome. * who reminds us of necessary tasks and directions we're going into? Sometimes the community collectively decides on moving forward. Sometimes it doesn't. Are we really maintaining our issue tracker well, say? No, but then a person should get some sort of responsibility for that. Note: A person. Not a committee. A committee means a bunch of people are responsible, which is the same thing as saying that nobody is. Yes, that's probably true. So either this steering group is a person or has some person who decides. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ - Show quoted text - Zope-Dev maillist - zope-...@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 8:43 AM, Andreas Jung li...@zopyx.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Show quoted text - On 03.03.2009 15:37 Uhr, Kent Tenney wrote: On Wed, Mar 4, 2009 at 6:24 AM, Hermann Himmelbauer du...@qwer.tk wrote: Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro: On Tue, Mar 3, 2009 at 00:16, Martijn Faassen faas...@startifact.com wrote: Who is going to make that decision to encourage this? Allow this? You? Me? Who? Right now, *nobody* is making such decisions and nobody can properly get away with saying they allow it. Leadership is a way to get out of it. I think open source in general has shown two things: 1. Communities can mostly take decisions without having official authorities to do so. This is hyper democratic. 2. When they can't, usually committees can't either. In those cases somebody with a deciding vote is needed. This isn't democratic at all, but efficient. Exactly. And that's what we currently don't have. +1, though a simple discouraging of utterance can't accomplish it by itself. What you need is active leadership that encourages such experimentation. I don't know about that. I agree with you that there hasn't been active leadership for a while. But look what has happened without this active leadership. * We have two cool new Zope 3 based frameworks. One which throws out the whole concept of ZCML for doing configuration by radical code introspection, and as a result making the Zope Framework immensely more accessible. And another one which experiments with revamping the way Zope publishes things, and a related effort of rewriting the whole publisher. Both frameworks have during these experimentation reached big audiences and gained widespread if still experimental acceptance in the community. True - but to me it seems that this happened because someone took leadership in this scenario. * Zope 2 has been eggified. * Buildout has totally massacred all other forms of deployment of Zope projects. All that is true and very positive, but what has not happened and maybe never will that way, is the aggregation of all those Zope 3 efforts, documentation, website and the like. And that is something very important in order to attract a broader user base. Who decides to kill something off? If it doesn't get maintained, is dead. I guess you want somebody to make it official. I'm not sure it's necessary in a component based reality. With Zope 2 eggified for example, ZClasses gets a separate module, and it lives as long as somebody maintains it. It's then just a matter of deciding if it should be a part of the release or not, which the release manager(s) decide. That's fine for one thing: Newbies don't know which packages are maintained and which are not. They find themselves confronted with a bunch of packages and don't know what they should use and what not. Example: zope.formlib vs. z3c.form. For instance, I decided to use lovely.remotetask - but I recognized that the last commit is quite some time ago and don't really know if it's actively used/maintained. I'll chime in as a newbie. It seems many of the comments preferring ad-hoc to structure come from we know what we are doing, we can take care of ourselves I think Zope has the goal of attracting new users, and the proposal has potential to make Zope more inviting to the uninitiated. Zope is very diffuse, making it a challenge to grasp. I know I would benefit from any initiative which sought to provide an overview role. I started up with something for zope2.zope.org in order to bring sort out the various things a bit: http://zope2.zopyx.de/about-zope-2/the-zope-eco-system That's very useful, and seems to describe the theory of the Zope world. In theory, theory and practice are the same, in practice they are not. My post was prompted by the mention of knowing which of several similar components is preferred, deprecated, abandoned. Maybe this doesn't fall within the proposal, but it strikes me as an element of 'steering'. I think that watching exchanges between a steering entity and the dev community would be a good vantage point for getting a picture of the Zope landscape. Thanks, Kent Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmtQfsACgkQCJIWIbr9KYw35wCgjXRDehJnSK44ztKrSLa5iizk uUwAoMTQpj+0tSbI3NA5zYEgHLrFe4zY =y1Df -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Why I dislike narrative doctests
On Thu, Apr 24, 2008 at 3:07 PM, Jim Fulton [EMAIL PROTECTED] wrote: On Apr 24, 2008, at 1:12 AM, Christian Theune wrote: Hi, On Wed, Apr 23, 2008 at 04:47:59PM -0400, Jim Fulton wrote: On Apr 23, 2008, at 4:47 PM, Marius Gedminas wrote: ... The point of my message was not to whine about the state of zope.testing, but to present a new argument against the current fashion of using plain-text narrative doctests for everything. Except that that is not the current fashion, which has been pointed out many times in many places. For my own record (I must have missed this many times in many places), is the current fashion something along the lines: Use the various test styles as reasonable, text-file narrative doctests are preferred. No. WRT doc tests: - If a file is documentation and a test, make sure it is good documentation. In that case, documentation comes first. Don't add so many tests that it ruins the documentation. - Test edge cases in separate tests. These are typically short-ish strings in test modules. - A variation is to have a narrative that doesn't try hard to be documentation. The narrative can be convenient, up to a point, even in a test. These should be clearly marked as not being documentation. However, as Sphinx lowers the barrier to cross-referencing, they will become important as link destinations from 'real' documentation. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists -http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Why I dislike narrative doctests
On Fri, Apr 25, 2008 at 9:39 AM, Jim Fulton [EMAIL PROTECTED] wrote: On Apr 25, 2008, at 10:20 AM, Kent Tenney wrote: However, as Sphinx lowers the barrier to cross-referencing, Sounds like I need to check that out. :) they will become important as link destinations from 'real' documentation. Maaaybe. I like doctests for readability even if they aren't documentation. I'd be hesitant to link to d=non-documentation from documentation. I think even non-documentation doctests are documentation since they demonstrate correct usage. They need to be explained in the linking document, but they are invaluable as examples. Seems like a natural separation of concerns. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Why I dislike narrative doctests
On Fri, Apr 25, 2008 at 10:11 AM, Kent Tenney [EMAIL PROTECTED] wrote: On Fri, Apr 25, 2008 at 9:39 AM, Jim Fulton [EMAIL PROTECTED] wrote: On Apr 25, 2008, at 10:20 AM, Kent Tenney wrote: However, as Sphinx lowers the barrier to cross-referencing, Sounds like I need to check that out. :) they will become important as link destinations from 'real' documentation. Maaaybe. I like doctests for readability even if they aren't documentation. I'd be hesitant to link to d=non-documentation from documentation. I think even non-documentation doctests are documentation since they demonstrate correct usage. They need to be explained in the linking document, but they are invaluable as examples. Seems like a natural separation of concerns. To make this work well, the doctests would want to have some markup added to identify specific tests, so the link would be to the test, not the file. This would be a good entry level chore for folks wanting to contribute. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: new zope.org, sphinx, and documentation management
On Thu, Apr 24, 2008 at 2:09 AM, Paul Carduner [EMAIL PROTECTED] wrote: On Wed, Apr 23, 2008 at 10:48 PM, Paul Carduner [EMAIL PROTECTED] wrote: On Wed, Apr 23, 2008 at 12:01 PM, Martin Aspeli [EMAIL PROTECTED] wrote: I would start with the simple HTML approach, personally. It may be all we need. Hopefully there will be a first sample of this in the next hour or so. Ok, I setup a sample of what sphinx produces after a quite minimal setup for z3c.form. Check it out at: http://docs.carduner.net/z3c.form/. I made a few small modifications to the existing documentation, which I checked into a branch on svn.zope.org along with the sphinx setup generated for me by the sphinx-quickstart command. A few goody features include: Full text searching powered by javascript: http://docs.carduner.net/z3c.form/search.html Module index with quick synopses: http://docs.carduner.net/z3c.form/modindex.html (click on the plus symbol after the big Z) Cross links to other parts of the documentation: http://docs.carduner.net/z3c.form/src/z3c/form/README.html So far, I think this is pretty good for what took me maybe an hour. Think of what it would be with some extra documentation cleanup. Cool!. The Zope-3.3.1 tree contains 70 README.txt, 309 *.txt so, more than 70 files of correct, up to the minute examples of use. That's a lotta doc. If not adequate in themselves, invaluable as link destinations when explaining with prose. As they grow ..contents:: directives, and more section headings are added, glossary tags are added, they will increase in value. -- Paul Carduner http://www.carduner.net ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] new zope.org, sphinx, and documentation management
On Wed, Apr 23, 2008 at 2:44 PM, Christophe Combelles [EMAIL PROTECTED] wrote: Paul Carduner a écrit : * THE POINT OF THIS EMAIL IS BELOW * I would like to develop a buildout recipe that generates aggregated documentation for a package (like z3c.form) using sphynx and publishes it to the new zope.org website. I want updating of zope documentation on zope.org to be as easy as uploading a package to pypi: When you are ready to make a release of a package, you would then do: $ cd z3c.form/tags/2.0/ $ python setup.py register sdist upload $ ./bin/buildout $ ./bin/update-documentation You would then be able to go to http://www.zope.org/projects/zope3/documentation/z3c.form and see everything from developer docs, to tutorials, to how-tos, etc. Won't it be redundant with the doctests displayed on the PyPI? Sphinx provides added value to existing doc. The PyPi page is fine, but it's nice to have a front page with searching, indexing, TOC, which is all basically free. The page which exposes the doctests would explain the heritage of this material. Some will prefer it to doc written from scratch. The beauty of the existing doctest is that it is maintained and correct. It would be nice if there could be a level of commit permission just for enhancing the doctests for Sphinx. see http://sphinx.pocoo.org/markup/index.html You speak about things like z3c.form, i.e. individual packages. They already have their doc (readme) displayed on the cheeseshop, which is the first place to look for packages. The problem is that many README.txt are more unittests than high level docs. In my opinion many README.txt contents should be moved into deeper functional doctests, and replaced by real introductions, or easy-to-read howtos. On zope.org, instead of individual egg docs, we need high level docs or integration docs that cover several packages at once. In which eggs do you want to put them? Christophe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] paver: buildout is utterly doomed
From Kevin's blog http://www.blueskyonmars.com/2008/04/22/paver-and-the-building-distribution-deployment-etc-of-python-projects/ (http://tinyurl.com/68sz6u) The idea is to use zc.buildout's machinery, not reinvent it. On Tue, Apr 22, 2008 at 8:44 AM, Martijn Faassen [EMAIL PROTECTED] wrote: Hi there, I just found out about this site: http://www.blueskyonmars.com/projects/paver/ I know that the author has used buildout in the past. He apparently decided to roll his own. I have no idea what the technical qualities of paver are. To get your attention, let me spell out a strongly worded and opinionated message nonetheless: zc.buildout is toast. It's on the way out now. Paver is going to compete it away and buildout is doomed to be a niche project only used by weird zope people. That's strongly worded. I'll admit it's drastically overstated. It's based on virtually no technical information! But that's exactly how many programmers will judge the projects: on community aspects, and not primarily technical. Paver has this in its favor: * Paver actually has a nice website that speaks to Python programmers of simplicity. zc.buildout has cheeseshop page with a lot of doctest documentation people have said was hard to understand. (including the author of paver!) * the author is well connected in the Python community. I'd say TurboGears and Pylons people are likely to go for Paver. * it's *already* showing up on programmer's sites like programming.reddit.com, where I just found it. Nobody bothers to link to buildout, as there's no easily digestable message about it available. So, I fear very much that this, or some other alternative, will wash away the undoubtedly more feature-rich and technically robust zc.buildout, if buildout doesn't present itself better. Without better presentation, fast, buildout is doomed to be a Zope-specific thing forever. You Can Save Buildout! So, who is up to make a nice clean looking website and a few tutorials for buildout? It needs a website. Buildout has been around for a few years without a proper website already, Paver for 5 minutes and it's got one. I'm not going to do it, but someone should. Just to be sure, I certainly *won't* be doing this. Jim won't either, and I don't expect it from him. Let him write great code, not make websites. So don't sit back and hope someone else will do it, as they won't. If nobody else can bother to step up, Paver probably deserves to win. If you're intereested, I think we already have a nice buildout for deploying grok.zope.org that can probably be adapted. The repoze people have a nice site too, so you could go ask there. Alternatively we start to figure out how to convert our buildouts to Paver. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: paver: buildout is utterly doomed
The Paver site seems based on the doc generation thing that the new docs on python.org use. Sphinx is the doc generation thing, it's really nice, takes ReST files and creates TOC, indexes, provides search, all from an attractive front page. If a tiny bit of markup was added to the existing ReST files in zc.buildout and massaged by Sphinx, the result would be useful and accessable doc. Alternatively we start to figure out how to convert our buildouts to Paver. :) I'd argue that the build system isn't quite as important as all that. We should ensure our packages work properly any setuptools-capable environment. Building and deployment will always be project-specific to a certain extent. However, I think we (including Plone) have a lot vested in zc.buildout and I think it is worth presenting it in the proper way. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Let's fix the damned website
Look at Sphinx for providing brilliant access to ReST doc. http://sphinx.pocoo.org/ doing no more than adding a .. module:: modname directive to a ReST file causes it to be converted to html, latex or pdf indexed and searchable. placing modname in the .. toctree:: directive creates the proper links to the module doc I really think Sphinx can easily add a lot of value to existing Zope doc. From that starting point, Sphinx offers lots of tools for enhancing access to, and presentation of, ReStructuredText It's being used for the official Python doc, no fly-by-night outfit. Thanks, Kent On Sat, Apr 5, 2008 at 3:10 PM, Paul Carduner [EMAIL PROTECTED] wrote: On Apr 5, 2008, at 12:11 PM, Martin Aspeli [EMAIL PROTECTED] wrote: There's no content that isn't visible to anonymous on the site. Basically, we originally thought we would have one documentation/learn section for all Zope technologies. However, it seemed to make more sense to have a folder for each sub-project (zope 2, zope 3, cmf, zodb) and keep documentation there. What questions do you have? Ah now I understand and found the Zope 3 section. One question I have is how the site might integrate with the apidoc tool. At least with Zope 3, a lot of good updated documentation lives in the svn repository in the form of Restructured .txt files. All it would take to make these documents easier to find and read is to hook them into apidoc and make a nicer skin for the apidoc book section with the look and feel of the new site. Basically, I want to write documentation once (in svn) and have it appear nicely formatted in multiple places: pypi, apidoc, zope.org, and wherever else. Will this be possible/is it part of the plan? -- Paul Carduner http://www.carduner.net ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists -http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
