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 [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/ _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
