Benutzer Diskussion:AKlapper (WMF)
SUL-Finalisierung
Hallo Andre, da du noch nicht begrüßt wurdest: Willkommen in der Wikipedia!
Da du laut Benutzerseite für Bugs zuständig bist und Jan gerade nicht online ist, kannst du dir eventuell dies mal ansehen und etwas dazu schreiben? Das Umbenennen ist eine Krücke, zu der es seit Jahren unbearbeitete Bugs gibt, um die sich die WMF nicht kümmert, siehe bei Bugzilla. Warum ist das so? Und wird es nach der SUL-Finalisierung weiterhin möglich sein, dass sich neue Benutzer mit dem alten Namen umbenannter Benutzer anmelden können, weil die Namen nicht nach Umbenennungen automatisch gesperrt werden? Dann wären es automatisch neue globale Konten, was noch größeres Chaos ergeben würde als jetzt bereits, siehe Beispiel. Laut der Hilfeseite findet die SUL-Finalisierung im August statt, also in den nächsten 8 Tagen, stimmt das noch oder wurde es weiter verschoben? Grüße --Typokorrektör (Diskussion) 10:57, 23. Aug. 2013 (CEST)
- Heja Typokorrektör, Link zur Hilfeseite der SUL-Finalisierung ist sehr willkommen, und woher das Augustdatum kommt. Ich scheitere daran irgendwelche konkreten Daten auf https://meta.wikimedia.org/wiki/Single_User_Login_finalisation_announcement oder https://meta.wikimedia.org/wiki/Help:Unified_login zu finden, allerdings listet https://wikitech.wikimedia.org/wiki/Deployments#Near_term nichts dergleichen fuer die naechste Woche. Ich habe mal in bugzilla:35707 gefragt. Falls Du bestimmte unbearbeitete Bugs im Kopf hast die Du als kritisch empfindest, waere ich sehr interessiert an den Bugnummern. Und bezueglich der Frage zur moeglichen Erzeugung neuer globaler Konten stecke nicht tief genug in der Materie als dass ich Details zur Implementierung geben koennte, sorry... --AKlapper (WMF) (Diskussion) 11:37, 23. Aug. 2013 (CEST)
- Ok, also wurde es verschoben. Bis Mitte August stand hier auch noch August, sehe ich gerade. Also wird es eventuell irgendwo eine Mitteilung gegeben haben, dies wurde aber auf der hiesigen Hilfeseite nicht aktualisiert. Du kannst ja MZMcBride fragen, woher er das hat. Aber auch hier steht „[August]: Removal of renameuser right from bureaucrat user groups and other changes for SUL finalisation“ und auch „Global RenameUser tool“. Was bedeutet denn „TBD“? Und wissen die Bürokraten auch, dass ihnen noch in diesem Monat das Umbenennungsrecht entzogen werden soll? Es ist nirgends aktuell etwas dazu zu lesen. :( Fällt das wieder unter das Kommunikationsdefizit oder was bedeutet das?
- Vielleicht kann man herausfinden, was mit den alten SUL-Namen nach der Umbenennung geschehen wird? --Typokorrektör (Diskussion) 12:50, 23. Aug. 2013 (CEST)
- "TBD" steht fuer "to be defined", also "noch festzulegen". --AKlapper (WMF) (Diskussion) 14:22, 23. Aug. 2013 (CEST)
- So etwas sollte besser allgemeinverständlich ausgeschrieben werden, damit das auch Nicht-Muttersprachler verstehen können. Allgemein besser weniger unverständliche Abkürzungen verwenden. --Typokorrektör (Diskussion) 15:12, 23. Aug. 2013 (CEST)
- Wir Bürokraten wissen schon seit einiger Zeit davon, es wäre aber unsinnig, uns die Umbenennungsrechte zu entziehen, wenn weder das Global Rename Tool noch die SUL-Finalisierung fertiggestellt sind. Das wird sich denke ich analog dem Finalisierungsprozess nach hinten verschieben. Ansonsten weiß ich auch nicht mehr, aber für gewisse Fälle ist es sicherlich sinnvoll, das spätere Anlegen eines neuen Kontos mit demselben Namen automatisch zu blockieren. IW 13:03, 23. Aug. 2013 (CEST)
- Ist das nicht fast immer sinnvoll, wenn es nicht um SUL-Zusammenführungen geht, sondern nur um eine einfache Namensänderung? --Typokorrektör (Diskussion) 13:17, 23. Aug. 2013 (CEST)
- Da ist die Frage zuerst, wie man so eine Blockierung lösen möchte. Wenn automatisch in jedem Wiki ein neues Konto angelegt wird, wäre das zum Beispiel bei beleidigenden Benutzernamen nicht sinnvoll, da dann ja wieder Logbucheinträge erscheinen. Wenn allerdings eine Art interne Blacklist mit umbenannten Benutzernamen angelegt wird, wäre diese Art der Blockierung sinnvoll. Möglich wäre auch, dass man andere Benutzernamen übernimmt (z.B. Klarnamenskonten bei Idenditätsdiebstahl) und dort auf automatische Blockierung verzichten muss. IW 13:23, 23. Aug. 2013 (CEST)
- Ja, aber die meisten Umbenennungen finden nicht wegen Identitätsdiebstahl statt, da werden die Konten meistens nur gesperrt. Und beleidigende Namen sollen auch nicht umbenannt, sondern gesperrt werden, und evtl. werden die Namen dann noch unsichtbar gemacht. Die meisten Umbenennungen sind normale Namensänderungen auf eigenen Antrag hin. --Typokorrektör (Diskussion) 13:40, 23. Aug. 2013 (CEST)
- Sicher sind die meisten Anträge völlig unproblematisch. Wikipedia:Benutzernamen ändern/Zwangsumbenennung bekommt ab und zu mal ein paar Fälle, bei denen zwangsweise umbenannt werden muss, und da ist ein neues SUL-Konto mit dem gleichen Namen eher suboptimal. Der Königsweg wäre hier wahrscheinlich wirklich eine nicht-öffentliche Blacklist, vor allem auch, um tausendfach „leere“ SUL-Konten zu vermeiden. IW 13:44, 23. Aug. 2013 (CEST)
- Dann kann man die Namen alle in die MediaWiki:Titleblacklist eintragen. So wäre es nur noch Admins möglich, sie neu zu erstellen. Da es nicht um beleidigende Namen geht, sondern nur um normale Umbenennungen, braucht das auch nicht nicht-öffentlich zu sein. --Typokorrektör (Diskussion) 14:07, 23. Aug. 2013 (CEST)
- Nach der SUL-Finalisierung müssten Stewards dann eventuell die Namen immer einzeln in Meta:Title blacklist eintragen, wenn die WMF dafür nicht doch eine bessere technische Lösung findet. --Typokorrektör (Diskussion) 14:11, 23. Aug. 2013 (CEST)
- Na ja, lauter Einzelfälle aufzuzählen, ist eigentlich nicht Sinn der Titelblacklist. Da müsste dann schon etwas anderes her, mit dem sich das Anmelden unter zwangsumbenannten Benutzernamen verhindern ließe. Wie ich gehört habe, soll es auch eine neue globale Benutzergruppe geben, die Umbenennungen tätigen kann. Die Stewards müssten also nicht alles allein machen. IW 14:14, 23. Aug. 2013 (CEST)
- Das klingt sinnvoll. Kontoneuanlage umbenannter Konten sollte dann nur noch diesen und eventuell auch den lokalen Bürokraten möglich sein. So wäre in Einzelfällen eine Neuanlage oder Umbenennung auf ein solches Konto möglich. --Typokorrektör (Diskussion) 15:12, 23. Aug. 2013 (CEST)
- Na ja, lauter Einzelfälle aufzuzählen, ist eigentlich nicht Sinn der Titelblacklist. Da müsste dann schon etwas anderes her, mit dem sich das Anmelden unter zwangsumbenannten Benutzernamen verhindern ließe. Wie ich gehört habe, soll es auch eine neue globale Benutzergruppe geben, die Umbenennungen tätigen kann. Die Stewards müssten also nicht alles allein machen. IW 14:14, 23. Aug. 2013 (CEST)
- Sicher sind die meisten Anträge völlig unproblematisch. Wikipedia:Benutzernamen ändern/Zwangsumbenennung bekommt ab und zu mal ein paar Fälle, bei denen zwangsweise umbenannt werden muss, und da ist ein neues SUL-Konto mit dem gleichen Namen eher suboptimal. Der Königsweg wäre hier wahrscheinlich wirklich eine nicht-öffentliche Blacklist, vor allem auch, um tausendfach „leere“ SUL-Konten zu vermeiden. IW 13:44, 23. Aug. 2013 (CEST)
- Ja, aber die meisten Umbenennungen finden nicht wegen Identitätsdiebstahl statt, da werden die Konten meistens nur gesperrt. Und beleidigende Namen sollen auch nicht umbenannt, sondern gesperrt werden, und evtl. werden die Namen dann noch unsichtbar gemacht. Die meisten Umbenennungen sind normale Namensänderungen auf eigenen Antrag hin. --Typokorrektör (Diskussion) 13:40, 23. Aug. 2013 (CEST)
- Da ist die Frage zuerst, wie man so eine Blockierung lösen möchte. Wenn automatisch in jedem Wiki ein neues Konto angelegt wird, wäre das zum Beispiel bei beleidigenden Benutzernamen nicht sinnvoll, da dann ja wieder Logbucheinträge erscheinen. Wenn allerdings eine Art interne Blacklist mit umbenannten Benutzernamen angelegt wird, wäre diese Art der Blockierung sinnvoll. Möglich wäre auch, dass man andere Benutzernamen übernimmt (z.B. Klarnamenskonten bei Idenditätsdiebstahl) und dort auf automatische Blockierung verzichten muss. IW 13:23, 23. Aug. 2013 (CEST)
- Ist das nicht fast immer sinnvoll, wenn es nicht um SUL-Zusammenführungen geht, sondern nur um eine einfache Namensänderung? --Typokorrektör (Diskussion) 13:17, 23. Aug. 2013 (CEST)
Bugzilla und normale Autoren
Hallo,
ich habe gesehen, dass du in der letzten Zeit mehrfach versucht hast, normale Autoren auf Bugzilla zu bugzieren.
- Das ist grundsätzlich nett, hier im deutschsprachigen Wiki als Entwickler aufzutreten.
- Erfahrungsgemäß wird das aber so nicht funktionieren, weil Bugzilla für nicht-englischsprachige Non-Techies allenfalls lesend zu ertragen ist, aber nicht schreibend und schon gar keine Neuerstellung.
- Jüngste Bemerkung eines fortgeschrittenen Halb-Techies.
- Anmeldeprozedur? E-Mail? Nö.
- Neuen Bug anlegen? Core, extension, priority, assign, product, hääääääääääääh?
- English? It goes so, but how hots this technic?
- Jahrelange Erfahrung zeigt, dass das einfach nichts wird.
- Hier übernimmt die Technik-Werkstatt die Vorklärung und führt in deutscher Sprache den Dialog mit den Meldenden; reproduziert, sammelt die Details zur Situation, Rückfragen. Auch erstmal nach dup suchen.
- Schon auf freier deutschsprachiger Disku bekommen normale Autoren es oft nicht hin, im ersten Anlauf ihr Problem mitsamt den erforderlichen Einzelheiten zu beschreiben.
- Wenn du hier deutschsprachig mitwirken möchtest, ist das sehr willkommen. Ein Standardtext mit dem Wunsch, der meldende Autor möge doch einen Bug aufmachen, geht allerdings ins Leere.
- Help:Bugzilla würde bereits den gleichen Hinweis geben.
- Lieber Problemfälle auf die Technik-Werkstatt lenken, und dort deutschsprachig mit den nichttechnischen Autoren die Details präzisieren. Weitere Techies bekommen den Thread mit und können reproduzieren, dann selber professionell den Bug aufmachen, und die überall verstreuten Diskussionsabschnitte liegen dort schließlich auch gebündelt im Archiv.
- Zu jedem Haupt-Produkt sollte eine normale Talk page auf MediaWiki gehören, wie es sie in vielen Fällen auch schon gibt; von mir aus dann auch mit Flow statt LT, und notfalls mit Unterseite
/de
. Schlimm genug, dass sie sich bislang nicht global beobachten lassen; mindestens das muss Flow hinbekommen. - PS: Weil ich Bugzilla in seiner eingebürgerten Nutzung als Diskussionsplattform statt als Bugtracker für seit vielen Jahren kommunikativ völlig verfehlt halte, boykottiere ich ihn und habe dort ebenfalls keinen Account.
Beste Grüße --PerfektesChaos 22:45, 18. Sep. 2013 (CEST)
- Hi PerfektesChaos, mir war nicht bewusst dass die Technik-Werkstatt auch solche Faelle abdeckt, danke fuer den Hinweis! Ich werde in Zukunft darauf verweisen! Bezueglich der zurecht kritisierten Anmeldeprozedur werden wir in den naechsten Monaten mal versuchen, dass mit dem Login zusammenzulegen (siehe bugzilla:14487). Um die Verwirrung dieser ganzen Felder (Core, extension, priority, assign, product) zu vermindern bin ich dabei, etwas mit der "Guided Bug Entry Form" herumzuexperimentieren (siehe bugzilla:36762). Ob das das Eintragen von Fehlermeldungen etwas einfacher machen wird, wird sich zeigen. Wie gesagt, nochmal danke fuer die Hinweise, das ist nuetzlich so wissen! --AKlapper (WMF) (Diskussion) 16:40, 20. Sep. 2013 (CEST)
- Wer Fachfrau für Obstbäume oder Fachmann für Gymnastik ist, kann core nicht von extension unterscheiden und findet sich nicht zurecht; da hilft auch eine bessere Anleitung nichts. Unter „Kern“ und „Extension“ stellen sich diese Autoren etwas anderes vor.
- Wobei nichts dagegen spricht, Anleitungen zu verbessern.
- Einen bestehenden Bug zu kommentieren, mag einem Nicht-enWPler bei mäßiger Ausdrucksmöglichkeit in englischer Sprache möglich sein. Einen Bug neu anzulegen ist aber für alle Normal-Autoren gleich welcher Sprache ohne ein Grundverständnis und Erfahrung mit den Strukturen der MW-Software und die Systematik von Bugzilla unzumutbar.
- Zu jedem Produkt, das einem im WP-Alltag begegnen kann, hat eine normale Wiki-Diskussion (Talk/LT/Flow) zu gehören; nebst Anlaufstellen für unsortierte Wünsche und Fragen (VP). Technische Fachleute kristallisieren daraus neue Bugmeldungen oder finden bereits vorhandene. Sprachabhängigkeit und Englisch ist dann noch eine weitere Frage.
- Feature Requests gehören dann in einen Bugtracker, wenn Details einer existierenden Funktionalität angepasst und erweitert werden sollen. Für die Erarbeitung neuer Konzeptionen und völlig neuer Funktionalität ist ein Bugtracker schlicht das falsche Werkzeug. Das ist Grundproblem der Kommunikation zwischen MW-Entwicklern und Anwendern, seitdem die WP den Kinderschuhen entwachsen war.
- Viele der Probleme lassen sich aber schon lokal klären: Bedienungsfehler, Browser-Einstellungen, Konfiguration im dewiki und lokale Gadgets.
- Wer Fachfrau für Obstbäume oder Fachmann für Gymnastik ist, kann core nicht von extension unterscheiden und findet sich nicht zurecht; da hilft auch eine bessere Anleitung nichts. Unter „Kern“ und „Extension“ stellen sich diese Autoren etwas anderes vor.
- Greetings --PerfektesChaos 10:44, 21. Sep. 2013 (CEST)
- Man muss auch Core gar nicht von Extension unterscheiden muessen, wenn man den Leuten sagt dass sie ihren Bericht einfach erstmal unter "Core > General/Unknown" eintragen koennen. Es ist Aufgabe von Triagern, das richtige Koerbchen (Component) zu finden. Das mit dem "unzumutbar" sehe ich nicht so. Bei der Rolle von Bugzilla fuer Feature Requests stimme ich zu; bei den Diskussionseiten zu jedem Produkt habe ich mir bisher noch keine Meinung gebildet. --AKlapper (WMF) (Diskussion) 16:32, 21. Sep. 2013 (CEST)
- Es ist mindestens eine Hürde für Autoren, die nichts mit Software zu tun haben. Sie mag dir als Software-Entwickler geringfügig vorkommen; wir wissen über viele Jahre, dass sie für die meisten Autoren kaum zu überwinden ist: Es wird „offiziell ein Bug registriert“, vielleicht blamiere ich mich jetzt dabei; vielleicht ist das gar kein Bug was ich beobachte, vielleicht stelle ich mich nur zu doof an, und hier ist alles so fremd und anders. Hinzu kommt die vorangegangene Registrierung als Benutzer mit E-Mail-Adresse, die dem Ganzen einen noch feierlicheren und offiziellen Charakter gibt.
- Die nächste Hürde gibt es für Menschen, die Englisch nicht als Muttersprache haben. Sie wirkt völlig abschreckend.
- Hinzu kommt das Problem, das mit Nicht-Software-Leuten aller Sprachen besteht: Eine vollständige Problembeschreibung nebst aller Begleitumstände und Schilderung des erwarteten gegen das tatsächliche Geschehen.
- Jemand, der erst- und einmalig mit einem Software-Problem konfrontiert ist und Bugzilla wahrscheinlich nie wieder brauchen wird, lässt diesen ganzen Aufwand bleiben.
- Vielleicht ist es nur eine einfache Frage zur richtigen Bedienung. Deswegen kommen Leute auf die niederschwellige WP:FZW und erwarten dort niederschwellige Hilfe in ihrer Vorstellungswelt. Deshalb einen „Bug aufmachen zu müssen“ war nicht die Erwartung. Man wollte doch nur eine Frage stellen, warum es nicht funktioniert.
- PS: Dein Kunde, den du auf FZW dazu aufgefordert hattest, mal einen Bug aufzumachen, sendet inzwischen ultimative Hilferufe.
- Er hatte auch brav die von dir gewünschte nähere Auskunft gegeben. Dies ist soweit vollständig.
- Als IP ist er schon in der Wikipedia nicht angemeldet. Was dich dann auf die Idee bringt, er würde sich aber statt dessen bei Bugzilla anmelden und dort einen bug filen, ist mir schleierhaft.
- Gerade bei IP musst du davon ausgehen, dass es sich um einen besonders neuen Benutzer handelt, der noch gar nichts mit Wikis zu tun hat. Wenn sich schon erfahrene Wiki-Autoren davor scheuen, Bugzilla anzufassen, dann erst recht ein potenzieller Neu-Benutzer.
- VG --PerfektesChaos 21:05, 21. Sep. 2013 (CEST)
- Dass eine Huerde da ist, bestreite ich nicht. Jedes User Interface, das anders ist als die zumeist genutzte oder bereits bekannte Software, schreckt ab. Das "Blamieren" ist ein soziales und damit ein anderes Problem, dass sich technisch nicht loesen laesst (sondern nur durch nett und freundlich sein). Das Problem der vollstaendigen Problembeschreibung laesst sich nur durch bessere Hilfe beim Eintragen eines Fehlerberichtes verbessern, wie sollte sonst jemand wissen welche Informationen fuer einen Entwickler notwendig sind. Niemand setzt eine Erwartung, einen „Bug aufmachen zu müssen“. Wenn ich in einem der Foren kommentiere sage ich dass es nett waere, wenn jemand einen Bug eintragen koennte. Kein "muss". Trotzdem fuehrt langfristig kein Weg daran vorbei, um den Entwicklern Bescheid zu geben. PS: Dass der "Kunde" Hilferufe sendet hat offensichtlich damit zu tun dass er keine Rueckmeldung erhalten hat, aber nicht mit der Bitte einen Bericht in Bugzilla einzutragen. Bitte nicht Ursachen durcheinander schmeissen. Ich weiss nicht was daran schleierhaft sein soll einem Nutzer zu sagen, wo ein Bericht ueber einen offensichtlichen Fehler landen muss damit ihn ein Entwickler sieht. Ich werde auch niemanden davon abhalten, das Problem in die Fehlerdatenbank zu kopieren, oder bessere Antworten zu liefern. Ich habe auch nicht den Benutzer speziell dazu selbst aufgefordert, sondern "jemanden". PS: Ich bin kein Software-Entwickler und wuerde mich daher freuen wenn diese falsche Annahme fallengelassen wuerde, auch wenn sie sicherlich praktisch fuer bestimmte Argumentationen sein kann. ;) --AKlapper (WMF) (Diskussion) 12:47, 22. Sep. 2013 (CEST)
- Um obige Argumentation mal ironisch stark zu ueberspitzen: Der von Dir angebrachte Benutzer scheint bereits leider Probleme damit zu haben, Diskussionsseiten zu benutzen anstelle den Artikel mit seiner Frage zu editieren. Daher schlussfolgere ich, dass das User Interface der Wikisoftware zu kompliziert ist und dass man es Nicht-Software-Leuten nicht zumuten sollte und sie nicht auffordern sollte, eine Wikiseite zu editieren. Oder um etwas ernsthafter zu sein: Bei einigen Deiner Punkte stimme ich zu, und bei einigen habe ich andere Schlussfolgerungen als Du. :) --AKlapper (WMF) (Diskussion) 13:08, 22. Sep. 2013 (CEST)
- Dass eine Huerde da ist, bestreite ich nicht. Jedes User Interface, das anders ist als die zumeist genutzte oder bereits bekannte Software, schreckt ab. Das "Blamieren" ist ein soziales und damit ein anderes Problem, dass sich technisch nicht loesen laesst (sondern nur durch nett und freundlich sein). Das Problem der vollstaendigen Problembeschreibung laesst sich nur durch bessere Hilfe beim Eintragen eines Fehlerberichtes verbessern, wie sollte sonst jemand wissen welche Informationen fuer einen Entwickler notwendig sind. Niemand setzt eine Erwartung, einen „Bug aufmachen zu müssen“. Wenn ich in einem der Foren kommentiere sage ich dass es nett waere, wenn jemand einen Bug eintragen koennte. Kein "muss". Trotzdem fuehrt langfristig kein Weg daran vorbei, um den Entwicklern Bescheid zu geben. PS: Dass der "Kunde" Hilferufe sendet hat offensichtlich damit zu tun dass er keine Rueckmeldung erhalten hat, aber nicht mit der Bitte einen Bericht in Bugzilla einzutragen. Bitte nicht Ursachen durcheinander schmeissen. Ich weiss nicht was daran schleierhaft sein soll einem Nutzer zu sagen, wo ein Bericht ueber einen offensichtlichen Fehler landen muss damit ihn ein Entwickler sieht. Ich werde auch niemanden davon abhalten, das Problem in die Fehlerdatenbank zu kopieren, oder bessere Antworten zu liefern. Ich habe auch nicht den Benutzer speziell dazu selbst aufgefordert, sondern "jemanden". PS: Ich bin kein Software-Entwickler und wuerde mich daher freuen wenn diese falsche Annahme fallengelassen wuerde, auch wenn sie sicherlich praktisch fuer bestimmte Argumentationen sein kann. ;) --AKlapper (WMF) (Diskussion) 12:47, 22. Sep. 2013 (CEST)
- Es ist mindestens eine Hürde für Autoren, die nichts mit Software zu tun haben. Sie mag dir als Software-Entwickler geringfügig vorkommen; wir wissen über viele Jahre, dass sie für die meisten Autoren kaum zu überwinden ist: Es wird „offiziell ein Bug registriert“, vielleicht blamiere ich mich jetzt dabei; vielleicht ist das gar kein Bug was ich beobachte, vielleicht stelle ich mich nur zu doof an, und hier ist alles so fremd und anders. Hinzu kommt die vorangegangene Registrierung als Benutzer mit E-Mail-Adresse, die dem Ganzen einen noch feierlicheren und offiziellen Charakter gibt.
Phabricator in der deutschsprachigen Wikipedia
FYI: Es gibt als ersten Anfang Wikipedia:Technik/Phabricator.
Die Woche über schaue ich mir an, ob alles mit der Migration geklappt hat, und lasse potentielle Kinderkrankheiten robust werden.
Nächstes Wochenende werde ich mich anmelden, die Stimmigkeit der angebotenen Hilfetexte nachvollziehen, und anhand meiner Erfahrungen die oben verlinkte Seite weiter ausbauen.
LG --PerfektesChaos 21:44, 23. Nov. 2014 (CET)
- Herzlichen Dank (und ich bitte um Entschuldigung dass ich die Doku nicht selbst ausbauen konnte, aber ich habe dieses Wochenende versucht circa fuenfzig Wikiseiten zu aktualisieren von Bugzilla nach Phabricator...)! --AKlapper (WMF) (Diskussion) 22:15, 23. Nov. 2014 (CET)
WP:Thanks
Ich bin verärgert. Bei Namensumbenennung wird jede Sperre mitgenommen, aber bei den Gesamtdaten bei WP:Thanks habe ich immer noch "zwei Benutzernamen". Den hier plus meinen alten Jack User (beide sind ein und derselbe Account). Wißt ihr was? WP:Thanks könnt ihr so in die Tonne kloppen, in der Statistik bin ich Nr. 9 und Nr. 24. Korrekt zusammengefaßt wäre ich an dritter Stelle. Wir reden hier von keiner "zusätzlichen Funktionalität", sondern von einem groben Fehler aka Bug. Wie wäre es, wenn ihr eure eigenen Fehler selber ausbügelt? --Informationswiedergutmachung (Diskussion) 16:26, 17. Dez. 2014 (CET)
- @Informationswiedergutmachung:: Ich bezog mich in meinem vorherigen Kommentar explizit auf die Sprache in dem Ticket. Wenn's hier um einen Bug geht dann ist das momentan nicht wirklich ersichtlich fuer jemanden der das Ticket in Phabricator liest (zumindest war es das nicht fuer mich). "Please include more log types for renaming" liest sich fuer mich wie ein neues Feature daher habe ich die Priority auf "Needs Volunteer" gesetzt (was nicht besonders selten ist in freien Softwareprojekten). Wenn es sich also um einen Bug und/oder eine Regression handelt, dann bitte ich dich darum im Phab-Ticket gegenueber den Entwicklern auszudruecken warum es sich um einen Bug handelt, was dieser konkret an Auswirkungen hat, und warum die Priority des Tickets hoeher sein sollte (siehe auch mw:Bug management/Phabricator etiquette). Ich wiederhole mich, aber beim Lesen des Tickets in Phabricator klang das nicht wie ein Bug fuer mich. Zu Saetzen mit "ihr": Ich bin eine Person, du wahrscheinlich auch. Das Beantworten sarkastischer oder unproduktiver Kommentare gehoert nicht zu meinen Prioritaeten, ich helfe und kommuniziere aber gerne mit positiven und engagierten Mitgliedern in unserer Wikimedia-Gemeinschaft. --AKlapper (WMF) (Diskussion) 17:08, 17. Dez. 2014 (CET)
- Ach, jetzt auch noch Prinzesschen auf der Erbse spielen? Das habe ich gerne. Ich pfeife auf euer Bug Managment, aber nicht nur deswegen, sondern auch, weil ich nicht dazu bereit bin, mir euer F(l)achenglisch anzutun, ich bin hier zum Artikelschreiben, und da kann ich einiges vorweisen. Was soll ich mir hier noch alles antun? Ich, und nicht nur ich, habe(n) klar und deutlich ausgedrückt, wo der Fehler ist, und soll das nochmal wiederholen, in einer Fachsprache, die ich nicht kenne und auch weder Zeit noch Lust habe mir anzutun? Du hast ja noch nicht einmal auf Deutsch (oder Englisch, ich weiß es nicht) verstanden, was das Problem ist und das soll ich in meinem Englisch (das zwar für einiges reicht, aber sicher nicht für Bug-Reports) das Problem wiederholen, und dann zigmal rumdiskutieren, was denn nun gemeint ist? Bin ich hier beim Buchbinder Wanninger? Nö. Daher: HabedieEhre, und immer schön positiv und enagiert sein. EOD --Informationswiedergutmachung (Diskussion) 17:25, 17. Dez. 2014 (CET)
Probleme mit Vorschaubildern
Hallo Andre,
Benutzer:Raymond hat mich auf Dich aufmerksam gemacht, daher wende ich mich an Dich. Schau Dir bitte mal folgende Seiten an:
- Benutzer Diskussion:Raymond#Probleme mit Vorschaubildern
- Benutzer:Hasenläufer/ProblemeMitVorschaubildern
Ich bin mir unsicher, ob es Sinn macht, für das geschilderte Problem ein Phabricator-Ticket aufzumachen. Daher diese Vorabanfrage an Dich.
Um das geschilderte Problem nachvollziehen zu können, wäre es erforderlich, dass jemand über eine jüngste Version von macOS und Safari verfügt. Also macOS High Sierra 10.13.1 und Apple Safari 11.0.1 (13604.3.5) – beides sind die derzeit aktuellen Versionen. Möglicherweise ist das Problem auch unter macOS Sierra reproduzierbar – aber Safari 11.0.1 sollte es schon sein, da ich vermute, dass das Problem nur mit dieser jüngsten Safari-Version nachvollziehbar ist.
Ist Dir jemand aus Deinem Team bekannt, der über eine solche Installation verfügt? Ich denke, es macht nur Sinn, aus dem Thema ein Phabricator-Ticket zu erstellen, wenn es reproduzierbar ist. Falls ja, würde ich als Vorbereitung eines Tickets die Seite Benutzer:Hasenläufer/ProblemeMitVorschaubildern ins Englische übersetzen. Gruß, Eckhard --Hasenläufer (Diskussion) 00:02, 19. Nov. 2017 (CET)
Fyi, der Seite Benutzer:Hasenläufer/ProblemeMitVorschaubildern habe ich eine englische Übersetzung beigefügt. --Hasenläufer (Diskussion) 02:46, 19. Nov. 2017 (CET)
Fyi 2: Ich habe das Thema in Probleme mit Vorschaubildern auf macuser.de adressiert. Hintergrund: Ich suche nach mehrfachen Verifikationen bzw. Falsifikationen. Ein Forum wie z. B. auf macuser.de erscheint mir in dieser Hinsicht als angemessen, weil ich annehme, dass dort mehrere Benutzer mit den aktuellen Versionen von macOS und Safari arbeiten. Mal schauen, ob bzw. was dabei heraus kommt. Gruß, Eckhard --Hasenläufer (Diskussion) 05:36, 19. Nov. 2017 (CET)
- @Hasenläufer: Hi, ich nehme momentan an dass dies eher ein Problem in Apple-Software ist denn in Wikimedia-Software. https://discussions.apple.com/thread/8141246 beschreibt dass es Nutzern geholfen hat, das Farbprofil des Monitors unter "System Preferences→Monitor→Color" zu aendern. Vielleicht einen Versuch wert? :) --AKlapper (WMF) (Diskussion) 20:45, 19. Nov. 2017 (CET)
- @AKlapper (WMF): Besten Dank für diesen Link! Er könnte mir wertvolle Infos zur weiteren Fehleranalyse liefern. Z. B. wird dort ein Problem mit „Mac mini (Mid 2011)“ beschrieben – das ist genau die Hardware, die auch ich verwende. Oder auch: „So I'm afraid it's a High Sierra Safari bug with Intel HD Graphics 3000.“ Das scheint alles in Richtungen zu zeigen, die ich verfolgen werde. Eine mögliche Maßnahme wäre ggf., dass ich meinen Monitor neu kalibrierte. Ich werde mich später noch mal an dieser Stelle melden. --Hasenläufer (Diskussion) 21:19, 19. Nov. 2017 (CET)
- @AKlapper (WMF): Hallo Andre, das Thema hatte mich in den letzten Tagen noch weiterhin beschäftigt. Dank Deines Hinweises konnte ich Fehlerursachen nachgehen, auf die Du mich aufmerksam gemacht hattest. Den letzten Stand meiner Erkenntnisse habe ich unter c:User:Hasenläufer/HighSierraProblem beschrieben. Heute habe ich einen Bug-Report an Apple adressiert. Ich danke Dir noch mal für Deine Unterstützung und denke, wir können das Thema hier abschließen.
- Der Bug-Report an Apple ist für mich eine Premiere. Ich bin gespannt, wie sich Apple in dieser Hinsicht verhalten wird. Vor Jahren hatte ich mal einen Bug-Report an Adobe adressiert und war positiv überrascht, wie zeitnah der Fehler sowohl öffentlich bestätigt als auch beseitigt wurde. Mal schauen, was aus meinem Bug-Report an Apple wird wird. Ich vermute, dass Apple solche Dinge anders kommuniziert als z. B. Adobe.
- Gruß, Eckhard --Hasenläufer (Diskussion) 12:31, 25. Nov. 2017 (CET)