[Nipy-devel] website modifications

[Jarrod Millman]

Sorry for the delayed response, I was busy and wanted to see if anyone
else had any comments before I responded.  I don't know how coherent it is,
but here are my thoughts about the issues raised by Fernando's last email.

On 5/11/06, Fernando Perez <fperez.net at gmail.com> wrote:
> Managing both a Moin and a Trac wiki does entail some overhead, and
> for a small project it's still viable to keep a Trac site with user
> and developer areas which are somewhat separated. In fact, quite a few
> projects on the net are using Trac as their only wiki, so this isn't
> unheard of.
>
> On the flip side, Moin does look a lot nicer, it is more customizable,
> and it won't expose all the development-centric links on the navbar
> which are ever-present in Trac.

I think that we all agree that for any open development project it is
important to provide distinct user's and developer's sites.  I also think
that making the 2 sites obviously and *visually* distinct is important in
terms of user accessibility.  Having the 2 sites on different wikis is
a very easy way to achieve this.  The 'users' site should be very simple
and hide most of the project complexity.  This is true both in terms
of visual clutter on the site itself as well as the amount of information
presented.  In this respect, I think that a user's site should provide a
very minimal amount of information and refer those interested to other
sites.

I also think that Fernando's point about the development-centric links
being exposed on the user's site is a serious problem if we use trac for both
the user's site.  Of course many users will also be interested in the
developer's site, but only once they have decided that the project is of
interest to them.

The Berkeley imaging tools (formerly called recon_epi) project has a TWiki
user's site and a Trac developer's site:
https://cirl.berkeley.edu/view/BIC/ImagingTools
https://cirl.berkeley.edu/trac/wiki/ImagingTools
In Berkeley's case we all ready had a TWiki instance running as our general
wiki, so we just created a Trac instance for code development.  Brian and
I spent a lot of time discussing the merit of splitting the user's and
developer's
site onto 2 different wikis.  Now that Brian and I are not so heavily involved
with that project the sites have diverged somewhat from our original intent,
but they still capture much of our discussions.

Another example is how Enthought splits the user and developer sites:
http://code.enthought.com/
http://www.enthought.com/enthought
In particular, I think they have a nice front user page for the Enthought Tool
Suite (ETS):
http://code.enthought.com/ets/
It has most everything I would expect to find on a user's page: a list of
components, download packages, installation information (e.g., dependencies),
mailing list, and a link to the developer's page.

Currently, both the ipython and nipy projects have a pure html user site
and a trac based developer's site.  I think that both sites work will
in the sense
that a new user coming to either site can quickly find the information they need
without feeling overwhelmed.  There is a lot of information pointed to
by the ipython
main site, but it is feels like the site is manageable, because it is
so visually obvious
that most of the links take you to "other" sites.  I know this may
seem like a small
point, but I think it has a big impact on the user's perception.

A user coming to the ipython site first sees that almost everything
about ipython
for the user is contained on one page.  You can find out what it is as
well as how
to download, install, and use it fairly quickly.  You also find a host
of links to other
sites, which contain more information.  I feel that this gives the
user access to the
most important things quickly, but also conveys to the user that these
other sources
of information are not necessary to read in order to get some use from the code.

I think that ipython and nipy would benefit from making the user sites
a little nicer,
but I would argue for keeping both sites visually distinct and very
minimal compared
to the developers sites.  Both ipython and nipy should have more
visually appealing
front pages, which convey a more professional image to users.  The
developer's site,
however, should be in a state of greater flux and have less gloss.

[[The majority of the content for a user's site should be the user's
guide, which should
not be generated using the wiki anyway.  I think user's guide should be written
using docbook (maybe using lyx) with autogenerated html, which can be put on
the website as well as in /usr/share/doc on the user's local machines.]]

I haven't used Moin, but I was imaging that it would be easier for me to update
than pure html, while also providing a more visually pleasing and professional
look.  I was hoping that since Enthought has done most of the work getting
Moin and Trac working together, using both of them together wouldn't
be too bad.  My plan is to keep the Trac site for developers only for now.  As
soon as we get something ready for new developer's to get going fairly easily,
I will talk to Robert about getting the Moin site up.

I also imagine that we will have 2 main types of users: 1) users who
will just want
to run scripts and interact with GUI applications as well as 2) users
who will write
their own scripts, but won't want to make svn commits.  The second
type of user will
find the Trac site more useful in the short-term.  We will not need
too much detail
on the Moin site, until we have enough code developed to be useful to the first
type of user.  So I think that the amount of documentation on the Moin
site will not
grow that quickly.  However the first type of user may also get easily
turned away
from the project, if they feel that they need to access the trac site
to figure out how
to use our code.

Once I start the process of using Moin, I will be in a more informed position to
assess whether maintaining both sites will create too much overhead.
However, it
will be at least a few months until we will have something for the 1st
type of user.  So
I will not be setting up the Moin site for sometime.

> I had to do the same a while back, and just yesterday had to disable
> even anonymous ticket submissions.  The spammers /will/ get you.  Just
> remove all anonymous edit capability of any kind; Robert has a Trac
> plugin to allow non-SVN users to create Trac-only accounts for
> tickets, wiki edits, etc.  It is the only long-term solution.

Excellent, I am glad that Robert has a way to provide accounts without svn
access; I will talk to him about it.

Jarrod