Community-Browser
abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du: 

Zugriff zum Board "Bugs in der Community" für alle Ränge

Sind Sie kein Privatkunde? Dann geht's hier zur Business Community
Aktueller Hinweis
Ihr habt Fragen oder Feedback zur Ideenschmiede? Stellt sie unserem Experten in diesem Beitrag!
Unsere Community hat Zuwachs bekommen: Herzlich willkommen an alle QIVICON Community Nutzer!
Die Versteigerung der 5G-Lizenzen ist vorbei. Nutzt die Gelegenheit und stellt Chris Hab. von unserer Unternehmenskommunikation eure Fragen zum Thema 5G hier.

Zugriff zum Board "Bugs in der Community" für alle Ränge

Der Zugriff zum Board "Bugs in der Community" wurde mit der Einführung im April 2018 nur Mitgestaltern und Guides eingeräumt.

 

Der letzte signifikante Fehler mit den ausbleibenden oder verspäteten Benachrichtigungen hat deutlich gemacht, dass auch die Mitgliederränge Zugriff zu diesem Board haben sollten. Es kommt zu Irritationen, weil Zugriffsberechtigte nicht Berechtigte auf dieses Board verweisen, womit diese dann überhaupt nichts anfangen können:

https://telekomhilft.telekom.de/t5/Fragen-zur-Community/Keine-neuen-Nachrichten-im-Benachrichtigungs...

 

Bugs können alle treffen und geniessen ja wohl nicht unbedingt eine hohe Vertraulichkeit, die den Ausschluss der unteren Hierarchiestufen rechtfertigt.

 

VG kws

 

 

Status: Abgelehnt

Hallo zusammen,

 

zuerst einmal danke @kws für deinen Vorschlag. Wir haben diesen Vorschlag eine Zeit lang beobachtet und auch im Team darüber Gedanken gemacht, da auch wir zuerst nicht eine klare Meinung hatten. Wir haben uns jetzt aber entschieden, den Vorschlag nicht umzusetzen und das Bug-Board weiterhin nur Mitgestaltern und Community Guides zugänglich zu machen. 

 

Sicherlich gibt es ab und zu Themen, die auch von Nutzern der Rolle "Mitglieder" gemeldet werden. Das passiert aber relativ selten. Die meisten Bugs werden von Mitgestaltern und Community Guides gemeldet. Ihr kennt auch viel besser mit der Community aus. Euch fallen Fehler eher auf als neuen Mitgliedern. Unsere Sorge ist, dass durch das Öffnen des Bug-Boards für alle Nutzer, dieser Bereich unübersichtlicher wird. Z.B. wünschen wir uns, dass Fehler anhand des Templates gemeldet werden, damit wir diese besser nachvollziehen können und damit wir sie auch leichter lösen können. Es gibt jetzt auch schon Mitgestalter und Community Guides, die sich beim Melden von Bugs nicht immer an das Template halten. Von neuen Nutzern können wir das noch weniger erwarten. Außerdem landen in diesem Board dann auch wieder Beiträge, die hier nicht hingehören (z.B. Störungen). Darum belassen wir es vorerst so wie es ist. 

 

Liebe Grüße

Mi C. und Waldemar H.

 

Kommentare

Lieber @kws,

 

ich stimme Dir absolut zu. Vorausgesetzt, es ist nicht streng geheim, bin ich immer dafür, Kunden den Zugang zu allen Kategorien zu erleichtern. Nur so bekommt die ThC neue Impulse.

 

Bevor Du mich nicht geduldig ins Testgelände einführtest, hatte ich keine Ahnung, dass es noch weitere interessante Kategorien gibt. Ich war froh, wenn ich mich erfolgreich auf der ThC eingeloggt hatte und die Kategorie für meine Frage gefunden hatte, was mir gelegentlich misslang.

 

Liebe Grüße

Marlise

 

Ich sehe hier schon einen Sinn. 

Wenn jeder dort schreiben könnte, würde alles doppelt und dreifach kommen. 

Auch würde es nicht lange dauern, bis erste Störungen gemeldet werden Zwinkernd 

 

Es macht sinn, nur den Kern darauf zugreifen zu lassen. 

@Kugic,

 

>Wenn jeder dort schreiben könnte, würde alles doppelt und dreifach kommen.

 

