[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Re: [fricas-devel] Re: Axiom Wiki and Portal are movin
[Axiom-developer] Re: [fricas-devel] Re: Axiom Wiki and Portal are moving
Sat, 3 Nov 2007 18:27:22 +0100 (CET)
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
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
> 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
> 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
> 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
> > 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.
> > 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
> > -- 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
> )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.
> 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.
[Axiom-developer] Re: [Axiom-mail] Axiom Wiki and Portal are moving, Gabriel Dos Reis, 2007/11/01
[Axiom-developer] Re: [fricas-devel] Axiom Wiki and Portal are moving, Waldek Hebisch, 2007/11/01