Mailinglist Archive: opensuse (963 mails)

< Previous Next >
[opensuse] Re: [opensuse-wiki] Re: broken link
On 4/5/2011 1:15 PM, Malcolm wrote:
On Tue, 2011-04-05 at 13:01 -0400, Brian K. White wrote:
google: "insserv_cleanup"

Top/First link, and in fact most of the whole first PAGE of results, is:

Which refers to:

Which doesn't exist.

Sure the referrer is a mail list thread which should be considered

That doesn't change the fact that almost the whole first page of google
results for a basic term are broken.

We all know that these links are broken since the wiki changes....

You can always add the old, or go to the proper place

or go to the proper place

I always go here now;

You might also want to use which is very

Missing the point? Or just ignoring it?

Of course we all know the links are broken and why.
Of course we all know there are other ways to get the info.
Of course it's old news.

But being old news does not make the problem go away. It's still bad today despite being old news. Every new day it's bad all over again just like the first day.
I'm sorry it's annoying to keep hearing the same complaint, but everyone else suffers the breakage anew every day so why shouldn't the breakers suffer the complaint anew every day as long as their damage keeps being a problem? It's not like this was some natural disaster or accident. It was an conscious and voluntary act. But forget me, the breakage hurts SUSE anew every day rather a lot more than myself or any single user. Countless broken links with suse's name on them do not make a good impression to people searching for answers to problems and finding only a broken link, when they are already in a poor state of mind from whatever the problem is they were having that sent them googling for answers.

The point is that the people that broke everything don't seem to think that this is somehow bad. They say "gee just report the breaks".

I say that's completely stupid, but ok fine here is yet another one.

There are not merely many, but literally countless, as in there is no way to count them, and far too scattered for that to be even remotely possible. You can't find all the references to the old wiki that have been put into other documents in the world. We're not just talking other web pages but countless internal company documents, printed books and hard copies, personal notes and scripts and install media and livecd's and programs and support db's ...

There was and still is a way for users to help fix everything, but it's not useful as there there is no way to know what needs to be fixed. It's an open ended forever job with no way to know when you're done. They pulled the trigger and switched more or less at random, after the new wiki had been up "a while" and "a lot" of stuff had been remapped, and "not many" or "no major" reports of gaps. All nice subjective meaningless terms in place of useful quanta.

But a couple things ARE possible.

It IS possible to know what are all the urls the old wiki provides and ensure they all work in some fashion before switching. A big job but a finite and knowable one and the largest part of which can be farmed out to users. The wiki admins can write and run a program to trawl the old wiki db and associated web pages and cgi's and compile a list of all possible old urls. Users and admins can then all work on that list until it's gone.

Even easier than that, why isn't the 404 page simply trying old-en on the fly for every request that doesn't exist in the new wiki? It could try swapping in old-en, and if the result exists and isn't old-en's 404, then transparently serve up the old-en page and log the discovery in a bugzilla or or other db that not only admins but users could work on. It could even keep a hit counter for each miss/hit so you'd know which articles to fix first. As a natural by-product that would also have the appearance of fixing all the internal links within the old wiki too as well as external ones.

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >
This Thread
  • No further messages