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

[Bill Page]

On 11/1/07, Waldek Hebisch wrote:
>
> Bill Page wrote:
> ...
> > new sites now. They can be found at:
> >
> >     http://axiom-wiki.newsynthesis.org
> >
> > and
> >
> >     http://axiom-portal.newsynthesis.org
> >
> ...
> 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.
>

Waldek, I very much appreciate your taking the time to comment. I also
have doubts as I will explain below. But I would state my own goals
with respect to the migration somewhat differently:

 Primary goal 1: Support all versions/forks of Axiom at one website
 Primary goal 2: Reduce the operating costs of the axiom-developer.org website
 Secondary goal 1: update software
 Secondary goal 2: migrate critical and selected content

The first three goals are well served by re-installing the web
applications at another site.
Notice I do not mention either updating content or migrating users.

> 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.
>

I think we should be quite honest: There are very few users. Only
about 3 or 4 people have ever made any effort to actually use the web
site in the way it was intended - as a wiki, a community maintained
web site. I do not think there will be any problem convincing these
same people to continue to contribute to the new site.

On the other hand, from the log statistics we can see that the Axiom
wiki website does have quite a large number of visits by people who
want only to read something about Axiom and is also very actively
crawled by the major search engines. From my point of view, I think
the partial content that I have already copied from the old site to
the new is sufficient to sustain this sort of use of the site.

> 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.

I do not understand your comment about proofreading. I suspect that
probably my reference to cut-and-paste was not very clear and that you
probably are not very familiar with how the content of the Axiom is
created and maintained. Cut-and-paste is simple. It involves only a
few steps and the entire content of a page is transferred and
re-created in essential one step by clicking Save.

Here is what I was hoping that you would do:

When you looked at the AxiomContributions page and noticed that some
apparently useful content was missing you could have added it with
less than 30 seconds effort. For example in detail:

1) At the new site

   http://axiom-wiki.newsynthesis.org/AxiomContributions

2) You see

  [CommonDenominator for polynomials]?

  where you would like to see a link to this web page that existed on
the old site.

3) Click on the blue ? to begin (re-)creating the page.

4) Open the source for this page at the old site in a separate browser window

  http://wiki.axiom-developer.org/CommonDenominatorForPolynomials/src

  Notice /src at the end of the url and also the rule of removing
blanks and capitalizing the first letter of each word.

5) Click Edit/Select All, Edit/Copy

6) Place the cursor in textbox in the page creation form and click
Edit/Paste to move the enter text of the page

7) Click the 'Create' button to render the new page. The link on the
AxiomContributions has been automatically updated.

Maybe during this process you notice that something is out of date so,
now you might continue by clicking 'edit' (upper right corner of page)
and make the correction.

> However,  it seems that creating current content took about 3 years.

I think a lot of this content is of out of date and no longer
interesting. I would prefer to place the emphasis on generating new
content and updating the old (if still relevant).

>  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.
>

What is the purpose of proof-reading? Keep in mind that this is a
*wiki* web site. The content can be edited by anyone at any time and
this use is strongly *encouraged*. Editing and extending the content
is an ongoing process.

> 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".

A wiki web site is never "complete". It is there to be changed,
updated and extended as time and motivation allow.

> 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.
>

We can easily disable updates to the old site and direct the user to
the new site in the resulting error message page.

> I would suggest to migrate content as much as possible in automatic
> way.

Because of the change in the underlying software I do not know any
easy way to accomplish this sort of automatic migration for the Axiom
wiki site. I have already done as much automatic migration to the
Axiom portal site as possible using the ZSyncer tool. If you have some
ideas about how to do more automatic migration I would be very
interested in this.

> Once the new site is fully functional I would made first
> stage of transition:

I do not know what you mean by "fully functional" except if you refer
to content as we discussed above. Other than that, I think the new
site is (almost) fully functional as a wiki and as a portal. The only
missing part right now that I know about as I mentioned in my previous
email is support for Aldor.

> -- put prominent notice about new site on the front page of
>    the old site

That is done now.

> -- change old site to read-only and display notice about new
>    site on any attempt to edit

I can do that today if everyone agrees that is the right approach.

> -- redirect all links to the new site.
>

I think this would be inconvenient. The old site must remain
accessible for some period of to allow content to be transferred.

> 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.
>

I do not think we have the luxury of spending this much time and using
this sort of more structured approach.

> 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.

I do not know what is the required "critical mass" of links or users.
So far as I can see we have never reached this "critical mass" stage
in either links or users yet even on the old site.

> Making old site read-only should avoid problems with
> synchronization.

Yes, but I do not expect the sites to every be anything except
approximately synchronized.

> 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.
>

I think eventually redirecting links is definitely a good idea once
the old site is no longer accessible at all. In fact I can tell from
the web logs of the new site that the search engines have already
noticed and started to crawl the new site. They are very agressive
these days.

> 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.
>

As I explained above, I think that this is quite normal for a wiki-based site.

> ...
> FriCAS also has a bug tracker at SourceForge.  As a person reading
> bug reports I find bugzilla format preferable compared to current
> IssueTracker format.

Of course I have no problem if you chose that as the preferred method
of reporting bugs for FriCAS.

>  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)

Why do you think that is important? Do you expect such changes?

> -- IssueTracker shows Axiom output as images which is unsearchable,
>    does not work on text terminal and may hide some important
>    information
>

If desired Axiom output can be displayed in text form by including the commands:

)set output tex off
)set output algebra on

But I do not understand why you would wish to use a "text terminal".

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

Agreed but transferring them is a problem.

> 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...
>

There are many good alternatives when it comes to bug tracking. For
example the Sage project is using the Trac system.

http://trac.edgewall.org

that includes it's own integrated wiki and interface to subversion.

Do you think we should try to operate something like this as a common
bug tracker for all the Axiom versions/forks?

Regards,
Bill Page.