Wikipedia

Wikipedia Diskussion:WikiDaheim

Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 23. Januar 2019 um 12:32 Uhr durch Herzi Pinki (Diskussion | Beiträge) (→Kritik, Diskussion: re). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Letzter Kommentar: vor 6 Jahren von Herzi Pinki in Abschnitt Zum frühzeitigen Aussortieren von Bildern in der Vorjury
Einleitung dieser Diskussionsseite anzeigen
 Diese Seite ist die allgemeine Problem-Anlaufstelle für WikiDaheim. Dies betrifft:
  • Bedienprobleme (hier wird dir gleich geholfen)
  • Datenfehler in den Grunddaten auf Commons (z.B. Friedhofsbilder sind nicht richtig einsortiert). Hier kann sich jeder selber helfen.
  • Probleme mit der Implementierung und Funktionsweise des Backends (Extraktion der Daten aus Wikipedia / Commons).
  • Probleme mit der Implementierung und Funktionsweise des Frontends (Darstellung dieser Daten in der WikiDaheim Applikation). Diese können jedoch auch gerne direkt in GitHub eingetragen werden.


 Nützliche Links:
Archiv

2017, 2018
Wie wird ein Archiv angelegt?
Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 3 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.
Auf dieser Seite werden Abschnitte mittwochs automatisch archiviert, deren jüngster Beitrag mehr als 30 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten.

Fehler in der JS Konsole: Tut weh

Letzter Kommentar: vor 7 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Karte wird nicht angezeigt, keine sichtbare Fehlermeldung an der Oberfläche: 

Error: Failed to initialize WebGL
Stack-Trace:
[189]</S</e.prototype._setupPainter@https://wikidaheim.at/client/vendor.js:1:554907
e@https://wikidaheim.at/client/vendor.js:1:543572
h/$</n.prototype.componentDidMount@https://wikidaheim.at/client/vendor.js:1:889447
a</t.prototype.notifyAll@https://wikidaheim.at/client/vendor.js:1:634004
close@https://wikidaheim.at/client/vendor.js:1:832534
closeAll@https://wikidaheim.at/client/vendor.js:1:107018
perform@https://wikidaheim.at/client/vendor.js:1:106516
perform@https://wikidaheim.at/client/vendor.js:1:106436
perform@https://wikidaheim.at/client/vendor.js:1:12725
T@https://wikidaheim.at/client/vendor.js:1:12902
closeAll@https://wikidaheim.at/client/vendor.js:1:107018
perform@https://wikidaheim.at/client/vendor.js:1:106516
batchedUpdates@https://wikidaheim.at/client/vendor.js:1:825701
u@https://wikidaheim.at/client/vendor.js:1:11886
r@https://wikidaheim.at/client/vendor.js:1:603875
enqueueSetState@https://wikidaheim.at/client/vendor.js:1:605003
r.prototype.setState@https://wikidaheim.at/client/vendor.js:1:659369
l/</r</s.prototype.handleChange@https://wikidaheim.at/client/vendor.js:1:908615
p@https://wikidaheim.at/client/vendor.js:1:665636
r/</</<@https://wikidaheim.at/client/vendor.js:1:942566
dispatch@https://wikidaheim.at/client/vendor.js:1:942871
g/</<@https://wikidaheim.at/client/client.js:1:84498
Als Issue auf GitHub angelegt: https://github.com/Wikimedia-Austria/WikiDaheim/issues/20 – Simon04 (Diskussion) 17:30, 10. Aug. 2017 (CEST)Beantworten

Fehler in der JS Konsole: Keine Ahnung, ob das weh tut (2)

Letzter Kommentar: vor 7 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Keine sichtbare Auswirkung (Laden einer neuen Gemeinde): 

Error: WebGL warning: texImage2D: Alpha-premult and y-flip are deprecated for non-DOM-Element uploads.  vendor.js:1:501388
Error: WebGL warning: texSubImage2D: Alpha-premult and y-flip are deprecated for non-DOM-Element uploads.  vendor.js:1:270760
Error: WebGL warning: texSubImage2D: Alpha-premult and y-flip are deprecated for non-DOM-Element uploads. vendor.js:1:488147

lg --Herzi Pinki (Diskussion) 19:29, 8. Aug. 2017 (CEST)Beantworten

Media from WikiDaheim 2017 in Austria needing check (after)

Letzter Kommentar: vor 7 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Was machen wir mit den Bildern, die nach Ende des Wettbewerbs in der Kategorie Commons:Category:Media from WikiDaheim 2017 in Austria needing check landen? https://petscan.wmflabs.org/?psid=1320648 Wir haben aktuell noch rund 3300 Bilder aus dem Wettbewerb, die noch nicht geprüft sind. BTW: Danke an alle, die bei den ersten 4000 Bildern ein Auge drauf geworfen haben. lg --Herzi Pinki (Diskussion) 16:14, 8. Okt. 2017 (CEST)Beantworten

Relative Anzahl hochgeladener Bilder

Letzter Kommentar: vor 7 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Ich habe wieder mal eine Gemeindestatistik Österreich erstellt / aktualisiert. Der Zeitraum deckt sich nicht mit WikiDaheim, trotzdem bin ich versucht, einen Vergleich auf Tagesbasis anzustellen. Die Gemeindestatistik umfasst den Zeitraum 3. June 2017 bis 27. November 2017. In diesem Zeitraum (177 Tage) wurden den Gemeinden (ohne Großstädte) 39123 Bilder hinzugefügt (d.h. nicht unbedingt neu hochgeladen, nicht unbedingt eigene Fotos, etc.), das sind im Schnitt 221 Bilder pro Tag. Im Vergleich dazu wurden bei WikiDaheim von 28. Juli 2017 bis 7. Oktober 2017 (71 Tage) insgesamt (mit Großstädten) 7217 Medien hochgeladen, also im Schnitt 102 Bilder pro Tag, rechnet man meine Schönbrunn-Bilder und andere Bilder aus den Großstädten raus, bleiben 3566 Bilder oder 50 Bilder pro Tag. Da WikiDaheim quasi alles umfasst, ist da deutlich Platz nach oben, nur durch passende Zuordnung.

Auf der anderen Seite zeigt die Statistik sehr fuzzy, in welchen Gemeinden relativ wenige Fotos vorhanden sind, und weitere Anstrengungen zur Bebilderung (etwa im Rahmen von WikiDaheim) sich lohnen könnten (Sortierung nach /1000 Ew. (Bilder pro 1000 Einwohner)), da sind auch größere Gemeinden wie Marchtrenk oder Traun dabei. Einzelleistungen wie jene von User:GT1976 führen dazu, dass beim Zuwachs an Bildern Gemeinden wie Schwarzenbach an der Pielach oder Frankenfels weit vorne liegen (Sortierung nach Δ/1000 Ew.). Kleine Gemeinden sind da natürlich im Vorteil.

