Communitypick 'won't fix' is niet altijd handig

[matroosoft]

Bij de communitypick voor een nieuwe feature wordt de minst gekozen feature verwijderd uit de lijst, maar je ziet geregeld dat de opties erg dicht bij elkaar liggen en dat de laatste optie nog best veel stemmen krijgt. Kan dit niet anders opgelost worden?

[rens-br]

@matroosoft. Dit ben ik inderdaad met jou eens. Bij de vorige poll heb ik dat ook al aangegeven. (Kan alleen het antwoord zo snel niet meer vinden)

Vind het sowieso zonde dat ze het op deze manier doen. Kennelijk zijn alle opties die de poll raken vaak gekozen door de community, anders zouden ze niet in de poll staan.

Het is dan erg jammer dan 1 of de 4 functies het maar halen en de rest wordt afgeschoten.

[ Voor 6% gewijzigd door rens-br op 02-05-2017 14:59 ]

[Standeman]

Ik vind het ook een beetje apart. Het is imo niet zo dat wanneer een bepaalde functie onderaan eindigt deze gelijk irrelevant is.

[Hero of Time]

Ik kan mij een statement herinneren dat het niet keihard weggegooid werd, maar een veel lagere prio (lees onderop) krijgt. Een van de features was bijvoorbeeld het meer mobiel vriendelijk maken van afkortingen/acronymen. Daar was een minimale aanpassing met CSS voor nodig maar eindigde onderaan. Het was echter van zo'n toegevoegde waarde dat die alsnog op de roadmap is gezet (misschien zelfs al online, geen idee aangezien ik 'm in m'n eigen custom CSS heb gezet).

[Standeman]

@Hero of Time Dan is het misschien handiger als het wat anders verwoord word, want die indruk krijg ik nu niet.

[Hero of Time]

Ik wist dat het door Femme was gezegd en dat klopt ook:

Femme schreef op donderdag 2 maart 2017 @ 20:57:
[...]


De regel zal in de praktijk niet zo letterlijk worden toegepast. Als iets weinig stemmen krijgt maar voor een specifieke doelgroep wel een vrij essentiële verbetering is zullen we het alsnog willen overwegen. Dit geldt bijoorbeeld voor extra rml-tags in productreviews.

De regel is meer bedoeld voor feature-requests met een discutabele use case. Recentelijk hadden we bijvoorbeeld een optie voor filteren op garantieduur in Vraag & Aanbod. Die kreeg twee keer de minste stemmen terwijl andere nieuwe filters in V&A consequent hoger scoorden. Dat vind ik wel een goede aanleiding om het ticket te sluiten.

De soep wordt dus niet zo heet gegeten zoals deze wordt opgediend.

[matroosoft]

Hero of Time schreef op woensdag 3 mei 2017 @ 08:25:
Ik wist dat het door Femme was gezegd en dat klopt ook:

[...]

De soep wordt dus niet zo heet gegeten zoals deze wordt opgediend.

Klinkt al beter maar toch jammer dat het dan niet transparant is welke wel en welke niet verdwijnen en om welke reden. Doet toch een gedeelte van het 'community' aspect teniet.

[rens-br]

Hero of Time schreef op woensdag 3 mei 2017 @ 08:25:
Ik wist dat het door Femme was gezegd en dat klopt ook:

Ah kijk. Had ik het toch goed onthouden, ik kon dat topic alleen niet meer terug vinden.

[Femme]

Het idee is wel om aan de hand van de uitkomsten van de community pick polls de backlog op te schonen. Vaak sluiten we het ticket dat als laatste eindigt, maar niet altijd.

We zouden de tekst in de .plan kunnen nuanceren, anderzijds vind ik een beetje aansporing om een serieuze keuze te maken ook wel goed .

[rens-br]

@Femme Voor mij is meer het idee dat een idee in de backlog komt te staan, dat er al genoeg animo voor is. Immers is er vaak genoeg op '+1' gedrukt, waardoor deze populair genoeg is om in de backlog te komen.

Het lijkt me dan ook vreemd om überhaupt een van die dingen te verwijderen.

[Hero of Time]

@Femme, er is al een paar keer 4 hele goede opties geweest om op te stemmen. 4 die we heel graag zouden zien. Om dan te zeggen dat de nummer 4 nooit gedaan zal worden, terwijl in het volgende .plan twee zijn waar je meer iets hebt van 'meh, leuk/handig om te hebben' en men minder rouwig zal zijn als ze niet toegepast zouden worden.

Dat is het hele probleem met die communitypick. Genoeg zaken die men heel graag geïmplementeerd ziet worden die dan in 1 pick komen. Dan is het niet kiezen voor de minst slechte, maar de net iets minder goede en dat is ontzettend jammer.

