On 10/30/07, Rolf Lampa rolf.lampa@rilnet.com wrote:
Sorry for this long post, but perhaps part of the difficulty so far is
Not at all. I haven't had time to fully read it and reflect, but will do so in about 4 days.
that different concepts, from "different levels of abstraction" makes
it difficult to clear things up. Short version: Redirects is primarily
Right. The reason is that it's much easier to get consensus (or lack thereof) for a real, concrete change. OTOH it's easy to discuss stuff at an abstract level, but nothing ends up becoming of it.
In other words, don't make, in an early stage, any assumptions at all about Redirects' be or not to be, until the use case (from the users perspective) is very well defined, and optionally, till the Redirect concept is very clearly understood, as a very good and generic abstraction useful as a (technical) design concept (in any complex system really).
I have no idea how to go about having a good discussion to solve difficult problems, or to come up with excellent solutions for only moderately difficult discussions. It seems to me that most of the development effort on MediaWiki has come from individuals who themselves have come up with, and then implemented, solutions. Can an email list really suffice for analysing a problem and coming up with a solution?
Therefore, don't confuse Redirects per se, with any good ideas about use cases solving real problems for the editors.
Sure. Redirects are just there already, it's good to look at them to see if they're solving our problems or can be improved.
In reality Redirects handles, under the hood, real problems, as
"freestanding" helpful "guides", which will not go away very easily.
Yep. But I originally started by proposing a mechanism to enhance their use as "guides". We've called this concept "aliases", "synonyms", "hints"...obviously we need something like that. But redirects are obviously not a perfect solution. And as you point out they're trying to solve more than problem at once.
This is because some of the problems it solves stems from the way we
humans function. Example: People tends to not always find the best title for a topic directly. Then, when a better title is found later, someone may already have linked to the first/old title. Then it is convenient to be able to move a page, and automatically leave a (freestanding) Redirect behind as to not break existing links to the old name/title.
There's no obvious reason why the original text couldn't simply be updated, instead of a redirect being created. This often slowly happens anyway, as people or bots replace redirects with their targets.
This use of Redirects simply is a good solution. It solves a real
practical problem, in real use case(s) (both when moving a page, and in continually catching the now "bad links" in the system). It's just a charmingly good solution.
It's charmingly good in the way a 7 year old who can play violin is charmingly good. I'd still rather listen to a real virtuouso. It was easy to implement, it's conceptually simple...but why stop there?
The Redirect concept actually abstracts a very basic concept in any
complex system. The point is that basic concepts implies "useful for many things", which is exactly what *designers* look for when they search for or design their tools for solving things. And in such a complex web of information as WP really is, don't remove redirects,
I don't think I've ever suggested "removing redirects". I've suggested replacing actual physical implement redirects, but the mechanism should live on, I think.
because Redirect is a tool, a technical good "meta solution" to more
than one problem. But such (technical) design tools are not necessarily best exposed "naked" to the users (which currently is the case with the present Redirect solution).
Yep.
So what I am saying is that whether, and how, Redirects are exposed to
the users, is quite another matter. You usually do NOT expose abstract "meta solutions" to end users of a system.
MediaWiki will always operate this way though. It sort of has to. It's so general purpose it's pretty hard to really hide the implementation details with some sort of abstraction layer. Maybe individual sites could do that, but I don't see how the software could generally do that. Though I would like it if it tried ;)
discussed at the same time. But the technical implementation must not
be confused with the essence of the Use Case! Well designed systems
Yes, you have repeated this point several times. Can you offer some more concrete guidance? Believe it or not, I have studied requirements analysis, and I have some understanding of use cases. I'm skeptical about the chances of performing a genuine use case -> specification -> design -> implementation lifecycle on a product like this though. Especially by email. :) So perhaps if you have some good ideas, you could state them directly.
The only "problem" with redirects may well turn out to be that they are exposed to the users (!),
Don't forget that MediaWiki really doesn't distinguish between the obvious types of users: readers and editors. That's in the nature of the wiki. I don't think it's conceivable to truly "hide" information from the user.
After having a concrete (Use Case kind of) specification of the need and functionality of the feature, it will also become easier to pick, or develop, the best technical implementation for just that well defined feature.
This would be a nice process if we were starting from scratch. But realistically, if we come up with an awesome solution to the general problem, that requires masses of new code, it's just not going to happen. We need to focus on what smallish changes we could implement that would cause great benefit. Especially given how many other people are going to have to need to get involved to make it happen.
Steve