Der Durchschnittswert liegt bei 75 Bildern je 1000 Ew. und Gemeinde, sowie bei 6 Artikeln je 1000 Ew. und Gemeinde.

Da sich bei den Einwohnerzahlen auf Wikidata Änderungen ergeben haben, stimmt die Auswertung im Detail da und dort nicht ganz. lg --Herzi Pinki (Diskussion) 10:21, 28. Nov. 2017 (CET)Beantworten

Grundsätzliches nach WD 2018, aber für ev. WD 2019

Letzter Kommentar: vor 6 Jahren2 Kommentare1 Person ist an der Diskussion beteiligt

Ich habe mir mal ein bisschen Gedanken gemacht, statt das unter #Laaangweilig weiter zu diskutieren. Notizen zu WikiDaheim 2018.

Anzahl der Bilder je Uploader

Aktuell (22.9.2018) wurden 10859 Bilder hochgeladen, der Median an hochgeladenen Bildern je User beträgt 6, der Schnitt 83 bei einer Maximalanzahl von 1167 Bildern für einen einzelnen User. Quelle: [1]. User mit ganz wenigen Bildern (tendenziell eher neue User) haben damit wettbewerbstechnisch stark reduzierte Chancen, einen der begehrten Preise zu gewinnen, detto positives Feedback für die Auszeichnung eines Bildes und damit erhöhte Wikipedia-Bindung. Das ist schade, weil es das Ziel neue User anzusprechen, etwas konterkariert. Es reicht schon, dass erfahrene User bei der Bildauswahl, -bearbeitung, -beschreibung im Vorteil sind. Vorschlag: Begrenzung der maximalen Anzahl nominierbarer Bilder je User auf eine (kleine) Anzahl in der Nähe des Medians. Es sollte erreicht werden, dass bei einer zufälligen Auswahl eines Bildes aus allen nominierten vergleichbare Wahrscheinlichkeiten für jeden User bestehen. (Und ich bin mit meinen >1000 Bildern selbst einer derjenigen, die sich da stark einschränken müssten). Erfahrene UserInnen laden ihre 1000+ Bilder auch ohne Wettbewerb hoch. Bei den monatlichen Fotowettbewerben auf Commons etwa sind 4 Bilder pro User erlaubt, selbst 5 Bilder pro Tag auf QI erlaubt nur die Nominierung von etwa 490 Bildern im ohnehin weitgesteckten Wettbewerbszeitraum.

Es ist zu klären, dass ein weg von der Menge nicht anderen Zielen zuwiderläuft, etwa einer im Grant versprochenen Anzahl an hochzuladenden Bildern.

Mindestteilnehmeranzahl (Lex Kellergassen, Lex Innenansichten)

Eventuell macht es Sinn, Bewerbe nur ab einer MindestteilnehmerInnenzahl auszuspielen?

Automatische Teilnahme

Aktuell werden beim Hochladen über die Listen die Bilder automatisch für WikiDaheim kategorisiert. Zwangsteilnahme. Wenn die Anzahl der Bilder / User limitiert ist, kann das nicht so bleiben. Aber auch sonst, ist das zu hinterfragen.

Scope

Einige Benutzer finden den Scope von WikiDaheim zu weit, so möchte (hier als Beispiel gedacht) etwa Regiomontanus keine Sportaufnahmen im Scope haben. Eine Schärfung des Scopes für WD 2019 sollte daher diskutiert werden.

Wettbewerbsrahmen

Es muss vor Beginn des ersten Wettbewerbs klar definiert sein, welche Wettbewerbe es gibt, geben wird, was ihr Scope ist und über welchen Zeitraum sie laufen. Diese Festlegung darf während des gesamten Zeitraums nicht mehr geändert werden, da dies unfair gegenüber einzelnen Usern sein kann. Ein Rückgriff auf das Vorjahr ist zu wenig, jeder (Teil-)Wettbewerb ist erneut zu definieren und mit (Vor-)Jury und Preisen zu versehen. Siehe etwa Wikipedia Diskussion:WikiDaheim#Ansichten zu Innenansichten. Für jeden Teilwettbewerb muss es einen definierten Verantwortlichen und eine Sponsor geben.

gemeinsamer Strang

Die Stakeholder (Organisator, Wettbewerbseigner, Verein, Geschäftsführung, die üblichen Poweruser, tech. Staff) sollten an einem Strang ziehen. Zumindest dem Projekt neutral gegenüber stehen. Sonst wird das nichts oder ladet die Last eines solchen Wettbewerbs auf zu wenigen Schultern ab.

Technik, Check

Das Nachprüfen / Nachkategorisieren so vieler Bilder ist Arbeit. Mühsame Arbeit auf eher wenigen Schultern. Für User, die nicht über den UploadWizard hochladen oder neue User sind diese Formalien kaum richtig zu machen. Entweder fällt uns was ein, wie das besser zu automatisieren geht, oder wir lassen es. Ideen gesucht.

Kontaktaufnahme mit Neulingen

Die Kontaktaufnahme mit Neulingen sollte für alle nachvollziehbar geschehen. Eine e-mail ist ok, aber wir brauchen eine Liste in der WP, wer welchen Benutzer kontaktiert hat und damit auch sowas wie eine Mentorenschaft über diesen Benutzer übernommen hat. Doppelte Kontaktierung ist das geringere Problem, aber eine verlorene Chance der Kontaktierung ist eine verlorene Chance einen neuen Benutzer anzusprechen.

Gründe für Nicht-Teilnahme von lang dienenden WP-Fotografen

wäre zu erfragen. Gugerell, Bwag, Linie29, Papergirl

--Herzi Pinki (Diskussion) 14:21, 11. Okt. 2018 (CEST)Beantworten

Rückblickend auf die Besprechung vom 17.1. fühle ich mich ignoriert. lg --Herzi Pinki (Diskussion) 00:47, 22. Jan. 2019 (CET)Beantworten

Neue Denkmalbilder 2018

Letzter Kommentar: vor 6 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Bei den Denkmallisten wurden 106 Löcher gestopft. Davon von zwei neuen Usern und einem recht fleißigen User, der 2017 nur einen Edit hatte.

angemeldet seit
HGT64 16 2017
Naturpuur 14
Braveheart 9
Haeferl 8
Hans Christian Briebauer 7 2012
Bwag - keine Teilnahme an WD 7
Isiwal 7
Szojak 6
AStiasny 5
Niki.L 4
PLauppert 3
Christian Pirkl 3
Herzi Pinki 3
Rufus46 2
Fl.schmitt 2 2011
TheRunnerUp 1
Ckling41 1 2006
Alletto 1
Robert Heilinger 1
Lindis Tirol 1 2018
ÖggHof221 einer der Besitzer 1 2018
BSonne 1
Liuthalas 1
Kanisfluh 1 (2018)
MaKatzen69 1 2015