[crisp]

De backlog opschonen kan en mag niet het doel zijn van de communitypick; dat is en blijft ook mijn mening.

Als blijkt dat een feature echt weinig votes krijgt dan kan dat wel als indicatie worden gebruikt dat er blijkbaar weinig behoefte aan is, maar veel opties worden al via upvotes hier op het forum als kandidaat aangedragen, en die zouden geen kind van de rekening mogen worden.

De uitkomsten van de poll zou je moeten gebruiken voor prioritering. Opschonen moet je doen door topics alhier met weinig thumbs gewoon te sluiten of te verplaatsen naar het archief.

[wouterg00]

Hero of Time schreef op woensdag 3 mei 2017 @ 18:56:
@Femme, er is al een paar keer 4 hele goede opties geweest om op te stemmen. 4 die we heel graag zouden zien. Om dan te zeggen dat de nummer 4 nooit gedaan zal worden, terwijl in het volgende .plan twee zijn waar je meer iets hebt van 'meh, leuk/handig om te hebben' en men minder rouwig zal zijn als ze niet toegepast zouden worden.

Dat is het hele probleem met die communitypick. Genoeg zaken die men heel graag geïmplementeerd ziet worden die dan in 1 pick komen. Dan is het niet kiezen voor de minst slechte, maar de net iets minder goede en dat is ontzettend jammer.

Precies. En het is al helemaal jammer als dan een paar functies met relatief weinig implementatietijd onderop beland, terwijl een veel moeilijkere functie iets meer stemmen heeft en dat er dan maar één functie wordt geïmplementeerd.

[matroosoft]

crisp schreef op woensdag 3 mei 2017 @ 19:56:
De backlog opschonen kan en mag niet het doel zijn van de communitypick; dat is en blijft ook mijn mening.

Als blijkt dat een feature echt weinig votes krijgt dan kan dat wel als indicatie worden gebruikt dat er blijkbaar weinig behoefte aan is, maar veel opties worden al via upvotes hier op het forum als kandidaat aangedragen, en die zouden geen kind van de rekening mogen worden.

De uitkomsten van de poll zou je moeten gebruiken voor prioritering. Opschonen moet je doen door topics alhier met weinig thumbs gewoon te sluiten of te verplaatsen naar het archief.

Hier sluit ik me volledig bij aan.

[MsG]

Hero of Time schreef op dinsdag 2 mei 2017 @ 20:06:
Ik kan mij een statement herinneren dat het niet keihard weggegooid werd, maar een veel lagere prio (lees onderop) krijgt. Een van de features was bijvoorbeeld het meer mobiel vriendelijk maken van afkortingen/acronymen. Daar was een minimale aanpassing met CSS voor nodig maar eindigde onderaan. Het was echter van zo'n toegevoegde waarde dat die alsnog op de roadmap is gezet (misschien zelfs al online, geen idee aangezien ik 'm in m'n eigen custom CSS heb gezet).

Die is juist niet op de roadmap gezet voor zover ik weet, maar juist wel door de shredder gehaald:

Zvennn in "Achterhaalde manier van afkortingen tonen"

Helaas heeft de community bepaald middels de community pick in het .plan van Development-iteratie #101 (zie plan: Categoriebrowser op frontpage - Development-iteratie #101 dat deze feature niet belangrijk genoeg is. We gaan dit verzoek dan helaas ook niet tot uiting brengen.

[Hero of Time]

MsG schreef op vrijdag 5 mei 2017 @ 02:04:
[...]


Die is juist niet op de roadmap gezet voor zover ik weet, maar juist wel door de shredder gehaald:

Zvennn in "Achterhaalde manier van afkortingen tonen"


[...]

Ja, en dat is dus enorm zonde, want onze goede vriend crisp vond het wel erg mooi en kost zo goed als geen moeite om te implementeren:

crisp schreef op donderdag 9 februari 2017 @ 22:51:
Ik vind de CSS oplossing best wel elegant. Dat is iets wat we eenvoudig (we werken immers al met stylesheets op basis van breakpoints met media-queries) zouden kunnen implementeren. Hopelijk ziet ons productteam daar ook wat in

Daarom vind ik, en anderen dus ook getuige dit topic en de discussie, het zo enorm jammer dat dit soort zaken die veel toevoegen aan de site met zo'n populariteitswedstrijd niet geïmplementeerd worden.

[matroosoft]

Femme schreef op woensdag 3 mei 2017 @ 10:24:
Het idee is wel om aan de hand van de uitkomsten van de community pick polls de backlog op te schonen. Vaak sluiten we het ticket dat als laatste eindigt, maar niet altijd.

