Hoe relevant is "Meest gewaardeerde feature requests" nog?

[Creesch]

Eerder deze week heb ik in dit subforum wat feedback achtergelaten. Daardoor zag ik ook weer het topic uit de titel bovenaan staan: Meest gewaardeerde feature requests

Toevallig staat een eerdere feature request van mij in de lijst. Nu gaat het mij daar niet om, maar wel dat ik me besefte dat ik het betreffende request in 2017 heb gedaan. Uit nieuwsgierigheid ben ik eens door de hele lijst heen gegaan en wat mij opviel is dat ze bijna allemaal meerdere jaren oud zijn en het merendeel er ook al een behoorlijk lange tijd in staat.

In de post zelf worden wij als gebruikers actief aangemoedigd om te stemmen op features.

Deze lijst wordt dynamisch samengesteld en gesorteerd op basis van het aantal opgestoken duimpjes van de startpost van het bijbehorende topics. De lijst is dus altijd actueel! Wil je dat een feature hoger in de lijst komt, geef de topicstart dan een thumbs-up!

Er wordt zelfs een belofte gedaan dat features in de lijst gebruikt zullen worden bij het bepalen van prioriteiten van de tweakers backlog.

De lijst helpt ons bij het bepalen van de prioriteiten van onze backlog. Als we een feature request om wat voor reden dan ook niet wenselijk vinden zullen we het bijbehorende topic sluiten. De feature verdwijnt dan uit de lijst.

Wellicht was dit zo in het verleden, maar deze specifieke lijst lijkt hiervoor niet meer ingezet te worden.

Als ik kijk naar de .plan artikelen wordt prioriteit voornamelijk op andere manieren bepaald. Soms wel op basis van input van gebruikers maar de voorgeschotelde poll opties komen zover ik weet niet uit het hier gepinde topic.

Sterker nog, het topic lijkt bij weinig mensen überhaupt te leven of op het netvlies te staan.

• Feature: filteren op winkelbeoordeling, nummer vier op de lijst met met 94 stemmen. Ondertussen al lang een breed geïmplementeerd. Maar, ik gok niet op basis van dit specifieke topic en de lijst. Je zou dan namelijk verwachten dat het topic zou zijn gesloten met een mededeling dat het is geïmplementeerd zodat de lijst ook daadwerkelijk actueel blijft.
• De +1 thumbsup omruilen voor Tweakmoticons , deze staat met 84 likes op nummer vijf. Je zou verwachten dat het topic minimaal een keer geciteerd zou zijn in een meer recentelijke discussie hier: Frontpage reacties like en/of emoji react systeem?.
• https://gathering.tweakers.net/forum/list_messages/2141328 Dit is geen feature request, staat wel op nummer 11 van de lijst.

In het kort, de lijst:

• is duidelijk geen leidraad voor de prioriteit van het backlog.
• wordt niet bijgehouden aangezien al geimplementeerde features er nog steeds in staan en algemene feedback ook de lijst vervuild.
• leeft sowieso niet bij zowel tweakers als gebruikers omdat vergelijkbare feature requests als nieuw worden besproken.

tl;dr

Volgens mij heeft het huidige gepinde topic weinig nut omdat eigenlijk weinig tot geen mensen er actief naar kijken. Mijn voorstel zou dan ook het volgende zijn om op zijn minst de belofte tot backlog prioriteiten uit de tekst te verwijderen.

Iets rigoureuzer zou zijn om te erkennen dat het topic in huidige vorm niet wordt gebruikt en het dus simpelweg met pensioen te sturen. Zou ik overigens zonder vinden, het geeft nog steeds een overzicht.

In een ideale situatie wordt de manier hoe features hier worden verwerkt eens onder de loep genomen.

[DaFeliX]

Bedenk wel dat als een feature-request is opgeleverd, deze niet meer in de lijst terugkomt? Dus dat er nu heel veel 'oude' feature requests zijn kan ook betekenen dat ze complex zijn. Je ziet dus enkel de overgebleven feature requests, en alle feature requests die zijn uitvoerd niet meer.

Creesch schreef op woensdag 26 oktober 2022 @ 10:12:
[...]

[...]

Wellicht was dit zo in het verleden, maar deze specifieke lijst lijkt hiervoor niet meer ingezet te worden.


Als ik kijk naar de .plan artikelen wordt prioriteit voornamelijk op andere manieren bepaald. Soms wel op basis van input van gebruikers maar de voorgeschotelde poll opties komen zover ik weet niet uit het hier gepinde topic.