Damit hat sich der Deckungsgrad an Bildern von 37191 auf 37295 bei 38146 Objekten erhöht, d.h. wir haben jetzt 97.8 % der Denkmäler bebildert (da zählen die Dummy-Bilder aber mit). Die 99 Tage WikiDaheim haben da einen Zuwachs von 0.3 % erzeugt.

Der idente Vergleichszeitraum 2017 hat 0.4 % (oder anders gerechnet, da Update in diesem Zeitraum: 0.2 %) beigetragen.

In den 9 Monaten dazwischen wurden 0.6 % (oder anders gerechnet, da Update in diesem Zeitraum: 0.4 %) der Lücken gefüllt. lg --Herzi Pinki (Diskussion) 11:29, 16. Okt. 2018 (CEST)Beantworten

Inhaltliche Frage zu TDD

Letzter Kommentar: vor 6 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

@(c)leitl: als Uploader. Mir ist unklar, ob die Bilder in commons:Category:Vellach 99 im Rahmen der TdD Tour Kärnten 1, Bad Eisenkappel [2] besucht worden sind oder nicht. Kann das jemand von den TDD-Leuten klären? Je nachdem sind sie für TDD teilnahmeberechtigt oder nicht. lg --Herzi Pinki (Diskussion) 11:50, 13. Okt. 2018 (CEST)Beantworten

Statistik TdD 2018

Letzter Kommentar: vor 6 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Insgesamt wurden 439 Bilder hochgeladen und für den TdD 2018 markiert. 2017 waren es 231 Bilder, somit ein Plus von 208 Bildern oder 90 %. Das Wachstum ist statistisch von zweifelhaften Wert (geringe Stichprobengröße = große Schwankungsbreite, 24 TeilnehmerInnen), da ein einziger Benutzer mit 170 Bildern zu einem Veranstaltungsort quasi das gesamte Wachstum verursacht hat. Allerdings hat sich die Anzahl der TeilnehmerInnen gegenüber 2017 verdoppelt. Die Anzahl der nominierten Bilder je TeilnehmerIn ist mit 18.3 gegenüber 19.3 im Vorjahr in etwas gleich geblieben.

15 BenutzerInnen haben noch weitere Bilder zu Objekten, die am TdD teilgenommen haben, hochgeladen., allerdings wurden sie offensichtlich nicht angesprochen, damit sie ihre Bilder nachmarkieren. Das ist schade. Größenordnungsmäßig handelt es sich da um etwa 200 zusätzliche Bilder (hab sie nicht gezählt, aber bei Karl Gruber waren es allein 87).

Ein Auswertung, wer über unser WP Seiten und wer über den Link des BDA's hochgeladen hat, ist mir leider nicht möglich. Aber vielleicht hat ja jemand eine Idee, wie das zu unterscheiden wäre. lg --Herzi Pinki (Diskussion) 18:06, 14. Okt. 2018 (CEST)Beantworten

Neue Naturdenkmalbilder 2018

Letzter Kommentar: vor 6 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Auch 106 neue Bilder in den Listen [3], FYI glamorous weist (auch abseits der Listen) 160 unterschiedliche Nutzungen aus. --Herzi Pinki (Diskussion) 02:43, 15. Okt. 2018 (CEST)Beantworten

Neue Public Art 2018

Letzter Kommentar: vor 6 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

glamorous weist (auch abseits der Listen) 171 unterschiedliche Nutzungen aus. --Herzi Pinki (Diskussion) 02:43, 15. Okt. 2018 (CEST)Beantworten

Ergebnisse Vorjury

Letzter Kommentar: vor 6 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Die Ergebnisse der Vorjury sind nun auch unter Wikipedia:WikiDaheim/Vorjury 2018 einsehbar - danke noch einmal an alle, die beim Bewerten mitgemacht haben. Ich denke es gibt wie weiter oben schon geschrieben einigen Verbesserungsbedarf fürs nächste Jahr, dazu wirds noch eine eigene Besprechung geben. LG, --Braveheart Welcome to Project Mayhem 21:42, 31. Okt. 2018 (CET)Beantworten

Rückblick und Ausblick WikiDaheim 2018/19 am 17. Jänner in Wien

Letzter Kommentar: vor 6 Jahren7 Kommentare6 Personen sind an der Diskussion beteiligt

Hi! Am 17. Jänner findet in der WMAT-Geschäftsstelle um 18 Uhr eine Besprechung zu WikiDaheim statt, um das letzte Jahr zu besprechen und die Weichen für dieses Jahr zu stellen, z.B. was den Umfang und das Format des Fotowettbewerbs betrifft. Bei Interesse bitte einfach hier in die Liste eintragen. LG, --Braveheart Welcome to Project Mayhem 13:56, 8. Jan. 2019 (CET)Beantworten

  • Vorläufige Agenda - bitte einfach Punkte hinzufügen, falls etwas wichtiges noch nicht abgedeckt wird
    • Diskussion des letzten Jahres, inklusive Statistiken
      • Karte von Ailura von Österreichgrenzen einbinden
      • Agruwie Wettbewerbszeitraum auf wikidaheim.at ankündigen; statt 1. Platz Kellergassen -> Sonderpreis Kellergassen (es gibt keinen zweiten Preis)
    • Besprechung der auf dieser Diskussionsseite aufgebrachten Punkte, darunter
      • Änderungen am Fotowettbewerb hinsichtlich der Masse und Qualität der Fotos
      • Integration von Tag des Denkmals
    • Structured Data für den WikiDaheim-UploadWizard
      • Vorbefüllen der Structured Data mit Informationen aus WikiDaheim wie etwa "Feuerwehrhaus"
      • Zusätzliche Felder im UploadWizard zum Verknüpfen von Bildern mit Wikidata-Item zu dem Objekt
        • Option, abstrakte Beschreibungen hinzuzufügen
        • Vorbefüllen der abstrakten Beschreibungen
      • Phototouren mit vorbefüllten Metadaten zum Event?
      • Sprachenabhängigkeit - wie nach Wikidata-Items in einer anderen Sprache als Deutsch suchen?
      • Nutzung der Metadaten zum Check/Wartung/Einbindung der Mediendateien
    • Verwendung von Wikivoyage als einfachere Bearbeitungsplattform für Touristikverbände/Gemeinden?
    • ...
Ich nehme teil
leider nein

Vergleich Vorjury WD AT mit WLM DE

Letzter Kommentar: vor 6 Jahren7 Kommentare4 Personen sind an der Diskussion beteiligt

