[SciPy-dev] Some Feedback

Andrew Straw strawman at astraw.com
Thu Nov 10 12:51:37 CST 2005

In addition to Trac, we could consider MoinMoin [1] as the "public face"
of scipy.org.  Let me declare immediately that I'm no Trac expert, so if
Trac can do all of these things, great, and please ignore this
suggestion. Reading the descriptions of Trac on this thread as well as
my limited experience as a user is all that I'm going on here.

[1] http://moinmoin.wikiwikiweb.de/

As the administrator of several MoinMoin sites, I can vouch that it's
easy to setup, easy to maintain, and easy to contribute to.  MoinMoin
has some protection against Wiki Spam [2], an apparent shortcoming
mentioned here in considering Trac for the public face. Don't get me
wrong -- I think Trac is super for viewing an svn repository, submitting
bug reports, and so on, but perhaps we could use it just for that role
and use MoinMoin in the public face.

[2] http://moinmoin.wikiwikiweb.de/AntiSpamFeatures

Another point in MoinMoin's favor as the public face is that if we want
scipy.org to be a starting point into the universe of scientific
computing in Python (which I think there's general consensus for), a
Trac wiki may give the wrong message. My impression of a Trac instance
is one wiki==one project. I think a MoinMoin wiki may make it easier to
create the distinction between scipy.org-the-website and

Regardless of wiki choice, I agree with Robert Kern's suggestion that
review-by-Wiki is tenable, at least until proven otherwise. If it came
to trouble, MoinMoin (I don't know about Trac) has a sophisticated
access control list model which can be tuned to a per-page granularity.

Janet M. Swisher wrote:
> Robert Kern wrote:
>>The evidence suggests that Plone just isn't suited to the kind and
>>amount of content that our community is producing. Plone is a great CMS,
>>but it's not so great when you don't have a lot of content to manage.
>>Plone was selected for the website years ago on the assumption that
>>people were going to register and stake out little homepages of their
>>own to post their stuff. Years later, we don't have many members doing
>>that but a fair amount of people posting to the Wiki. The review-by-Wiki
>>process is, I think, tenable. Or at least as tenable as the Plone review
>>process which we've never used to any real extent.
> I think there is a process/access issue introduced by Plone, or by the 
> way we've implemented it. Yes, site members can create content in their 
> home folders. However, I don't think most members realize that's 
> possible, or that such content would be accessible to other members. 
> Also, people like to collaborate, not just work in their own silos. They 
> do contribute to the existing wikis, because that is the only "public" 
> area that they're allowed to change.  The non-wiki public areas are 
> locked down except for commenting (and I think not all pages allow 
> comments). Only a small handful of users currently have access to change 
> the public pages, so pages grow stale when the original owners don't 
> have time to maintain them.
> Plone seems to be oriented toward PR-type content management, where you 
> publish content that remains static unless you replace it with totally 
> new content. (Plone doesn't really manage versions, because, in the 
> intended workflow, you don't really need that.)  It's possible to use 
> Plone in a more collaborative mode, as is done at oooauthors.org (now 
> also hosted by Enthought). However, the content being developed there 
> isn't even really published there -- it's officially published on 
> documentation.openoffice.org -- so the community doesn't worry too much 
> about its "public face".
> For the scipy.org site, we haven't figured out (partly for lack of 
> trying) how to balance the publishing mode and the collaborative mode. 
> How do you balance preserving "blessed" content and organization against 
> making it easy for people to contribute? I think it's possible to do 
> that within Plone; it has a great deal of flexibility that we haven't 
> taken advantage of. However, given Plone's apparent performance 
> drawbacks, switching to Trac is a reasonable alternative. Enthought now 
> uses Trac internally for other projects, so we (especially Joe) would 
> get the benefit of consistency.

More information about the Scipy-dev mailing list