We zouden de tekst in de .plan kunnen nuanceren, anderzijds vind ik een beetje aansporing om een serieuze keuze te maken ook wel goed .

Wat is dan precies het nut van de backlog opschonen? Ik geloof niet dat die backlog ooit leeg gaat zijn Als je het mij vraagt zou een ticket alleen naar het archief moeten als:
- het ticket is verwerkt
- de gevraagde feature al bestaat
- het productteam niet akkoord gaat met de gevraagde feature of de tijd/kosten die eraan verbonden zijn om de feature te implementeren te hoog is
- er geen behoefte aan de feature is.

Als er in een poll waar 1500 mensen op stemmen, de laatste keuze nog 20% van de stemmen krijgt, zou ik niet zeggen dat er geen behoefte aan is. Ergens ligt natuurlijk een grens waar de tijd die het kost niet meer opweegt tegen het aantal mensen die er behoefte aan hebben maar gevoelsmatig ligt die grens op een heel andere plek als waar de laatste keuzes in de poll doorgaans eindigen. Het is natuurlijk jullie keuze maar zo denk ik erover.

[emnich]

Het puur bepalen op basis van een poll klopt niet. De keuze die de minste stemmen krijgt is niet per definitie de minst gewenste van de opties.

Als je dat wilt weten dan moet je de gebruikers de mogelijkheid geven om ze alle 4 op volgorde te zetten. Of om een bepaald aantal punten te verdelen over de opties. Dat is uiteraard te lastig te implementeren en ook lastig voor bezoekers maar zonder dat kan je er geen (goede) conclusies aan verbinden.

[matroosoft]

emnich schreef op woensdag 10 mei 2017 @ 17:54:
Het puur bepalen op basis van een poll klopt niet. De keuze die de minste stemmen krijgt is niet per definitie de minst gewenste van de opties.

Als je dat wilt weten dan moet je de gebruikers de mogelijkheid geven om ze alle 4 op volgorde te zetten. Of om een bepaald aantal punten te verdelen over de opties. Dat is uiteraard te lastig te implementeren en ook lastig voor bezoekers maar zonder dat kan je er geen (goede) conclusies aan verbinden.

Het is inderdaad ook nog zo dat mensen als tweede keus de minst gekozen optie kunnen hebben, wat het beeld dan behoorlijk vertekend. In stem wel eens strategisch om ervoor te zorgen dat een tweede keus niet naar het archief verdwijnt.

[MsG]

matroosoft schreef op woensdag 10 mei 2017 @ 17:20:
[...]


Wat is dan precies het nut van de backlog opschonen? Ik geloof niet dat die backlog ooit leeg gaat zijn Als je het mij vraagt zou een ticket alleen naar het archief moeten als:
- het ticket is verwerkt
- de gevraagde feature al bestaat
- het productteam niet akkoord gaat met de gevraagde feature of de tijd/kosten die eraan verbonden zijn om de feature te implementeren te hoog is
- er geen behoefte aan de feature is.

Als er in een poll waar 1500 mensen op stemmen, de laatste keuze nog 20% van de stemmen krijgt, zou ik niet zeggen dat er geen behoefte aan is. Ergens ligt natuurlijk een grens waar de tijd die het kost niet meer opweegt tegen het aantal mensen die er behoefte aan hebben maar gevoelsmatig ligt die grens op een heel andere plek als waar de laatste keuzes in de poll doorgaans eindigen. Het is natuurlijk jullie keuze maar zo denk ik erover.

Vanuit de Scrum-methodiek die Tweakers aanhangt is het juist wel het idee om de backlog ook beheersbaar te houden en niet elke wens er eeuwig in te laten. Maar naar mijn idee doen ze dat nu juist o.a. door dingen waar veel animo voor is, en soms eenvoudig te implementeren zijn, de nek om te draaien.

[matroosoft]

MsG schreef op woensdag 17 mei 2017 @ 10:38:
[...]


Vanuit de Scrum-methodiek die Tweakers aanhangt is het juist wel het idee om de backlog ook beheersbaar te houden en niet elke wens er eeuwig in te laten. Maar naar mijn idee doen ze dat nu juist o.a. door dingen waar veel animo voor is, en soms eenvoudig te implementeren zijn, de nek om te draaien.

Mja.. Leuk idee opzich, maar heb je al eens gekeken naar het aantal feature requests wat nog open staat? Volgens mij is het hier volstrekt zinloos

[MsG]

Ik denk niet dat alle feature requests zijn opgenomen in hun backlog. In genoeg bedrijfssituaties komen er wel weer de hele tijd nieuwe wensen, maar daarom moeten er ook dingen worden afgeschoten. Ik heb alleen vraagtekens of populaire community aandragingen daar meteen onder moeten vallen.