@Haeferl, Regiomontanus:, in AT haben sich 15 Menschen für die Vorjury angemeldet, in DE 38. In AT nahmen 14700 Bilder am Bewerb teil, davon wurden 3000 von den Hochladern von der Vorjury ausgenommen, bleiben 11700. In DE 25800, davon wurden 9500 von den Hochladern von der Vorjury ausgenommen, bleiben 16300. Vergleicht man die Bevölkerung 1:10 und nivelliert den Hochladezeitraum mit 3:1 Monaten, so entsprächen die 11700 in AT 39000 Bildern in DE (HoHo!), also wurden in AT wesentlich mehr Bilder als in DE hochgeladen, wenn man die Zahlen auf vergleichbar rechnet. Bei einer Bewertung des Hochladezeitraums von 1:2 wären das sogar ein Erwartungswert von 58500 Bildern in DE gegenüber den tatsächlichen 16300 Bildern. Wenn man die Bevölkerungsanzahl und den kleineren Hochladezeitraum von 1 zu 3 Monaten verrechnet, beträgt der Mobilisierungsgrad der Fotografen in DE nur etwa 42 % von dem in Österreich. Für jeden Vorjuror und jede Vorjurorin blieben im Schnitt 780 Bilder in AT und 429 in DE Bilder pro Durchlauf zu bewerten. Das heißt, die Vorjuroren in AT, Haeferl, da hattest du Recht, hatten pro Durchlauf und Kopf 82 % mehr Bilder zu bewerten als in DE. Vergleich man die Zahlen aber bei einer fiktiven gleichen Hochladedichte (Bilder pro Einwohner, 11700 zu 39000 Bilder), so ergibt sich eine fiktive Mehrbelastung des einzelnen deutschen Vorjurors von 32 %. Man kann aber hoffen, dass sich mit zunehmender Hochladedichte auch mehr Vorjuroren finden werden. Die Hochladedichte lässt sich a priori schlecht abschätzen, so wurden in AT 75 % mehr Bilder hochgeladen als noch 2017.

Man kann das also auch anders sehen, entweder hatte AT zu wenige Juroren für die gleiche Anzahl an Durchläufen wie DE (bei gleicher Belastung), oder in AT wurden für die vorhandenen Juroren einfach zu viele Bilder eingereicht (bzw. zu wenige von den HochladerInnen von der Vorjury ausgeschlossen). ME ist die freiwillige Mitarbeit von Juroren nur schwierig einzufordern und vorherzusagen, einfacher ist jedenfalls eine Begrenzung der Anzahl der teilnahmeberechtigten Bilder. Nochmals anders ausgedrückt, können die deutschen Vorjuroren bei den obigen Zahlen und bei gleicher Belastung fast doppelt so viele Bewertungsdurchläufe machen, als unsereiner.

Realiter wurden in DE mindestens 8 Bewertungen pro Bild abgegeben (8,8 im Schnitt), in AT wurde jedes Bild mindestens 6 Mal bewertet (lt. email von Braveheart vom 30. Oktober), 6,5 im Schnitt. Damit wurden in AT etwa 76050 Bewertungen abgegeben, in DE etwa 143440 oder 5070 pro Vorjuror in AT bzw. 3775 pro Vorjuror in DE. Damit war die reale Arbeitsbelastung der Vorjuroren in AT etwa um 34 % höher (und nicht um die oben errechneten 82 %). Hervorzuheben sind ManfredK und Sebastian Wallroth, die sich jeweils an beiden Vorjurys beteiligt haben.

Bitte nachrechnen und ev. korrigieren. lg --Herzi Pinki (Diskussion) 00:51, 9. Jan. 2019 (CET)Beantworten

Vielen Dank für die Auswertungen. Beeindruckend ist die Entwicklung der Juryprozesse in Deutschland und in Österreich. Aus einem Mehrtagesmarathon für einige Juroren ist auch in Deutschland jetzt ein Teamwork mit einem zweistufigen Juryprozess geworden. 6,5 Bewertungen pro Bild bei WikiDaheim sind bei so vielen Bildern ein beachtlicher Wert. Wenn man bei der Vorjury noch etwas verbessern will, gibt es grundsätzlich zwei Möglichkeiten:
  • Mehr Beteiligung von Jurorinnen und Juroren in der Vorjury bzw. Verlängerung des Juryprozesses (durch früheren Beginn).
  • Weniger Bilder für die Vorjury z. B. durch Selbstbeschränkung bzw. verstärkte Benutzung der Kategorie "not for prejury" (nicht für die Vorjury) für Duplikate, Beiwerk wie Informationstafeln etc.
Darüber hinaus könnten durch Einbindung von mehr Leuten in die Vor- und Nachbereitung Synergien erzielt werden. --Regiomontanus (Fragen und Antworten) 06:54, 9. Jan. 2019 (CET)Beantworten
Den Mehrtagesmarathon gab es trotzdem. --Ailura (Diskussion) 09:25, 9. Jan. 2019 (CET)Beantworten
Die Frage ist auch, ob man beim Wettbewerb selbst durch konkretere Vorgaben die auszuschließenden Bilder erhöhen kann, was ich persönlich bezweifle, weils der hochladenden Person selbst nix kostet, Bilder für den Wettbewerb einzureichen. --Braveheart Welcome to Project Mayhem 11:16, 9. Jan. 2019 (CET)Beantworten
Mich kostet ein Foto im Schnitt 10 Minuten Bearbeitung, wenn ich schnell bin. Da ist Hinfahren noch gar nicht gerechnet. Insoferne ist es nicht ganz gratis, Bilder hochzuladen. Ich hab mal den Vorschlag gemacht, Bilder nach zwei Bewertungen unterhalb einer gewissen Punkteanzahl einfach per Algorithmus für weitere Bewertungen auszuscheiden. Ist aber nicht verstanden worden bzw. auf Wohlwollen gestoßen. Ein aktives Nominieren statt eines aktiven Nicht-Nominierens würde die Anzahl der für den Wettbewerb nominierten Bilder auch radikal senken, allerdings mehr Ansprüche an Neulinge stellen. lg --Herzi Pinki (Diskussion) 18:42, 9. Jan. 2019 (CET)Beantworten
Ja, die Ansprüche für Neulinge würden steigen, sofern wir nicht alle TeilnehmerInnen mit weniger als xy Fotos nicht automatisch am Wettbewerb teilnehmen lassen. Lass uns das am besten nächsten Donnerstag besprechen und konkreter ausformulieren, inklusive dem Vorschlag mit der Punktebewertung (wo ev. auch Structured Data helfen könnte). LG, --Braveheart Welcome to Project Mayhem 12:43, 11. Jan. 2019 (CET)Beantworten

