[SciPy-dev] Some Feedback
jonathan.taylor at utoronto.ca
Thu Nov 10 13:20:24 CST 2005
Do you think that while scipy is in development mode, it may be enough to
just link to other sites from a main trac page? Later on, we could move
trac behind a static/moinmoin/etc front page.
On 11/10/2005, "Andrew Straw" <strawman at astraw.com> wrote:
>In addition to Trac, we could consider MoinMoin  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.
>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 , 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.
>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.
>Scipy-dev mailing list
>Scipy-dev at scipy.net
More information about the Scipy-dev