Sterker nog, het topic lijkt bij weinig mensen überhaupt te leven of op het netvlies te staan.

We kunnen niet alle feature requests uitvoeren, daar is helaas te weinig tijd voor. Maar deze lijst wordt wel degelijk gebruikt. Sommige zaken die complex zijn duren nu eenmaal langer, of worden iets verder naar achteren geschoven om features die kleiner zijn op te kunnen pakken. Dat verklaard waarom we niet van boven naar beneden werken, maar dat de lijst niet gebruikt word is niet waar.

Neem darkmode, die bovenaan de lijst staat. Dat weten we en staat ook hoog op onze agenda. Het is echter ook een megaklus, waarvoor we niet al het andere werk willen laten vallen. Met onbeperkte capaciteit hadden we het allang gedaan, maar we moeten eenmaal helaas (soms harde) keuzes maken.

• Feature: filteren op winkelbeoordeling, nummer vier op de lijst met met 94 stemmen. Ondertussen al lang een breed geïmplementeerd. Maar, ik gok niet op basis van dit specifieke topic en de lijst. Je zou dan namelijk verwachten dat het topic zou zijn gesloten met een mededeling dat het is geïmplementeerd zodat de lijst ook daadwerkelijk actueel blijft.
• De +1 thumbsup omruilen voor Tweakmoticons , deze staat met 84 likes op nummer vijf. Je zou verwachten dat het topic minimaal een keer geciteerd zou zijn in een meer recentelijke discussie hier: Frontpage reacties like en/of emoji react systeem?.
• https://gathering.tweakers.net/forum/list_messages/2141328 Dit is geen feature request, staat wel op nummer 11 van de lijst.

Ik ben het er mee eens dat de bijbehorende topics dan wel op slot moeten als de feature request is doorgevoerd. Let er ook op dat feature requests op meerdere manieren bij ons kunnen binnenkomen, dus er is niet altijd een directe relatie tussen feature request en topic; en soms bestaat een topic uit meerdere feature requests die we deel voor deel opleveren. Ik zal kijken of ik iemand door deze lijst kan laten gaan om 'm weer bij te werken, want als ie nu niet actueel is moeten we dat fixen

[...]

In een ideale situatie wordt de manier hoe features hier worden verwerkt eens onder de loep genomen.

Ik ben het met je eens dat transparantie zeer wenselijk is, en hoop je met deze reactie wat te hebben gegeven. Suggesties hoe 't nog beter kan vinden we erg prettig en ontvangen we graag

[Creesch]

DaFeliX schreef op woensdag 26 oktober 2022 @ 10:44:
Bedenk wel dat als een feature-request is opgeleverd, deze niet meer in de lijst terugkomt?

Dat lijkt dus niet het geval te zijn als ik naar de lijst kijk. Sterker nog, het grootste gedeelte van de lijst lijkt enigzins statisch te zijn. Mocht ik mij daar in vergissen dan lijkt het mij handig om wellicht ook een lijst te hebben met feature requests die al zijn ingevoerd. Nu leeft bij mij echt het idee dat er weinig mee gedaan wordt door de punten die ik al aanhaalde.

Maar dat de lijst niet gebruikt word is niet waar.

Ik geloof dat het zo is als je dit nu zegt, maar het is nogmaals niet het beeld wat bij mij leeft. Dat kan ook zijn omdat de informatie ontbreekt om te zien dat er daadwerkelijk wat mee gedaan wordt. Zoals ik hierboven al aangaf, een lijst met features die op de lijst hebben gestaan, maar ondertussen al zijn geïmplementeerd zou al een hoop helpen.

Aanvullend

Neem darkmode, die bovenaan de lijst staat. Dat weten we en staat ook hoog op onze agenda. Het is echter ook een megaklus, waarvoor we niet al het andere werk willen laten vallen. Met onbeperkte capaciteit hadden we het allang gedaan, maar we moeten eenmaal helaas (soms harde) keuzes maken.

Dat kan, dit signaal heb ik inderdaad wel vaker gelezen over deze feature. Dat valt echter niet uit de lijst of het topic makkelijk op te maken. Wat naast de lijst met al geïmplementeerde features ontbreekt, is eigenlijk de status van feature requests in de lijst. Een extra kolom in de tabel misschien met daarin een korte toelichting of een label vergelijkbaar zoals je vaak op github issues ziet "Complexe feature, lastig te implementeren" oid.

Let er ook op dat feature requests op meerdere manieren bij ons kunnen binnenkomen, dus er is niet altijd een directe relatie tussen feature request en topic;