Da es aber gar keine Vorgabe gibt, wie viele Bewertungsdurchgänge von der Vorjury zu absolvieren sein sollten, würden vermutlich 5 auch reichen. Das Ergebnis des Prozesses von Jury und Vorjury und Sondervoten wird durch mehr Durchgänge ab einem gewissen Punkt nicht mehr besser. Unzufriedene auf allen Seiten gibt es auch bei 100 Durchgängen. --Herzi Pinki (Diskussion) 02:56, 14. Jan. 2019 (CET)Beantworten

Structured data

Letzter Kommentar: vor 6 Jahren11 Kommentare4 Personen sind an der Diskussion beteiligt

So viel ich weiß gibt es ab März einzelne (ausgewählte) Pilotprojekte zu Structured Data, z.B. Sammlungen von Kulturgütern, die dann im 2. Halbjahr 2019 evaluiert werden. Ob das für uns schon reif ist bzw. helfen kann? Prinzipiell kann ich es mir vorstellen, aber jetzt schon? --Regiomontanus (Fragen und Antworten) 23:34, 11. Jan. 2019 (CET)Beantworten

Wann kann WMAT eine Schulung anbieten? Muss wohl erstes Quartal sein. Evaluierung im 2. Halbjahr käme zu spät, außer wir wollen uns mit bleading edge technologie auseinandersetzen. Allein schon das neue Feature der Captions macht den Upload-Wizard noch unfreundlicher und fehleranfälliger für die HochladerInnen, d.h. es muss mit erhöhtem Nachbearbeitungsaufwand gerechnet werden, siehe Commons:Commons:Village_pump#Good_practice_? (en.). Und bis Sommer kommt da noch was dazu, vermutlich auch im UW. Vielleicht sollten wir jeden Bewerb 2019 erst mal sistieren? Ohne klares Konzept, was die Benutzung von structured data für WD bedeutet, und wie das umzusetzen ist, kann die Entscheidung nächste Woche zu structured data eigentlich nur Nein heißen. Kann jemand bis Montag so ein Konzept erstellen? lg --Herzi Pinki (Diskussion) 02:07, 12. Jan. 2019 (CET)Beantworten

@Braveheart: Was SD betrifft, worum geht es?

  1. dass die Uploader mit dem Upload auch SD erfassen?
  2. dass irgendjemand SD für alle Objekte von WD zur Verfügung stellt und diese dann dem Uploader helfen, den Upload richtig zu machen?

--Herzi Pinki (Diskussion) 18:24, 12. Jan. 2019 (CET)Beantworten

@Herzi Pinki: Primär darum, dem Bild im UploadWizard mehr Informationen mitzugeben bzw. dem Benutzer dies zu ermöglichen. Verknüpfung mit Wikidata-Item wäre auch angedacht. Im Idealfall hätten wir eine Checkliste, die die Benutzer mit SD befüllen können. Theoretisch würde das den Check danach einfacher bzw. obsolet machen? LG, --Braveheart Welcome to Project Mayhem 08:28, 16. Jan. 2019 (CET)Beantworten
Ist doch illusorisch, dass sich Wettbewerbsteilnehmerinnen aktiv mit dem Ausfüllen der structured data beschäftigen. Will man das, muss nachgearbeitet werden und dazu braucht es die entsprechende Workforce. Verknüpfung mit WD wäre auch angebracht - heißt was beim Bild? Dass, dort wo in WD ein Bild fehlt, dieses unter der Property Bild (P18) eingefügt wird, oder was anderes? lg --Herzi Pinki (Diskussion) 10:23, 16. Jan. 2019 (CET)Beantworten
So wie es von den SD-Verantwortlichen klingt, ist das nicht illusorisch, sofern das Ausfüllen von SD z.B. die Kategorien ersetzt. Momentan wären wir in der Lage (wenn wir morgen beschließen sollten, das das einen Versuch wert ist), dem SD-Team unsere Wünsche und Anforderungen mitzugeben, die diese bis April/Mai umsetzen würden. Im Konkretfall würden mir spontan folgende Anforderungen einfallen:
  • Verwendung von SD statt Kategorien, d.h. Eingabe auf Deutsch und entsprechend benutzerfreundlicher gestaltet - die Kategorien würden sich dann automatisch aus den SD-Werten ergeben
  • Mitgabe von SD-Werten aus der WikiDaheim-Oberfläche für die Bilder
  • Verknüpfung mit dem Image-Property(P18) auf Wikidata. Dafür muss man sich aber erstmal die Datenlage ansehen, bei den Denkmalen wird das sicher net so einfach :-/