Hier im Board "Vorschläge für die Community" kann auch jeder schreiben. Manches kommt dann doppelt, dreifach oder noch häufiger.

Dabei sind hier doch überwiegend Mitgestalter und Guides tätig. Da sind wohl weniger die unteren Ränge dafür verantwortlich.

 

Hallo Kugic,

> Es macht sinn, nur den Kern darauf zugreifen zu lassen.

Sehe ich genauso.

Grüße
gabi

Durch Zufall geriet ich an einen unübersichtlichen Thread.

Da schrieben fast ausschließlich “höhere Ränge.“

 

Das ist aber nur ein Beispiel. Es gibt auch mehr als 40ig-seitige Threads, auf die doppelt und dreifach geantwortet wurde und oftmals am Thema vorbei und fast ausschließlich verfasst von “höheren Rängen.“ Momentan finde ich kein Beispiel dafür.

 

Viele Grüße

Marlise

Zusammenfassung meines Vorschlags in dem Zusammenhang (kurze Version):

Gestufte Rechte im Bord Bugs je nach Mitgliederrang. Schreib- und Leserechte für alle Thread-Statusarten ab Mitgestalterrängen, Lese- und Kommentarrechte abhängig vom Userrang (Mitglieder oder niedriger) abhängig auch vom Threadsstatus (Neu, Offen) ab einem bestimmen Mitgliederrang. Für Mitgliederränge als Schreibrechte höchstens nur Kommentarrecht. Leserechte auf die Threadstatusarten Neu und Offen auch für die niedrigsten Ränge. Soweit so eine Unterscheidung machbar.

 

Alternativ zwei getrennte Bords mit unterschiedlichen Rechten je nach Rang. In dem einen Bord "Aktuell" Neustart von Threads nur durch Mitgestalter und CGs möglich. In dem Bord Lese- und Kommentarrechte für alle Grade. In dem zweiten Bord "Überholt" nur Lese- und Kommentarrechte ab einem bestimmten Userrang. CMs verschieben Thread von "Aktuell" zu "Überholt" erst nach einem Zeitpuffer, nachdem sie dort den Status der Meldungen von "Neu" oder "Offen" in "Erledigt", "Doppelt", ... geändert haben, so dass man die Chance als Leser hat die Änderung mitzubekommen und gegebenfalls die Begründung der Änderung zu lesen. Denn wenn in dem anderen Bord "Überholt" nicht alle Ränge Leserechte haben, dann sollte man ihnen die Chance eine gewisse Zeit lang in dem Bord lassen, wo sie es können.

 

Bug Report Template-Thread (falls zwei getrennte Bords in "Akutell"Bord) wird überarbeitet.

  • Falls getrennte Bords eingeführt werden und/oder unterschiedliche Schreib- und oder Leserechte nach Rang oder Bord, das dort kurz erwähnen und zu einer ausführlicheren Erklärung im Hilfe-Wiki verlinkt  (bezüglich Schreib-, Leserechte je nach Rang und oder Bord extra für die Bugmeldungen). Restliche Punkte hier auch, falls keine getrennten Bords.
  • Muster einer vorbildhaften Meldung wird dort als Screenhot abgebildet.
  • Hinweis, was das in dem Code-Fenster ist, und dass man es als Makro speichern soll, um damit selbst eine Meldung nach dem Muster erstellen zu können.
  • Erklärung, wie man so etwas in ein Makro bekommt (z. B. wo in den Benutzereinstellungen etc) und wie man dann das Makro aufrufen kann, als Hinweis mit Verlinkung. Es sollte also das am besten noch im Bug Report Template oder an anderer Stelle näher ausgeführt werden, damit es nicht an der Hürde scheitern kann.
  • Inhalt des HTML-CodeFeldes für Anwender optimiert, welche z. B. mit dem Handy unterwegs sind.

Im Hilfe-Wiki Hinweis auf Bug-Threads mit Erklärungen und gegebenfalls Verlinkungen.

 

