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

Bill Page wrote:
> 
> On 11/1/07, Waldek Hebisch wrote:
> >
> > Bill, I must admit that I have doubts concerning your migration
> > tactic. 
> 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.
>

We are using different terminology here: for me people visiting the
site are users.  But I do not want discuss names here.  For me
important point of wiki is that content may be viewed by large
number of visitors.  And I belive that you want visitors to go
to the new 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.

You wrote about obsolete pages: to find out if a page is obsolete
you need to read it.  And my impression is that 100% obsolete
pages are rare, rather part of a page is obsolete.  So to
eliminate obsolete pages and/or improve content you need
proofreading.

However below you explain that you just want mechanical copy...

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

OK, so we have easy way to grab sources of all pages from the old
site.

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

This sound like work for Perl WW::Mechanize module.  However, since
you have direct access to the machine there should be easier way
to submit pages.  Note: I never used Mechanize module.  Since
I may need it for other purposes I am willing to try mass upload
using it (assuming you have no easier way).

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

Yesterday contents page of the new site contained 74 positions,
while contens page of old site had 913 positions -- that is large
difference.
 
> > 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.
>

I have no experience with Zwiki.  But I would be very disappointed if
Zwiki does not allow easy batch import from external source.

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

Yes.

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

I think it is important to store _exactly_ the report: frequently
little details does not mater, but sometimes give very important
clue.  I saw report which looked like somebody later edited them
and reports were it was hard to distinguish what original reporter
wrote and what later folks added.  Which means that in _all_
cases there is danger that report was changed.  I guess one can
trace history of the page to check this, but it seems much
simpler to use append-only mode.
 
Concering metadata: there is a lot of bogus metadata in current
IssueTracker.  Part may be due to simple errors, but it seems
that wandals frequently change metadata.  I would say that
anuthorised people have no business changing metadata and
that maintaining metadata is less work than correctiong wrong
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 that means that I would have to edit original report.  Beside
extra effort I would like to keep original report "as is".

BTW:  I _definitely_ prefer to store output of orignal report to
recreating it on page change.  Note that storing output avoids
all tricky issues with changing versions.

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

I _use_ "text terminal" -- that is just personal preference.

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

I have no experience with Trac.  I really have no strong preference
for specific software.  I mentioned Bugzilla because it is known
and works "good enough".  I belive that changing IssueTracker in
specific aspect I mentioned would not be very hard.  So, now
it is mostly question what other versions want.

-- 
                              Waldek Hebisch
hebisch-o02PS0xoJP/[email protected] 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/