LG, --Braveheart Welcome to Project Mayhem 10:57, 16. Jan. 2019 (CET)Beantworten
Die SD-Verantwortlichen versuchen ihr Ding zu pushen. Nach dem Rollout der Captions würde ich denen maximal 50 % glauben. Für dem Ersatz der Kategorien durch SD würde es einen Communityentscheid brauchen, siehe Commons:Commons_talk:File_captions#Category_captions.
Wie würden sich die Kategorien automatisch aus den SD Werten ergeben? Es ist nicht mal klar, ob beides parallel existieren soll oder ob SD die Kategorien ersetzen soll. Und was primär und was sekundär ist.
Wie können wir auf etwas verlinken, was in SD den Kategorien entspricht und in den Tabellen massenhaft als commonscat eingetragen ist?
Die Mitgabe von SD Werten aus der WikiDaheim-Oberfläche für die Bilder: schön und gut, aber wo kommen diese SD-Werte her? Ich erinnere daran, dass auch irgendwelche Bilder mit Themenbezug Österreich hochgeladen werden können. Wie schaut das aus bei vermuteten fehlenden Bildern wie Schulen, Friedhöfen, Sportplätzen, wo wir annehmen, dass praktisch jeder Ort darüber verfügt und wo wir aus dem Fehlen eines Bildes in einer bestimmten Kategorieschnittmenge einen Eintrag in WD machen, aber im Prinzip fast nix über das Objekt wissen (wir vermissen Schulen, aber sind das Volksschulen, Hauptschulen, etc. wissen wir nicht, bei Sportplätzen kann das eine Kegelbahn, ein Fußballplatz oder ein Basketballkäfig sein, WD weiß das nicht)? Aber selbst bei Denkmälern u.a., wo kommen die SD Werte her: z.B. ein naturdenkmalgeschützter Baum bräuchte mindestens einen Ort und eine Species, Public art einen Ort, einen Titel, ein Jahr und einen Künstler (der Künstler steht in den public art Listen, aber es gibt nicht für jeden Künstler eine WD-Eintrag. Wer soll die machen, oft haben wir nur den Namen?), ein Denkmal einen Typ (Schloss, Pfarrhof, Stadtmauer, Bildstock, etc., die Information gibt es nicht strukturiert).
Die Mitgabe von SD Werten aus der WikiDaheim-Oberfläche für die Bilder: wie geht das konsistent bei alternativen Hochlademechanismen (direkt über die Listen, andere Uploader)? Wenn nicht, wer macht die Nacharbeit?
Du überzeugst mich nicht. lg --Herzi Pinki (Diskussion) 11:59, 16. Jan. 2019 (CET)Beantworten
Ich bin nicht hier, um dich zu überzeugen - mir gehts um die Möglichkeiten, die SD bieten würde. Wenn wir morgen draufkommen, dass SD für uns nix bringt, werden wirs auch net machen. --Braveheart Welcome to Project Mayhem 13:43, 16. Jan. 2019 (CET)Beantworten
P.S.: Und ja, wie schon vorher angedeutet, wirds ohne sinnvolle Wikidata-Informationen zu den Objekten wenig für SD zu tun geben. --Braveheart Welcome to Project Mayhem 13:45, 16. Jan. 2019 (CET)Beantworten
Wo sollen die sinnvollen Wikidata-Informationen zu den Objekten herkommen, und wer verbindet die Friedhöfe, Basketballkäfige, Linden und Mosaike mit den entsprechenden WD-Einträgen?
Welche Möglichkeiten bietet SD konkret für Wikidaheim?
Was ich mir vorstellen kann: Jedes Objekt bekommt beim Upload soweit möglich eine oder mehrere Wikidata-IDs und damit implizit alle Properties aus dem entsprechenden Wikidata-Objekt. Die werden aber nicht kopiert, sondern immer direkt von Wikidata abgegriffen. Das würde der Information entsprechen, die jetzt in den Kategorien über die Wikidata Infobox angezeigt wird. Nur so lässt sich mit unvollständigen und fehlerhaften Wikidata-Enträgen arbeiten, ohne millionenfach Nacharbeit an den Bildern. Das sind zwar objektspezifische Properties, keine bildspezifischen Properties (Angaben zu Details, zu Aufnahmedaten soweit sie nicht aus den Exif-Daten eruierbar sind, etc., könnten bildindividuell hinzugefügt werden, aber das wäre ohnehin außerhalb des Scopes von Wikidaheim). Statt Commonscat-Einträgen müsste halt jemand die Wikidata-Einträge zu den Objekten erstellen. Ich fürchte, dass bei der Eingabe von SD über das Hochladeformular die Bedienung ähnlich ist wie bei Wikidata, d.h. jedes Property ist einzeln einzutragen. Verglichen mit einer Schnittstellenkategorie, die mit cat-a-lot mit einem Schritt auf viele Bilder gepickt werden kann, würde die Anzahl der notwendigen Aktionen bei einer Oberfläche a la Wikidata um zwei Ordnungen größer sein (1. viele einzelne SD-Properties statt Schnittstellenkategorie und 2. für jedes Bild extra).
Ich überlege das jetzt um mir vor morgen eine Entscheidung zurechtzulegen. Wenn wir das morgen inhaltlich diskutieren, dann fallen alle anderen Punkte unter den Tisch, oder wir machen open end. Bisher habe ich kein Konzept gesehen, aber nur über ein solches könnten wir entscheiden. lg --Herzi Pinki (Diskussion) 19:41, 16. Jan. 2019 (CET)Beantworten
Nur eine Frage: Ich weiß, ich war bei der Besprechung ja net dabei, aber bietet SD schon tatsächlich eine nachhaltige Lösung als Ersatz für Kategorien, oder ist das ganze ein Pilot, der nächstes Jahr entweder wieder vergessen oder ganz anders ausschaut. Derzeit bin mir nicht sicher, dass das Newbies so zuzumuten ist, dass nicht für die derzeitigen User, die ja nicht unbedingt mehr werden (Herzi Pinki lässt sich ja nicht klonen ;-) mehr Arbeit entsteht, als es erleichtert. --K@rl du findest mich aber hauptsächlich im RegiowikiAT 14:21, 22. Jan. 2019 (CET)Beantworten

Feuerwehrhäuser und andere Themen

Letzter Kommentar: vor 6 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

wenn auch viele wissen, dass Feuerwehrhäuser mein Thema sind, aber vielleicht kann man das noch etwas in der Erklärung ausweiten auf andere Beispiele von öffentlichen Bauten, wie Gemeindehäuser, Schulen, Kindergärten o.ä. - was vielleicht auch ein Thema wäre, sind die 100.000 Kreisverkehre, die für andere ganze Bücher hergeben, warum nicht für uns auch. Nicht nur in NÖ wurden durch erwin viele errichtet, auch in den anderen Bundesländern. --K@rl du findest mich aber hauptsächlich im RegiowikiAT 19:59, 15. Jan. 2019 (CET)Beantworten

Stimmt, danke für den Hinweis :-) --Braveheart Welcome to Project Mayhem 10:58, 16. Jan. 2019 (CET)Beantworten

Uploader mit Anmeldedatum

Letzter Kommentar: vor 6 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt

Hallo und @Raimund Liebert (WMAT): Mit https://quarry.wmflabs.org/query/30382 gibt es jetzt die Uploader zu WikiDaheim 2018 mit Anmeldedatum. Bei einigen alten usern scheint es kein Anmeldedatum zu geben. lg --Herzi Pinki (Diskussion) 16:19, 21. Jan. 2019 (CET)Beantworten

Danke; allerdings scheint es beim Datum nicht anzuzeigen, wann das Benutzerkonto angelegt wurde, sondern wann es erstmals auf Commons aktiv war. Benutzer:Funke ist z. B. schon um Einiges älter als 2007-01-03. --Raimund Liebert (WMAT) (Diskussion) 16:26, 21. Jan. 2019 (CET)Beantworten
Danke für die Kontrolle, ad Funke: https://meta.wikimedia.org/wiki/Special:CentralAuth?target=Funke scheint überhaupt erst am 30. Jun. 2010 aktiv geworden sein. Daten vor 3. Okt. 2008 sein es nicht zu geben: https://meta.wikimedia.org/wiki/Special:CentralAuth?target=Herzi+Pinki. Vor Sul würde ich die Werte auch nicht ernst nehmen. Aber du hast auch Recht, vermutlich handelt es sich um das Datum des ersten Edits auf commons. Auf meta werden nochmals andere Daten geliefert, https://quarry.wmflabs.org/query/32836 als Muster.
Für die neuen Benutzer könnte es aber besser aussehen? Wie kriegst du das raus? --Herzi Pinki (Diskussion) 17:06, 21. Jan. 2019 (CET)Beantworten
Für mich gibt es hier Daten ab 1. Juni 2008 (während ich mit diesem Benutzernamen seit 2. Dezember 2005 auf de aktiv bin). Für meinen alten Benutzernamen gibt es mit 17. März 2015 einen völlig sinnlosen Eintrag, denn das Passwort dieses Benutzers ist mit seit 2006 nicht mehr bekannt. --TheRunnerUp 08:22, 22. Jan. 2019 (CET)Beantworten