Dit suggereert bij mij toch echt dat deze lijst niet echt leeft of er actief naar wordt gekeken. Als dat wel zo was dan zou bij het doornemen van de lijst (wat volgens mij prima als taak per twee sprints oid kan worden opgenomen) een realisatie moment zijn dat een recente feature ook gelijk een request in de lijst (gedeeltelijk afdekt). Sterker nog, dat zou dan tijdens refinement ook boven water kunnen komen.

en soms bestaat een topic uit meerdere feature requests die we deel voor deel opleveren.

Dat begrijp ik, dat is wat mij betreft dan ook een argument voor het toevoegen van een status kolom in de tabel.

Ik zal kijken of ik iemand door deze lijst kan laten gaan om 'm weer bij te werken, want als ie nu niet actueel is moeten we dat fixen

Dat lijkt me een uitstekend plan. Maar, wederom wekt het bij mij niet de indruk dat de lijst echt leeft ondanks dat je aangeeft dat deze daadwerkelijk wordt gebruikt. Nogmaals, ik verwacht niet dat er dagelijks naar wordt gekeken. Eens per twee sprints of zelfs eens per kwartaal kan al afdoende zijn. Zolang dat maar terug te zien is voor ons als gebruikers

Ik ben het met je eens dat transparantie zeer wenselijk is, en hoop je met deze reactie wat te hebben gegeven. Suggesties hoe 't nog beter kan vinden we erg prettig en ontvangen we graag

Volgens mij heb ik dat ook gedaan Het is wat mij betreft simpelweg stakeholder management. Gebruikers, actief in dit forum, hebben weliswaar (individueel) weinig invloed, maar zijn wel engaged. Dan wil je, denk ik, ook actief informeren. Dat laatste gebeurd nu op dit specifieke vlag dusdanig weinig dat ik het gevoel heb dat er weinig mee gebeurt.
Ik weet dat de development iteratie artikelen ook bedoeld zijn om deze rol te vervullen. Zoals ik al aangaf lijkt daar geen relatie/weinig relatie te zijn met de feature requests in de genoemde lijst.

[DaFeliX]

Creesch schreef op woensdag 26 oktober 2022 @ 11:26:
[...]


Dat lijkt dus niet het geval te zijn als ik naar de lijst kijk. Sterker nog, het grootste gedeelte van de lijst lijkt enigzins statisch te zijn. Mocht ik mij daar in vergissen dan lijkt het mij handig om wellicht ook een lijst te hebben met feature requests die al zijn ingevoerd. Nu leeft bij mij echt het idee dat er weinig mee gedaan wordt door de punten die ik al aanhaalde.

De lijst wordt automatisch gemaakt adhv een call naar https://gathering.tweaker...t_best_rated_topics/39/25 ; die geeft de 25 niet-gesloten topics voor dit forum gesorteerd op aantal duimpjes.
Helaas hebben we (zo ver ik weet) geen endpoint die een soortgelijke functionaliteit biedt voor topics die wel gesloten zijn, dus een overzicht maken van doorgevoerde feature requests aan de hand van deze topics is niet triviaal vrees ik. Wellicht dat @ikloon wel e.e.a. uit Jira kan halen?

[...]


Ik geloof dat het zo is als je dit nu zegt, maar het is nogmaals niet het beeld wat bij mij leeft. Dat kan ook zijn omdat de informatie ontbreekt om te zien dat er daadwerkelijk wat mee gedaan wordt. Zoals ik hierboven al aangaf, een lijst met features die op de lijst hebben gestaan, maar ondertussen al zijn geïmplementeerd zou al een hoop helpen.

Aanvullend


[...]


Dat kan, dit signaal heb ik inderdaad wel vaker gelezen over deze feature. Dat valt echter niet uit de lijst of het topic makkelijk op te maken. Wat naast de lijst met al geïmplementeerde features ontbreekt, is eigenlijk de status van feature requests in de lijst. Een extra kolom in de tabel misschien met daarin een korte toelichting of een label vergelijkbaar zoals je vaak op github issues ziet "Complexe feature, lastig te implementeren" oid.


[...]

In de .plan's delen we nog wel 'ns welke features we opleveren, maar ik weet niet of we daar consequent alle features in noemen. Wellicht dat we daar nog wel wat in kunnen verbeteren, door vaker en beter te melden welke features we dan opgeleverd hebben. Het is helaas wel 'n beetje het probleem van features: Zo lang het er niet is, is het een groot gemist, op het moment dat het er wel is is het 'gewoon' geraakt en valt 't niet meer op.

