Wikipedia Diskussion:WikiDaheim

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Exclamation.svg
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.


Qualidade-5-.svg
Nützliche Links:
Archivübersicht Archiv

2017, 2018

Wie wird ein Archiv angelegt?
Automatische Archivierung
Auf dieser Seite werden Abschnitte automatisch archiviert, die seit 3 Tagen mit dem Baustein {{Erledigt|1=~~~~}} versehen sind.
Automatische Archivierung
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[Quelltext bearbeiten]

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/20Simon04 (Diskussion) 17:30, 10. Aug. 2017 (CEST)

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

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)

Media from WikiDaheim 2017 in Austria needing check (after)[Quelltext bearbeiten]

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)

Relative Anzahl hochgeladener Bilder[Quelltext bearbeiten]

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)

Glückwunsch[Quelltext bearbeiten]

Liebe Mitstreiter des Projektes WikiDaheim,

ihr wurdet für die WikiEule 2018 in der Kategorie:KulturEule nominiert. Wir möchten euch sehr herzlich zu eurer Nominierung gratulieren und haben euch ein EulenBabel mitgebracht. Gleichzeitig möchten wir euch für eure Arbeit in der Wikipedia sehr herzlich danken.

St.Gallen Stiftsbezirk WikiEule 04 (cropped).jpg Ich wurde für die KulturEule 2018 nominiert.

Beste Grüße, Eure --WikiEulenAcademy Bagoly 2 vonallal.png 23:10, 7. Okt. 2018 (CEST)

Dieser Abschnitt kann archiviert werden. --Braveheart Welcome to Project Mayhem 21:04, 16. Jan. 2019 (CET)

Grundsätzliches nach WD 2018, aber für ev. WD 2019[Quelltext bearbeiten]

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)

Neue Denkmalbilder 2018[Quelltext bearbeiten]

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)

Inhaltliche Frage zu TDD[Quelltext bearbeiten]

@(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)

Statistik TdD 2018[Quelltext bearbeiten]

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)

Neue Naturdenkmalbilder 2018[Quelltext bearbeiten]

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)

Neue Public Art 2018[Quelltext bearbeiten]

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

Ergebnisse Vorjury[Quelltext bearbeiten]

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)

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

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)

  • 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
  • --doppelt gebucht :-( --K@rl du findest mich aber hauptsächlich im RegiowoikiAT 10:32, 9. Jan. 2019 (CET)

Vergleich Vorjury WD AT mit WLM DE[Quelltext bearbeiten]

@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)

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)
Den Mehrtagesmarathon gab es trotzdem. --Ailura (Diskussion) 09:25, 9. Jan. 2019 (CET)
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)
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)
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)

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)

Structured data[Quelltext bearbeiten]

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)

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)

@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)

@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)
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)
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)
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)
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)
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)
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)

Feuerwehrhäuser und andere Themen[Quelltext bearbeiten]

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)

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