Bisherige Meldungen, welche bisher nur teilweise oder gar nicht dem Bug Report Template entspricht werden je nach Abweichung von der Vorlage durch CMs nachbearbeitet, dass Leser später nicht diese Mängel abkupfern, weil sie  das so gelesen hatten (wie sollte man es nicht machen, z. B. einfach die Punktbezeichnungen weggelassen hat oder fett und nichtfett der Schrift kein Unterschied war), also nicht unbewusst nachahmen. Oder die CMs fordern die Autoren auf, dass sie die Meldung nochmals schreiben, und dieses Mal gemäß Bug Report Template. Und danach werden die vorherigen Meldungen mit "Doppelt" versehen, und oben ein Kommentar durch die CMs eingefügt, dass eine strukturierte neue Meldung hierfür existiert mit Verlinkung dort hin. Die Kommentarfunktion dieser Meldungen ohne diese Struktur wird dann nach Erstellung des neuen strukurierten Threads geschlossen. Ein Link zum vorherigen Thread ggf eingebaut. Kommentiert soll dann in der neuen Meldung werden, welche dann auch von den CMs mit dem jeweiligen richtigen Status versehen (z. b. "Erledigt") und demgemäß anschließend weiter normal behandelt würde.

 

Einiges davon nun ausführlicher:

Spoiler

Schreibrechte erst ab bestimmten Userrängen. Es tun sich sogar Mitgestalter mit etwas mehr Forumserfahrung als Mitgliederränge schwer hier Meldungen zu schreiben, welche es den CMs erleichtern (und anderen Mitlesern) diese Meldungen nachvollziehen zu können.

 

Das Bug Report Template, welches extra von Waldemar gepostet wurde, damit eine struktierte Meldung erfolgt, welche er gezielt weiter reichen kann, wird von den Meldern bisher teilweise gar nicht angewandt. Oder sehr frei interpretiert, einfach mal was weggelassen oder geschoben, Punktebezeichnungen als Ordungssystem nicht integriert, ... . Es ist also schon anscheinend für die Leute mit etwas mehr Forumserfahrung schwer, das in georneter Weise festzuhalten.

 

Ein Grund für das Bug Template ist, so scheint es mir, dass man nicht x Beiträge untereinander stehen haben soll, über welche in einem Frage-Antwort-Spiel die Leser oder die meldenden CMs erst heraus bekommen sollen, was ist Sache. Es soll den Fokus auf das Wesentliche richten. Es ist zwar mühevoll, sich an eine vorgegebenen Struktur zu halten, erleichtert es aber allen anderen, wenn man sich die Mühe macht, den Inhalt besser sich erschließen zu können. Durch den Punktekatalog kann es auch weniger passieren, dass man etwas weglässt, was die CMs für die Meldung an die Programmierer der Seiten brauchen.

 

Es würde für mich Sinn machen, dass man aber den Lesezugriff (nicht den Schreibzugriff) etwas nach unten öffnet. Erstens könnte man manche Bugs direkt verlinken. Wenn es ein Mitglied ist, dem ich etwas schreibe, mache ich so etwas in der Regel nicht, da ich den fehlenden Zugriff im Hinterkopf habe. Und es gibt durchaus einige User hier, welche das Bug Report Template sinngemäß so anwenden, wie es gedacht ist. Anhand dieser Beispiele können dann die niedrigeren Ränge lernen, wie man so etwas formulieren sollte. Und wenn sie selbst mal den Rang zum Schreiben haben, durch diese Leseerfahrung mit etwas weniger Unsicherheit an die Sache herangehen.

 

Da man sich aber auch schlechte Anwendungen abschauen könnte (nicht gemäß Bug Report Template angewandte Meldungen), bin ich dafür dass die Schreiber a) entweder eine Auffordung dazu erhalten, dass sie das neu machen gemäß Bug Report Template. Und man dann die alten Meldungen mit dem Kennzeichen "doppelt" versieht. Und zudem ganz oben in der Meldung einen Kommentar notiert, fett geschrieben, damit es auffällt oder in Farbe, dass diese Meldung nochmals überarbeitet wurde, so dass sie dem Ordnungssysem Bug Report Template vollständig entsprechen. Dabei den Begriff "Bug Report Template" verlinken zu dem entsprechenden Thread. Und zusätzlich als Kommentar ganz oben, dass man die neu strukturierte Meldung nun dort finden würde: .... (mit Link dort hin). Die Kommentarfunktion ggf in den auf diese Weise erledigten Meldungen schließen. Kommentiert soll dann in den musterhaften Meldungen werden, welche statt dessen geschaffen wurden.

 

