Massenhaft Nonsens-Logs - Rückfrage einbauen?

[following]

Threadtitel geändert von "Massenhaft Nonsens-Logs - sollte das Supportteam hier eingreifen können?" in "Massenhaft Nonsens-Logs - Rückfrage einbauen?"

---

Drei Beispiele aus den letzten Wochen:

- Bei einem User spinnt OCprop. Das Ergebnis: mehrere dutzend identische Logs mit falschem Datum. Der Benutzer korrigiert die Logs trotz Rückfrage nicht.

- Ein Benutzer loggt bei mehreren dutzend Caches "vor langer Zeit bei GC gefunden", alles mit heutigem Datum und ohne weiteren Text. Auf eine Rückfrage reagiert er nicht.

- Ein User loggt bei zahlreichen Caches nur das Wort "gefunden", obwohl er sich offentlichtlich nie gesucht hat (z.B. Webcams ohne Foto etc., Caches bei denen weitere Aufgaben gelöst werden müssen etc.).

Leider prüfen nur wenige Owner die Logs; viele sind auch einfach inaktiv. Das Ergebnis ist dann, dass der Unsinn massenhaft Fundhistorien zerstört. Gerade bei Caches, die nur selten gesucht werden kann das sehr stören - der Cache existiert womöglich seit Jahren nicht mehr, und es sieht aus als wäre alles ok.

Klar: Grundsätzlich kann man loggen wie und was man will, und es ist Sache der Owner wie es in den Loghistorien ihrer Caches aussieht. Auf der anderen Seite leidet die Qualität der Cachedatenbank darunter, und zahlreiche Cacher werden in die Irre geführt. Und solche Massen-Nonsense-Logs lassen sich mit minimalem Aufwand automatisch aufspüren.

Wäre es sinnvoll, dass der OC-Support hier - nach Prüfung und Anschrieb des Loggers - auf einen Knopf drücken und die Logs entsorgen kann? So wie er ja auch Unsinn-Cachelistings sperrt?

[flopp]

Dieser Libelle-Typ ist mir auch schon negativ aufgefallen. Ich kann mir keinen Grund vorstellen, warum der - offensichtlich händisch - so einen Blödsinn loggt.

Du hast Recht, die Qualität der DB leidet darunter. Log-Löschen durch den Support kann ich mir trotzdem nur schwer vorstellen.

[mic@]

Ich bin auch für ein Aufräumen, allerdings eher so:

Falls ein Benutzer Unsinn loggt und auf eine Anfrage von uns nicht reagiert,
dann setzen wir den User auf "blockiert". Und wenn man dann noch implementiert,
daß Logs von blockierten Usern nicht angezeigt werden, ist alles wieder im Reinen.

Gleichzeitig sollte durch diese Blockade der User beim login einen Hinweis sehen
mit der aktuellen Support-Anfrage und der Bitte, diese zu beantworten. Dies ist
auch das Einzige, was er im eingeloggten Zustand sehen kann. Es sind also keine
weiteren Unsinn-Logs von seiner Seite möglich.

[4_Vs]

Hiho,

ich bin absolut dagegen in Logs einzugreifen. Das System muss sich selbst regulieren und reglementieren - es kann in meinen Augen nicht sein, dass wir jetzt auch noch in Logs eingreifen - egal ob Kurzlog, Schwachsinnslog oder falscher Zeitstempellog - wir bewegen uns zwar entwicklungstechnisch immer mehr in Richtung Open - aber inhaltlich bewegen wir uns mit solchen Maßnahmen Richtung "closed" bzw. "Zensur/Überwachung" ...

just my personal 2 cents ...

[erdbot]

[quote="4_Vs"]
Hiho,

ich bin absolut dagegen in Logs einzugreifen. - egal ob Kurzlog, Schwachsinnslog oder falscher Zeitstempellog -
[/quote]

+1

[Steingesicht]

so lange irgendwelche Logs nicht gegen Recht und gute Sitten verstossen (Beleidigung etc.) sollte da m.M.n. auch nicht eingegriffen werden - Der Rest ist Owner-Aufgabe.

[doglobe]

[quote="erdbot"]
[quote="4_Vs"]
Hiho,

ich bin absolut dagegen in Logs einzugreifen. - egal ob Kurzlog, Schwachsinnslog oder falscher Zeitstempellog -
[/quote]

+1
[/quote]

+1

[following]

Schade, aber ich kann eure Argumente nachvollziehen.

Spricht denn etwas dagegen, eine Sperre gegen das massenhafte Einstellen identischer Logs per Ocprop einzubauen? Diese Ocprop-Amokläufe sind das größte Problem.

[4_Vs]

[quote="following"]
Schade, aber ich kann eure Argumente nachvollziehen.

Spricht denn etwas dagegen, eine Sperre gegen das massenhafte Einstellen identischer Logs per Ocprop einzubauen? Diese Ocprop-Amokläufe sind das größte Problem.
[/quote]
Hmmm,

