[Wikide-l] Re: mediawiki-bausteine als navigationselemente

Sa Feb 28 21:06:48 UTC 2004

> Ein paar Highlights von Uli:
>
> 	"Ich werde diese Dinger gnadenlos löschen, wenn sie mir in die
> 	 Finger kommen, da könnt Ihr abstimmen, so viel ihr wollt."
>
> 	"Was das Löschen angeht: Das ist keine Drohung, ich hab die
> 	 fraglichen Bausteine eben gelöscht."

Sorry, aber mein Job als Admin ist, die Enzyklopädie auf der Linie 
"Enzyklopädie, die Wissen strukturiert verfügbar machen soll" zu halten. Wenn 
wir uns mal umdefinieren in "Sauhaufen, bei dem jeder jederzeit in bewährten 
und von vielen Leuten abgestimmten Strukturen rumpfuschen darf, ohne vorher 
wenigstens ein Minimum an Konsens herzustellen" werde ich mein Verhalten 
gerne ändern. Bis dahin seh ich sowas als Vandalismus an, und den haben wir 
noch nie auf den Löschkandidaten gelistet.

> 	"Arbiträre Abstimmungen interessieren mich nicht"

Du sollst meine Zitate nicht aus dem Zusammenhang reißen. Es ging da um eine 
10:11 "Abstimmung", die als finales "Ergebnis" dargestellt wurde  - frag mal 
Jimmy, was er von Abstimmungen hält.

>
> Hinzu kommen dann noch ähnliche Ausführungen in diesem Thread. Ich kann
> nur wiederholen, daß mir schleierhaft ist, wie so jemand an Sysop-Rechte
> kommt.

Glaub mir, mir ist manchmal schleierhaft, warum ich sie eigentlich immer noch 
behalten hab. Vielleicht kommt ja am Ende bei meinem Berserkertum doch immer 
sowas wie ein Fortschritt raus. Hast Du Dir schonmal überlegt, wie 
Web-Communities funktionieren?

>
> Am Fuß der Seite scheint er jetzt endlich mit seiner mirakulösen Idee,
> wie das Feature seiner Meinung nach auszusehen hat, rausgerückt zu
> haben. Die Idee ist an sich nicht schlecht, aber IMHO extrem Overkill,
> extrem zeitaufwendig zu programmieren, und bringt wenig zusätzlichen
> Nutzen gegenüber der existieren Funktion.

Na, so mirakulös war sie nie gewesen. Es hat nur nie jemand danach gefragt. 
Wir haben mal wieder ein typisches EDV-Problem: Benutzer, die nicht wissen, 
was sie eigentlich brauchen, und Entwickler, die raten, was die Benutzer wohl 
brauchen könnten und mal einfach drauf los programmieren, aber nicht 
verstehen, was wirklich benötigt wird, weil sie zu wenig von der Sphäre der 
benutzer verstehen.

Die Lösung ist kein Overkill, weil sie ein paar Probleme auf einmal lösen 
würde, die wir gegenwärtig haben (nicht nur eins). Im Gegenteil, sie ist eine 
Minimallösung, weil sie eigentlich mit dem Thema "Kategorisierung von 
Artikeln" in Zusammenhang zu sehen ist. Aber sie ist halbwegs zukunftssicher 
und wachstumsfähig, und ich glaube, dass man sie mit einer wie auch immer 
gearteten Kategorisierungslösung einfach in Einklang bekommt. Ich gebe zu, 
dass sie Implementierungszeit erfordert. Aber sie wäre sauber. Die msg: 
-Lösung ist das nicht - sie ist ein klassischer Hack: Schnell zu 
implementieren, aber unsauber. Das Problem ist, dass, je mehr solcher Hacks 
man einbaust, jede neue Änderung schwieriger wird. Es entsteht klassischer 
unwartbarer Spaghetti-Code, den Du in drei Jahren nur wegwerfen und neu 
machen kannst. Die Lösung ist unter anderem bereits deshalb aufwändiger zu 
implementieren, weil die Software schon jetzt recht unmodular ist, soweit ich 
das auf die Schnelle gesehen hab.

Nochmal: Ich plädiere nicht für Overkill (dann würde ich Dir eine Meta-Syntax 
spezifieren, mit denen die Anwender definieren könnten, wie die Software die 
einzelnen Bausteinarten rendern sollte etc.) - Overkilll ist etwas, das das 
aktuelle Problem *zu* gut löst, und zwar mit Features, die keiner braucht. 
Das was ich aufgeschrieben habe, ist das, was die "Enzyklopädisten" von den 
"Entwicklern" im Moment *brauchen* - alles dunter ist zu wenig (dann fangen 
die Enzyklopädisten mit Hacks an), alles drüber ist Overkill.

Uli