Aloha ;) > @@Tabellenkalk > > > > Wie kann man den die Code-Beispiele bearbeiten? > > > > > > > Ich glaube, wegen Vandalismusprävention benötigt man dafür spezielle Scharwies- bzw. Apsel-Rechte. > > Was absurd wäre. Naja, so speziell sind die Rechte nicht - bei Nachfrage werden sie ja auch im Normalfall erteilt. Gründe dafür, das nicht noch offener zu handhaben hat @Matthias Apsel [schon genannt](https://forum.selfhtml.org/meta/2017/mar/18/selfhtml-wiki-letter-spacing-nur-fuer-bestimmte-werte-empfaenglich/1690405#m1690405). Andererseits ist es so, dass gewisse fleißige Heinzelmännchen sowieso ein Auge auf die Änderungshistorie der Artikel haben und im Zweifel (oder spätestens dann, wenn man ihnen eine Notiz hinterlässt) die Änderungen im Beispiel-Code auch ins statische Beispiel übertragen. Gerade bei gelegentlichen Änderungen durch Einmal-Bearbeiter ist das ein gut funktionierender Mechanismus. > Vielleicht sollte man das mit dem selbstgefrickelten Frickler sein lassen und Beispiele von CodePen einbetten? Das löst die Vandalismus-Problematik auch nicht, genauso wenig wie ein Sichtungs-Mechanismus. Bei einem Sichtungs-Mechanismus muss ein Admin drüberschauen und die Änderungen akeptieren oder entsprechend den Richtlinien anpassen - das ist in etwa der gleiche Aufwand wie die Änderung im Beispiel-Code zu registrieren und mit dem statischen Beispiel zu synchronisieren. Und manche bekannte Autoren würden eben ein automatisches-Sichtungsrecht bekommen, was im Moment dem Beispiel-Admin-Status gleichkommt. Bei CodePen-Einbettungen muss die manuelle Überprüfung genauso stattfinden. Gleichzeitig setzen wir dabei auf einen externen Dienst, dem sowohl unsere Nutzer (externer Seitenzugriff) als auch wir (keine Kontrolle über Verfügbarkeit) als auch unsere Autoren (Rechteabtretung nicht nur an uns, sondern auch an Codepen) vertrauen müssen und können nur dann Vandalismus *verhindern* wenn ein zusätzlicher Sichtungs-Mechanismus greift, der wieder wie gesagt keinen Vorteil zur bisherigen Lösung bietet. Wenn man das mit *CodePen vs. Frickle* mal außen vor lässt (und ich glaube zu spüren, dass es dabei vor allem darum ging, einen Nebenkriegsschauplatz zu eröffnen - nix für ungut) reduziert sich die Frage also auf *Sichtungsmechanismus vs. bisherige Lösung* und da gibt es aus meiner Sicht keinerlei Blumentöpfe zu gewinnen. Grüße, RIDER -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller # [Twitter](https://twitter.com/Camping_RIDER) # [Steam](http://steamcommunity.com/id/Camping_RIDER) # [YouTube](https://www.youtube.com/user/RidersFlame) # [Self-Wiki](http://wiki.selfhtml.org/wiki/Benutzer:Camping_RIDER) # [Selfcode](http://community.de.selfhtml.org/fanprojekte/selfcode.htm): sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[

Aloha ;) > @@Tabellenkalk > > > > Wie kann man den die Code-Beispiele bearbeiten? > > > > > > > Ich glaube, wegen Vandalismusprävention benötigt man dafür spezielle Scharwies- bzw. Apsel-Rechte. > > Was absurd wäre. Naja, so speziell sind die Rechte nicht - bei Nachfrage werden sie ja auch im Normalfall erteilt. Gründe dafür, das nicht noch offener zu handhaben hat @Matthias Apsel [schon genannt](https://forum.selfhtml.org/meta/2017/mar/18/selfhtml-wiki-letter-spacing-nur-fuer-bestimmte-werte-empfaenglich/1690405#m1690405). Andererseits ist es so, dass gewisse fleißige Heinzelmännchen sowieso ein Auge auf die Änderungshistorie der Artikel haben und im Zweifel (oder spätestens dann, wenn man ihnen eine Notiz hinterlässt) die Änderungen im Beispiel-Code auch ins statische Beispiel übertragen. Gerade bei gelegentlichen Änderungen durch Einmal-Bearbeiter ist das ein gut funktionierender Mechanismus. > Vielleicht sollte man das mit dem selbstgefrickelten Frickler sein lassen und Beispiele von CodePen einbetten? Das löst die Vandalismus-Problematik auch nicht, genauso wenig wie ein Sichtungs-Mechanismus. Bei einem Sichtungs-Mechanismus muss ein Admin drüberschauen und die Änderungen akeptieren oder entsprechend den Richtlinien anpassen - das ist in etwa der gleiche Aufwand wie die Änderung im Beispiel-Code zu registrieren und mit dem statischen Beispiel zu synchronisieren. Und manche bekannte Autoren würden eben ein automatisches-Sichtungsrecht bekommen, was im Moment dem Beispiel-Admin-Status gleichkommt. Bei CodePen-Einbettungen muss die manuelle Überprüfung genauso stattfinden. Gleichzeitig setzen wir dabei auf einen externen Dienst, dem sowohl unsere Nutzer (externer Seitenzugriff) als auch wir (keine Kontrolle über Verfügbarkeit) als auch unsere Autoren (Rechteabtretung nicht nur an uns, sondern auch an Codepen) vertrauen müssen und können nur dann Vandalismus *verhindern* wenn ein zusätzlicher Sichtungs-Mechanismus greift, der wieder wie gesagt keinen Vorteil zur bisherigen Lösung bietet. Wenn man das mit *CodePen vs. Frickle* mal außen vor lässt (und ich glaube zu spüren, dass es dabei vor allem darum ging, einen Nebenkriegsschauplatz zu eröffnen - nix für ungut) reduziert sich die Frage also auf *Sichtungsmechanismus vs. bisherige Lösung* und da gibt es keinerlei Blumentöpfe zu gewinnen. Grüße, RIDER -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller # [Twitter](https://twitter.com/Camping_RIDER) # [Steam](http://steamcommunity.com/id/Camping_RIDER) # [YouTube](https://www.youtube.com/user/RidersFlame) # [Self-Wiki](http://wiki.selfhtml.org/wiki/Benutzer:Camping_RIDER) # [Selfcode](http://community.de.selfhtml.org/fanprojekte/selfcode.htm): sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[