meinst Du so etwas wie: Es ist nur ein Log / 30 Sekunden möglich?

LG
Micha

P.S.: Wenn jemand meint jden Kommentar mit "gefunden" dokumentieren zu wollen und mehr nicht, so ist dies auch sein gutes Recht. Ob der jetzt die 30 Logs mit dem gleichen Wortlaut per OCprop macht oder manuell spielt dabei eigentlich keine Rolle, oder?

[Steingesicht]

gegen eine amoklaufendes-OCprop-Sperre finde ich nix einzuwenden. Der verursacher sollte dann aber auf jeden Fall irgendwie eine Meldung bekommen, damit er es merkt und abstellen kann.

[Schrottie]

[quote="following"]
Spricht denn etwas dagegen, eine Sperre gegen das massenhafte Einstellen identischer Logs per Ocprop einzubauen? Diese Ocprop-Amokläufe sind das größte Problem.
[/quote]

Kann man denn erkennen, ob da ein Automat läuft? Denn wenn das sicher erkennbar ist, spricht IMHO nichts dagegen.

[following]

[quote="Schrottie"]
Kann man denn erkennen, ob da ein Automat läuft? Denn wenn das sicher erkennbar ist, spricht IMHO nichts dagegen.
[/quote]

Ocprop meldet sich als User Agent "Ocprop" - das wird bereits ausgewertet, damit Ocprop keine Nanos zu Micros macht.

https://github.com/OpencachingDeutschla ... c.php#L245

[quote="4_Vs"]
meinst Du so etwas wie: Es ist nur ein Log / 30 Sekunden möglich?
[/quote]

So ähnlich: maximal 30 identische Logs pro Tag z.B.

[quote="4_Vs"]
P.S.: Wenn jemand meint jden Kommentar mit "gefunden" dokumentieren zu wollen und mehr nicht, so ist dies auch sein gutes Recht. Ob der jetzt die 30 Logs mit dem gleichen Wortlaut per OCprop macht oder manuell spielt dabei eigentlich keine Rolle, oder?
[/quote]

30x "gefunden" am gleichen Tag ist schon sehr ungewöhnlich. Ok, bei nem Powertrail macht sogar das Sinn. 

[following]

Gestern hat mal wieder jemand 100 OC-Cachehistorien mit GC-Nachlogs zerstört, alle mit identischem Datum und dem Text "Auf gc.com schon vor einiger Zeit gefunden, jetzt hier der Nachlog."

Ich möchte nochmals einen Anlauf machen, um das Problem in den Griff zu bekommen. Vorschlag: Nach 20 identischen Logs mit identischem Datum erscheint bei weiteren identischen Logs eine Rückfrage, die bestätigt werden muss. Der User wird darauf hingewiesen, dass jeweils das Datum des (Nicht-)fundes eingetragen werden sollte, und beim Kopieren von Logs der Originaltext. Das aktuelle Datum wird bei weiteren Logs nicht mehr vorgeschlagen, sondern der User muss immer ein Datum von Hand eingeben.

Dazu einer Erklärung, dass sonst die Cachehistorie beeinträchtigt und damit weitere Cacher und der Owner irritiert werden. Außerdem funktioniert die Suchsortierung nach letztem Log nicht mehr, ebeno wie geplante Filterfunktionen nach letztem Logdatum und die geplante "Dornröschen-Funktion".

[Schrottie]

Wenn sich das schnell und einfach umsetzen lässt, nur zu. Das dürfte ja auch im sind der Owner sein.

[4_Vs]

Hiho,

ich bin da immer gespaltener Meinung, da ich nicht genau beurteilen kann, warum jemand die Cachehistorien durcheinander bringt.

1. Jemand sammelt Logs so lange, bis es sich für ihn "lohnt" bei OC nachzuloggen
2. Jemand möchte von GC zu OC wechseln, möchte aber nicht bei Null anfangen

Erster Fall wäre mir die "Fehlermeldung" bzw. die Auffirderung mit richtigen Datum etc. zu loggen auch egal, im zweiten Fall jedoch würden wir den User direkt vergraulen, weil er vielleicht keine Lust hat das alles händisch zu übertragen - ihm der Zeitpunkt des Fundes egal ist, er aber wissen möchte, welche Caches er schon gefunden hat.

Mich zum Beispiel stört es recht wenig, wenn jemand mit falschem Datum einen Nachlog macht, warum auch? Ich mache eh regelmäige Cachekontrollen und bei OC ist auch ein Nachlog für mich ein Ereignis

Ich möchte aber keinen davon abhalten sich programmiertechnisch da auszutoben, allerdings sollten man sich vielleicht in einem kleinen Team mal genau Gedanken machen, wie was möglich ist und was für eine Außenwirkung das ganze hat ...

Das ist nur meine Meinung als Teammitglied und rein persönlich ...

LG
Micha