Zum frühzeitigen Aussortieren von Bildern in der Vorjury

Letzter Kommentar: vor 6 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt

Wie am 17.1. besprochen, sollen Bilder mit wenigen Punkten frühzeitig aus dem Vorjuryprozess ausgeschlossen werden und weitere Vorlagen eines chancenlosen Bildes vermieden werden. Mathematischer Background dazu:

Ansatz

(1) Im folgenden bezeichnen p die durchschnittlichen Punkte, und P die aufaddierten Punkte eines Bildes. Nach k Bewertungen gilt: 

pk = Pk / k

individuell pro Bild. Im Prinzip sind die aufsummierten Punkte und der Punkteschnitt gleichwertig, der Punkteschnitt erlaubt allerdings eine unterschiedliche Anzahl von Bewertungen pro Bild. Das ist der Grund, warum wir mit dem Punktschnitt arbeiten.

(2) Wir betrachten das Bild, das es als 500. (allgemein L) gerade noch durch die Vorjury geschafft hat. Dieses hatte im Schnitt plimit Punkte. Alle Bilder die die Vorjury überstanden haben, hatten p ≥ plimit Punkte (liegen im oberen Bereich und gehen weiter an die Jury), die anderen p < plimit Punkte (liegen im unteren Bereich und scheiden aus). Nach insgesamt d Bewertungen kann ein Bild, das nach k Bewertungen pk Punkte erhalten hat, d > k, am Ende nur insgesamt 

pk + 5*(d-k)

Punkte erreichen.

Beispiel für d=6, k=2 und plimit=4: In den verbleibenden 4 Durchgängen kann ein Bild maximal noch 4*5 = 20 Punkte erreichen, damit 

(20+P2)/6 ≥ 4

ist, muss 

P2 ≥ 4 (wolframalpha)

sein. Bilder, die nach zwei Runden weniger als 4 Punkte haben, können rein rechnerisch nicht mehr unter die letzten 500 (L) kommen.

(3) Die Anzahl der endgültigen Durchgänge kennen wir nicht im Voraus, hängt von vielen Faktoren ab. Wir wissen aber, dass bisher Bilder sich in der Anzahl der Durchläufe gerade mal um 1 unterscheiden können, weil Bilder, die mit den Bewertungen im Rückstand sind, bevorzugt zur nächsten Bewertung vorgelegt werden. In Ausnahmefällen (etwa wenn alle Bilder mit Rückstand schon vom aktuellen Vorjuror bewertet wurden) kann der maximale Unterschied der Bewertungen je Bild auch größer 1 werden. Wenn wir Bilder frühzeitig nach wenigen Bewertungen ausscheiden, da diese es ohnehin nicht mehr in die Auswahl der Vorjury schaffen, ändert das nichts am Ergebnis der Vorjury, auch wenn der Unterschied in der Anzahl der Bewertungen größer als 1 wird. Ein solcher Unterschied betrifft fast immer ein Bild aus der Auswahl der Vorjury und ein Bild, das es nicht in die Auswahl der Vorjury schaffen würde, auch wenn es die volle Anzahl an Bewertungen und dabei die jeweils vollen 5 Punkte bekommen würde. Fälle, in denen sich die Bilder in der Anzahl der Bewertungen um mehr als 1 unterscheiden, werden hier ignoriert.

Verallgemeinerung

(4) Wir machen die Anzahl der Durchgänge variabel. Sei dmax die größte Anzahl von Bewertungen bei einem der Bilder (nicht die Anzahl vollständiger Durchläufe). Für alle anderen Bilder b gilt: 

db ≤ dmax.

Ein Bild kann in der Situation maximal noch 

dmax − db + 1

Bewertungen bekommen. +1, weil es Bilder gibt, die eine Bewertung mehr haben können als die anderen. Wir nennen die aufaddierten Punkte, die ein Bild nach db = k Bewertungen hat, Pk. Die maximal erreichbaren Punkte für diese Bild bis zum Erreichen der aktuellen Maximalanzahl an Bewertungen ergeben sich dann nach 

(5*(dmax-k)+Pk)/(dmax) ≥ plimit

bzw. bei Überschreiten der aktuellen Maximalanzahl an Bewertungen um 1 zu 

(5*(dmax-k+1)+Pk)/(dmax+1) ≥ plimit

(5) Nach Auflösen der Ungleichung 

(5*(dmax-k+1)+Pk)/(dmax+1) > (5*(dmax-k)+Pk)/(dmax)

ergibt sich mit 

Pk < 5*k (wolframalpha)

eine wahre Aussage, nach k Runden à 5 Punkten kann ein Bild nicht mehr als maximal 5*k Punkte bekommen haben, insoferne muss, um die Chancen eines Bildes auf einen Erfolg in der Vorjury intakt zu lassen, mit der größeren Anzahl an Durchläufen gerechnet werden. Dies ist logisch, da mit fetten 5 Punkten in der max+1 ten Runde die Chancen auf einen Erfolg in der Vorjury steigen.

(6) Also kann o.B.d.A ein Bild in dieser Situation maximal 

(5*(dmax-k+1)+Pk)/(dmax+1)

Punkte erreichen. Ein Bild was damit nicht über plimit kommt, kann vorerst zurückgestellt werden und muss in dieser Situation keiner zusätzlichen Bewertung zugeführt werden.

(7) Ein Bild, das zurückgestellt wurde, kann allerdings bei einer Erhöhung von dmax um 1 wieder in die Vorjury zurückkehren. Dies deshalb, weil ein Bild, das bei dmax Bewertungen maximal noch 

(5*(dmax-k+1)+Pk)/(dmax+1)

Punkte erreichen kann und damit unterhalb von plimit bliebe und nicht bewertet wird, in der nächsten Runde bei dann insgesamt einer Bewertung mehr 

(5*(dmax+1-k+1)+Pk)/(dmax+1+1)

Punkte erreichen kann. Die Ungleichung 

(5*(dmax-k+1)+Pk)/(dmax+1) < (5*(dmax+1-k+1)+Pk)/(dmax+1+1)

ist äquivalent zu 

Pk < 5*k (wolframalpha),

was immer der Fall sein muss (ein Bild kann nach k Bewertungen nie mehr als 5k Punkte haben). Damit muss Bildern die Chance auf eine dmax +1 te Bewertungmöglich gemacht werden.

Algorithmus

Damit ergibt sich folgender Algorithmus. Die größte Anzahl an Bewertungen für ein Bild sei aktuell dmax. Der Grenzwert während eines Durchgangs, um ins Finale zu kommen, ist plimit, der Anfangswert dafür 1 (weniger Punkte gibt es auch im Schnitt nicht). Ein Bild mit aktuell Pk Punkten aus bisher k Bewertungen wird nur dann zur nächsten Bewertung vorgelegt, wenn 

