[Axiom-developer] Re: [fricas-devel] Axiom Wiki and Portal are moving

[Waldek Hebisch]

Bill Page wrote:
> 
> Dear Axiom Users and Developers;
> 
> Earlier in October Tim Daly asked me if I would be able to move the Axiom 
> wiki:
> 
>     http://wiki.axiom-developer.org
> 
> and the Axiom portal:
> 
>     http://portal.axiom-developer.org
> 
> web applications to a new server.

> In spite of this and in view of Tim's desire to complete the move as
> soon as possible, I would like to invite everyone to begin using the
> new sites now. They can be found at:
> 
>     http://axiom-wiki.newsynthesis.org
> 
> and
> 
>     http://axiom-portal.newsynthesis.org
> 

> So I would like to encourage everyone who cares about Axiom (and/or
> it's forks) and who is interested in wiki and portal support for these
> projects to help with testing and re-populating the new sites as soon
> as possible. After three years of operation of the Axiom wiki there
> are a fairly large number of out-dated, poorly organized and possibly
> irrelevant pages which probably should not be simply copied over to
> the new site. I would be very very happy if some other Axiom users and
> developers would agree to assist with this "shifting" and
> re-organizing effort. Copying missing content between the sites can be
> easily done by cutting-and-pasting the text from the 'edit' of the old
> site to the corresponding 'edit' page of the new site.

Bill, I must admit that I have doubts concerning your migration
tactic.  AFAU there are two goals:

1) Primary goal: migrate content and users from the old site
   to the new site.
2) Secondary goal: update software and the content.

As you wrote: Axiom wiki is a comunity site, so migrating users
to the new site is crucial.  But to migrate users it is
essential to migrate content.  I took quick look at the new site
and I see that a large part (most??) of content is missing
-- for example most links on AxiomContributions page does not work
and many positions from the page on the old site are missing.

IIUC you propose to transfer rest of the content via cutting-and-pasting
from the old site.  I think this is problematic: without proofreading
almost any automatic procedure will work better.  You probably hope
that volunteers will proofread the content while copying.  However,
it seems that creating current content took about 3 years.  I would
expect that proofreading the site will take month or two and
proofreaders will be slowed down by the need to copy things --
I am not saying that proofreading itself takes a lot of time,
but simply that our volunteers are in general busy, and can spend
only a short time doing this.

During that time the new site will be more or less broken, so many
users will try to use the old site -- since only old site will
be "complete".  Similarly links will continue to point to the old
site.  Another problem is that users may come to the old place and
add content there -- migrating additions will cause extra trouble.

I would suggest to migrate content as much as possible in automatic
way.  Once the new site is fully functional I would made first
stage of transition:
-- put prominent notice about new site on the front page of
   the old site
-- change old site to read-only and display notice about new
   site on any attempt to edit
-- redirect all links to the new site.

In the next stage (two weeks or maybe month later) I would replace
all pages on the old site by a notice about move and link to
the corresponding page on the new site.  I would handle updates
to the content separately.

Rationalle: without proper action users will continue to come
to the old site: it shows in search engines, it is in bookmarks,
there are links to it.  The first stage is intended to shift
critical mass of links and users to the new site.  To avoid loosing
users old site should be operational.  Making old site read-only
should avoid problems with synchronization.  Redirecting links
should help with search engines and bookmarks -- search engines
should notice new site, new bookmarks to links will point to
the new site.

Concerning update of content: the move may cause some loss of
users.  Operating both sites in paralell is intended to minimize
user loss.  However, it is essential that new site is fully
operational -- otherwise users will go to the old site or we may
loose them.  IMHO trying to update content during migration
slows down migration and causes extra work.


> The most serious missing component at the new Axiom wiki site is the
> existing database of IssueTracker reports. I have tried unsuccessfully
> to copy to the old database to the new server. In any case it is also
> true that a number of these reports may be obsolete or may not apply
> equally to all of the Axiom projects. Also some of the Axiom projects
> (forks) have their own way of tracking problems, e.g. OpenAxiom simply
> uses SourceForge. So I am open to suggestions on how to proceed with
> this transferring this information (and/or comments about whether this
> is really necessary or not).
>

FriCAS also has a bug tracker at SourceForge.  As a person reading
bug reports I find bugzilla format preferable compared to current
IssueTracker format.  More precisely:
-- bugzilla is more restrictive when comes to edits, for example
   for normal users is append-only and does not allow unautorized
   changes to metadata (bug classification)
-- IssueTracker shows Axiom output as images which is unsearchable,
   does not work on text terminal and may hide some important
   information 


However, I feel that access to old reports is important, so I certainly
would like to see old reports at the new site.

I belive that common bug tracker for all Axiom forks would be good.
In the past Tim said that he does not want FriCAS bugs in Axiom bug
tracker, so FriCAS bug tracker was created.  Certainly, common
bug tracker make sense only if one can restrict view so that
only bugs reported against given fork are visible.  Technically,
this should be not a problem...


-- 
                              Waldek Hebisch
address@hidden