Oder b) die CMs bearbeiten die Meldungen in dem Sinne nach, wie es der Struktur eintsprechen würde, inklusive Einfügen der Teilüberschriften, welche manche trotz  Kennens des Bug Report Template Threads einfach weg gelassen hatten. Ich finde, die Meldungen lesen sich deutlich schlechter, wenn die Überschriften nicht vorhanden sind.

 

Die Nachbearbeitung könnte je nach Falllage individuell wie a und/oder b gelöst werden.

 

Dadurch (u. a. aus Möglichkeit a) lernen Mitleser sogar aus vorher nicht entsprechend verfasster Meldungen, dass man es nicht so sondern so machen soll. Können also alleine durchs Mitlesen auch mitbekommen, dass es das Bug Report Template gibt und wie man es anwenden sollte. Und wenn sie selbst mal dort Schreibrechte haben, dann mit höherer Wahrscheinlichkeit das eher hinbekommen.

 

Vielleicht könnte Waldemar oder Mi in dem Bug Report Template Startbeitrag auch noch manches optimieren. Beispielsweise sich einen Thread von denjenigen aussuchen, welche ihrer Meinung nach dieser Struktur entsprechen und in der Anwendung ein Vorbild sein könnte. Und dann in dem Startbeitrag des Bug Report Template ein Screenshot davon als Muster einfügen.

 

Die HTML-Befehle, welche in dem Codefenster des Bug-Template-Beitrags stehen, könnte weiter optimiert werden.

 

Mir ist beispielsweise aufgefallen, dass es zwar Sinn macht, dass die Ordnungspunkte fett geschrieben sind, aber dann es wenig Sinn macht, wenn die  Angaben dahinter (welche der Melder machen soll) auch in fetten Schriftlettern erfolgen. Man könnte hierbei also mit ein paar Leerzeichen, ab denen das Schriftbild im HTML-Code dahinter wieder auf nichtfett umgestellt wird, es den Anwendern leichter machen. Insbesondere die Leute, welche das Bug Report Template mit dem Instrument Phone nutzen, werden sich freuen, wenn sie sich nicht auf Umformatierungen kümmern müssen.

 

Eine andere Idee wäre, dass es sogar Felder mit feinen Linien sind (in einer Art Tabelle) in dem HTML-Code gibt, den man sich in seine Makros bauen kann, welche dort mit eingebaut sind. und in den Feldern, wo die Leute ihre Angaben machen, von vornherein eine andere Formatierung der Schriftzeichen vorhanden ist. Falls es möglich ist, Felder so festzulegen, dass sie sich in der Höhe je nach Inhalt anpassen werden.

 

Da man sich am leichtesten tut, wenn man es als Makro einbaut und nicht jedes Mal frisch kopiert, wenn man es braucht, bietet es sich an entweder in einer Antwort oder in einem extra Thread zu erklären, wie man einen HTML-Code in ein Makro bekommt. Am besten mit Schrittanleitung und Bildern. Das könnte man dann auch im Startbeitrag des Bug Report Template verlinken. Ein Muster einer vorbildhaften Meldung wird im Bug Report Template Thread abgebildet.

 

Sind nur ein paar Ideen dazu.

 

Nun zurück zur Zugriffsmöglichkeit "Leserechte für niedrigere Ränge".

Mag sein, dass es gegen eine Regel geht, dass alle User darauf Zugriff bekommen. Kann ja sein, dass sich manche Leute nur deshalb anmelden, um negative Infos zu sammeln und nicht, um hier mitzumischen. Wenn diese Leute selbst wenig hier schreiben, werden sie weniger in die Ränge rutschen ab wann man dort mitlesen könnte. Das könnte auch ein Grund dafür sein (reine Spekulation von mir), dass das nicht nach unten vollständig geöffnet wird.

 

Ein anderer Grund könnte sein, dass sie Übersichtlichkeit in dem Bord Bugs etwas gewöhnungsbedüftig ist, da anders sortiert z. B.. Wenn man aber nur die aktuellsten Sachen angezeigt bekommen würde als niedriger Rang kommt man damit auch besser klar, da es einfach nicht mehr so viel ist, wo man drüber lesen muss, als wenn man alles schon mal Geschriebenen angezeigt bekommt. Dass man unten auf die Status-Arten Neu oder Offen klicken könnte, werden gerade Frischlinge oder Selten-Nutzer nicht gerade schnell heraus finden. Oder dass man oben etwas umsortieren könnte. Mit weniger ausgewählten Meldungen kommen auch sie besser klar.

 