[...]

Dit suggereert bij mij toch echt dat deze lijst niet echt leeft of er actief naar wordt gekeken. Als dat wel zo was dan zou bij het doornemen van de lijst (wat volgens mij prima als taak per twee sprints oid kan worden opgenomen) een realisatie moment zijn dat een recente feature ook gelijk een request in de lijst (gedeeltelijk afdekt). Sterker nog, dat zou dan tijdens refinement ook boven water kunnen komen.

[...]

Dat begrijp ik, dat is wat mij betreft dan ook een argument voor het toevoegen van een status kolom in de tabel.

[...]

Dat lijkt me een uitstekend plan. Maar, wederom wekt het bij mij niet de indruk dat de lijst echt leeft ondanks dat je aangeeft dat deze daadwerkelijk wordt gebruikt. Nogmaals, ik verwacht niet dat er dagelijks naar wordt gekeken. Eens per twee sprints of zelfs eens per kwartaal kan al afdoende zijn. Zolang dat maar terug te zien is voor ons als gebruikers

[...]

Het nadeel is dat voor development/product onze SPOT Jira is, en niet het forum. Waarschijnlijk kunnen we deze wel wat beter met elkaar synchroniseren, zodat het voor jullie als community ook duidelijker is.

[...]


Volgens mij heb ik dat ook gedaan Het is wat mij betreft simpelweg stakeholder management. Gebruikers, actief in dit forum, hebben weliswaar (individueel) weinig invloed, maar zijn wel engaged. Dan wil je, denk ik, ook actief informeren. Dat laatste gebeurd nu op dit specifieke vlag dusdanig weinig dat ik het gevoel heb dat er weinig mee gebeurt.
Ik weet dat de development iteratie artikelen ook bedoeld zijn om deze rol te vervullen. Zoals ik al aangaf lijkt daar geen relatie/weinig relatie te zijn met de feature requests in de genoemde lijst.

Duidelijk. Volgens mij is het dan vooral de communicatie die niet goed gaat, daar kunnen we wat in verbeteren. Voor jouw geruststelling: Weet dat wat we ook doen, we altijd de gebruikers in 't achterhoofd houden. Dat zie je misschien niet genoeg, maar het is wel zo

[jelle.]

Creesch schreef op woensdag 26 oktober 2022 @ 10:12:

tl;dr

Volgens mij heeft het huidige gepinde topic weinig nut omdat eigenlijk weinig tot geen mensen er actief naar kijken. Mijn voorstel zou dan ook het volgende zijn om op zijn minst de belofte tot backlog prioriteiten uit de tekst te verwijderen.

Iets rigoureuzer zou zijn om te erkennen dat het topic in huidige vorm niet wordt gebruikt en het dus simpelweg met pensioen te sturen. Zou ik overigens zonder vinden, het geeft nog steeds een overzicht.

In een ideale situatie wordt de manier hoe features hier worden verwerkt eens onder de loep genomen.

Bedankt voor je feedback en suggesties! Het is alweer even geleden, maar dit topic en een aantal andere signalen hebben ertoe geleid dat we zijn gaan nadenken over een nieuwe aanpak voor Mooie features. Door andere prioriteiten duurde dat wat langer dan de bedoeling was, maar inmiddels hebben we hier een plannetje voor liggen.

Het klopt dat Meest gewaardeerde feature requests tegenwoordig niet meer de leidraad vormt voor het stellen van prioriteiten op onze backlog. In onze nieuwe aanpak willen we daarom afscheid gaan nemen van dit overzicht en deze manier van stemmen, mede vanwege de populariteitsbias die hierin meespeelt. Voor het indienen van nieuwe feature requests gaan we een template beschikbaar stellen. Belangrijkste verschil met de oude werkwijze is dat we de focus willen verleggen van mogelijke oplossingen naar het probleem dat een gebruiker ervaart. Het geven van duimpjes kan natuurlijk nog steeds, maar zal niet doorslaggevend zijn om iets wel of niet te bouwen.

In de aankondiging zeer binnenkort zullen we hier uitgebreider op ingaan, maar aangezien je hier de moeite hebt genomen om dit onder de aandacht te brengen, wilde ik alvast laten weten dat we er dus mee bezig zijn

[jelle.]

Zie Mooie features beleid (nieuwe aanpak)

Aangezien hiermee als het goed is je vraag beantwoord is, doe ik deze op slot. Voor eventuele vragen/feedback kun je ook in dat topic terecht