(5*(dmax+1-k)+Pk)/(dmax+1) ≥ plimit

wird. Muss dmax um 1 vergrößert werden, so wird plimit neu berechnet und mit dem neuen Kriterium ein neues Bild ausgewählt.

plimit kann ohne wesentlichen Einfluss jederzeit berechnet werden, es empfiehlt sich aber dies vor der endgültigen Teilung in den oberen Bereich und den Rest jedenfalls zu tun. Invariant ist 

1 ≤ plimit ≤ 5

Für die Punkte je Bild Pk gilt 

k ≤ Pk ≤ 5k

bzw. für neue Bilder (k = 0) als degenerierte obige Ungleichung 

Pk = P0 = 0

Für neue Bilder gilt unabhängig von dmax 

(5*(dmax+1-0)+P0)/(dmax+1) = (5*(dmax+1-0)+0)/(dmax+1) = 5 ≥ plimit

d.h. später eingestiegene neue Bilder bekommen immer eine erste Bewertung. Diese Bedingung gilt auch für den ersten Durchgang (alle Bilder neu).

Im zweiten Durchgang gilt dmax = 2, k = 1, 1 < P1 < 5, es ergibt sich 

(5*(2+1-1)+P1)/(2+1) = (10+P1)/3 = [3.67;5] ≥ plimit

Zu lesen ist das wie folgt: Ein Bild mit einer fehlenden Bewertung im zweiten Durchgang kann je nach den Punkten für die erste Bewertung zwischen 3.67 und 5 Punkten final erreichen. Je nach plimit reicht das für die Vorlage zur nächsten Bewertung. Ist plimit = 4, so werden Bilder mit P1 = 1 nicht vorgelegt (max. 3.67 erreichbar), während Bilder mit P1 ≥ 2 (ergibt mindestens 4) vorgelegt werden. Das Bild mit dem bisher einen Punkt kann aber im dritten Durchgang wieder vorgelegt werden, dmax = 3, k = 1, 1 < P1 < 5, es ergibt sich 

(5*(3+1-1)+P1)/(3+1) = (15+P1)/4 = [4;5] ≥ plimit

Eigenschaften

  • Je weniger Punkte ein Bild hat, d.h. je schlechter es bisher bewertet wurde, desto eher wird es nicht mehr vorgelegt.
  • Auch schlechte Bilder werden mit zunehmender Anzahl von Durchgängen ev. wieder vorgelegt, aber insgesamt weniger oft als gute Bilder. Dies kann dazu führen, dass in bestimmten Abschnitten der Vorjury ein Block schlechterer Bilder zur Bewertung vorgelegt wird.

Implementierung

Ich würde mir eine begleitende Statistik über die Bewertungen je Bild wünschen, braucht keinen Bildbezug. Ein Tupel pro Bild mit den Bewertungen in ihrer Reihenfolge reicht aus, etwa (1,2) für ein schlechtes und (4,5,4,3,5) für ein gutes Bild. Insbesondere brauchen wir ein Gefühl für die Einsparung an Bewertungen im realen Betrieb.

Kritik, Diskussion

Ich bitte Menschen mit mathematischem Verständnis meine Überlegungen nachzuprüfen, mein Vorschlag wäre hier zu kommentieren und ausnahmsweise nicht oben im Text. Ich habe jetzt keine Abschätzung, was das an Einsparungen bringt. @Ruben Demus: wäre das so umsetzbar? lg --Herzi Pinki (Diskussion)

Hab mal manuell die Tupel für die Gewinnerbilder rausgesucht.
(4,4,3,3,3,3,3) 3,29
(5,4,4,3,3,1) 3,33
(5,5,4,3,2,1) 3,33
(4,4,4,4,3,1) 3,33
(5,4,3,3,3,2) 3,33
(4,4,3,3,3,3) 3,33
(5,4,3,3,3,2) 3,33
(5,4,4,3,3,3,2) 3,43
(4,4,4,3,3,3) 3,50
(5,5,4,4,3,2,2) 3,57
(5,4,4,3,3,3) 3,67
(4,4,4,4,3,3) 3,67
(5,4,4,4,4,3,3) 3,86
(5,5,5,5,4,4,4) 4,57
Je nach Reihenfolge der Bewertungen und Schlüssel zur Teilung könnten (5,5,4,3,2,1) und (5,5,4,4,3,2,2) problematisch werden. --Ruben Demus (Diskussion) 13:24, 22. Jan. 2019 (CET)Beantworten
Danke für die konkreten Zahlen, ich jag sie mal durch Excel Open Office Calc. Mich wundert der große Abstand in der durchschnittlichen Bewertung, hatte da eine andere Fantasie von eher dicht beinander liegenden Schnitten. Einigkeit bei der Bewertung (±1) ist eher die Ausnahme als die Regel. Sogar 5 & 1 kommen zweimal gemeinsam vor. lg --Herzi Pinki (Diskussion) 17:42, 22. Jan. 2019 (CET)Beantworten
Mein angepasster Algorithmus oben, der ohne Ausscheiden nach einer fixen Anzahl Runden auskommt, sollte das aber schaffen. Ein Bild, das mit Bewertungen 1 und 2 beginnt, würde vermutlich nicht zur 3. Runde vorgelegt werden, auch nicht zur 4. Sondern bei 2 Bewertungen verharren. Wird nach 3 Bewertungen abgebrochen, ist das Bild zu recht draußen. Bei der 5. Runde (das Bild mit 3 Punkten aus 2 Bewertungen ist jetzt mögliche 3*5 Hoffnungspunkte im Rückstand, wird es wieder vorgelegt und ist mit 5 Punkten weiter im Rennen, mit 1 Punkt aber für weitere Runden draußen. Es werden nur Bilder ausgeschlossen, die es auch theoretisch nicht mehr schaffen können über plimit zu kommen. Aber ich spiel noch mit den Zahlen, um das auch praktisch zu untermauern. lg --Herzi Pinki (Diskussion) 17:52, 22. Jan. 2019 (CET)Beantworten
Wenn es darum geht, dass sich nicht jeder Vorjuror alle Bilder anschauen 'muss' (Öfter als 1x kann ein Bild ja pro Person ohnehin nicht bewertet werden.): Sollte die Logik für 'schlechte Bilder' nicht umgekehrt auch für 'gute Bilder' angewendet werden? --Ruben Demus (Diskussion) 19:43, 22. Jan. 2019 (CET)Beantworten
Gute Idee, werde das nochmals für den oberen Bereich überlegen. Die 500 besten Bilder der Vorjury, nur zur Sicherheit, kommen ja ohne diese Wertungen, also unsortiert, zur Vorjury. lg --Herzi Pinki (Diskussion) 11:32, 23. Jan. 2019 (CET)Beantworten
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:WikiDaheim&oldid=184992629“