Deshalb noch eine weitere Anregung von mir, falls das mit der Forumssoftware überhaupt machbar wäre: die niedrigsten Ränge erhalten nur Lesezugriff auf Bug-Meldunge, welche mit Neu oder Offen gekennzeichnet sind. Höhere Mitgliederränge können zusätzlich auch Erledigt oder Umgesetzt oder Abgelehnt oder Doppelt Meldungen sehen, so dass sie durch Mitlesen für das spätere eigene Erfassen daraus lernen können. Schreibrechte erst ab Mitgestalterrängen. Und dann auch Leserechte für restliche Punkte wie Archiviert.

 

Falls man innerhalb eines Bords nicht nach Threadstatus verschiedene Leserechte einräumen kann, aber zumindest nach Mitgliederrang, könnte man das Problem mit mindestens einem zweiten Bord umgehen.

  • Neue Meldungen werden im Bord "Aktuelle Bugs" (oder so ähnlich) gemacht, dort hat man als Mitgestalter und CG auch bezüglich von Neustarts von Threads Schreibrechte, und dort befindet sich dann das Bug Report Template mit Status neu. Die niedrigeren Userränge haben nur Kommentarschreibrechte oder gar keine (ggf je nach Rang). Die Threads dort haben normalerweise entweder den Status "neu" oder "offen". Und falls etwas sich kurzfristig erledigt hat oder umgesetzt oder doppelt, dann für eine Woche bis vier auch der Status "erledigt" oder "umgesetzt" oder "doppelt". In dem Bord haben alle Ränge Leserechte. Dann kann man jedem die neuen akutellen Meldungen oder offenen Meldungen verlinken.
  • Im Bord "Historische Bugmeldungen" oder "Alte Bugmeldungen" oder "Überholte Bugmeldungen" kommen alle anderen Statusarten hinein (doppelt, archiviert, erledigt oder umgesetzt oder dopplelt nach gewisser Wartezeit, abgelehnt, ...).Bei bestimmten Status-Typen lassen die CMs die Threads vorübergehend nach der Umstellung auf den Status im "Aktuelle Bugs"-Bord, damit man es noch kurzfristig mitbekommen und nachlesen kann, wenn es eine Statusänderung gab. Nach dieser Wartezeit von 1 bis 4 Wochen verschieben sie diese Threads in das Bord "Historische Bugmeldungen". Mitgestalter und CGs haben dort nur Lese- und Kommentar-Schreibrechte (nicht für Erstellung neuer Threads). Nur bestimmte Mitgliederränge (ab höherem Grad) oder keine Mitgliederränge haben dort Lese- und Kommentar-Schreibrechte. Die niedrigeren Mitgliederränge haben dort keinen Zugriff.

 

 

Status geändert in: Abgelehnt

Hallo zusammen,

 

zuerst einmal danke @kws für deinen Vorschlag. Wir haben diesen Vorschlag eine Zeit lang beobachtet und auch im Team darüber Gedanken gemacht, da auch wir zuerst nicht eine klare Meinung hatten. Wir haben uns jetzt aber entschieden, den Vorschlag nicht umzusetzen und das Bug-Board weiterhin nur Mitgestaltern und Community Guides zugänglich zu machen. 

 

Sicherlich gibt es ab und zu Themen, die auch von Nutzern der Rolle "Mitglieder" gemeldet werden. Das passiert aber relativ selten. Die meisten Bugs werden von Mitgestaltern und Community Guides gemeldet. Ihr kennt auch viel besser mit der Community aus. Euch fallen Fehler eher auf als neuen Mitgliedern. Unsere Sorge ist, dass durch das Öffnen des Bug-Boards für alle Nutzer, dieser Bereich unübersichtlicher wird. Z.B. wünschen wir uns, dass Fehler anhand des Templates gemeldet werden, damit wir diese besser nachvollziehen können und damit wir sie auch leichter lösen können. Es gibt jetzt auch schon Mitgestalter und Community Guides, die sich beim Melden von Bugs nicht immer an das Template halten. Von neuen Nutzern können wir das noch weniger erwarten. Außerdem landen in diesem Board dann auch wieder Beiträge, die hier nicht hingehören (z.B. Störungen). Darum belassen wir es vorerst so wie es ist. 

 

Liebe Grüße

Mi C. und Waldemar H.