[ari]

Wellicht is onderstaand buiten de scope van het topic. Toch lijkt het me een nuttige overweging voor het concept community pick.

Video van CGP Grey:

Korte uitleg: in plaats van ieders favoriet te vragen laat je iedereen aanvinken welke tickets die OK vindt als die uitgewerkt zouden worden. Dus checkboxes in plaats van radio buttons. Het ticket met de meeste stemmen wint zoals gewoonlijk.

Voordeel: Het ticket met de grootste goedkeuring van de community wordt uitgewerkt, terwijl dit idee voor velen wellicht op nummer twee zou staan als je om favorieten vraagt. Dit ticket zou in het huidige systeem rustig als laatste kunnen eindigen, omdat iedereen een andere favoriet heeft.

Tweede voordeel: Het ticket met de minste stemmen is daadwerkelijk het ticket waarvan de minste stemmers waarde zien. Het geeft ook inzicht in de populariteit van de minder gekozen opties. Zo zou je kunnen beslissen dat opties met minder dan bijvoorbeeld 25% goedkeuring van de lijst gehaald worden, omdat die niet genoeg draagvlak hebben.

Of gewoon alleen de laatste eraf zoals nu, met als rem de goedkeuring van de community.

[ Voor 5% gewijzigd door ari op 30-05-2017 18:31 ]

[Hero of Time]

Zou kunnen. Je kan daarmee ook de prioritering van de features iets beter inplannen. Meer votes is iets hoger op de todo lijst.

[crisp]

In feite doen we dat toch al door naar de thumbs-ups te kijken?

[Hero of Time]

Ja, maar als toevoeging zou dat niet verkeerd zijn. Niet elke gebruiker komt op het forum of de FP. Ik stem zelden tot nooit op de community pick (en als ik het .plan al lees, is vaak de stemronde al gesloten).

[ari]

crisp schreef op dinsdag 30 mei 2017 @ 21:12:
In feite doen we dat toch al door naar de thumbs-ups te kijken?

Dat is toch alleen voor de selectie van tickets die in de poll terecht komen? De poll bepaalt uiteindelijk welke daarvan wordt uitgewerkt. Juist op het punt waar de beslissing valt wordt alleen gekeken naar wat ieders favoriet is, niet naar welk ticket de grootste goedkeuring heeft van de community die er er eentje uit moet pikken.

[crisp]

ari schreef op vrijdag 2 juni 2017 @ 11:09:
[...]

Dat is toch alleen voor de selectie van tickets die in de poll terecht komen? De poll bepaalt uiteindelijk welke daarvan wordt uitgewerkt. Juist op het punt waar de beslissing valt wordt alleen gekeken naar wat ieders favoriet is, niet naar welk ticket de grootste goedkeuring heeft van de community die er er eentje uit moet pikken.

Als je de poll ziet als een manier om alleen te prioriteren dan is dat toch niet erg? Maar zolang de poll ook gebruikt wordt om features te wontfixen dan niet natuurlijk...

[ari]

Het wontfixen is inderdaad waar het om gaat in dit topic. Maar ook als het gaat om prioriteit te bepalen lijkt het me handig om te kijken naar waar je het grootste deel van de community een plezier mee doet (goedkeuring), niet naar wat de meeste mensen toevallig op hun nummer één hebben staan (favoriet).

[F.West98]

MsG schreef op vrijdag 5 mei 2017 @ 02:04:
[...]


Die is juist niet op de roadmap gezet voor zover ik weet, maar juist wel door de shredder gehaald:

Zvennn in "Achterhaalde manier van afkortingen tonen"
[...]

Sterker nog: die feature was niet eens laatste geworden. Hij kreeg 18% van de stemmen, terwijl nr 2 en 3 respectievelijk 21 en 19 procent kregen. Nummer 1 had 33. In dit geval vind ik die zeker niet 'niet belangrijk genoeg', als 290 mensen die als top optie hebben gekozen. Als jullie 'm niet willen implementeren om welke reden dan ook, schuif dat dan niet af op de community pick.
Ik snap prima dat als een feature 3x achter elkaar in de community pick laatste is geworden jullie m weg doen. Dat zou ik ook doen. Maar ik zou niet één poll als leidraad nemen, maar meerdere. Dan is echt consistent die ene feature niet populair.

[Verwijderd]

Óf een dubbele poll houden en alle posts van onderwerpen meetellen óf e.v.t. dumpies van duimpjes afhalen.

[Zvennn]

Daarnaast doen we het sluiten met 'won't fix' inmiddels niet meer dus dit topic is dan niet meer relevant.