GitHub implementeert veelgevraagde +1-knop

GitHub heeft een eerste duidelijke verandering doorgevoerd met betrekking tot een van de meest gewilde features: het toevoegen van een +1-knop. Naast de mogelijkheid om met een 'duim omhoog' een reactie een +1 te geven, zijn er ook andere reactiemogelijkheden toegevoegd.

De andere reacties in icoontjes omgezet zijn een duim naar beneden of -1, een 'smile', 'thinking face', 'heart' en 'tada'. De functionaliteit werkt bij pull requests, issues en comments. Daarmee komt GitHub een beetje tegemoet aan de klachten die honderden ontwikkelaars uitten in een open brief aan GitHub in januari. Zij waren daarin van mening dat GitHub hen negeert en geen gehoor gaf aan suggesties voor verbeteringen vanuit de community.

GitHub heeft daar met de nieuwe Reactions nu gehoor aan gegeven. De icoontjes die gebruikt kunnen worden zijn volgens de GitHub-ontwikkelaars relevant voor conversaties die mensen via het platform voeren. Het gebruik van emoji's, dat al wel mogelijk was, zou alleen maar ruis toevoegen aan discussies.

Reacties (42)

[capsoft]

Ik ben erg blij met deze functie. Als je een keer bij een issue of voorgestelde oplossing een +1 geeft krijg je dat je automatische mailtjes krijgt omdat je deelneemt aan die discussie. Dan volgen soms bergen comments met alleen +1 (wat je daarvoor zelf ook hebt gedaan) en unsubscribe je omdat je gek wordt van de +1's en mis je dus wanneer er een PR wordt gemerged.

edit: voorbeeld link toegevoegd zodat het duidelijk(er) is:
https://github.com/FortAw...78#issuecomment-193509557

[Reactie gewijzigd door capsoft op 29 juli 2024 08:23]

[Verwijderd]

Is dat niet een probleem van gebruikers, en niet zozeer de site?

Ik kan het fout hebben (dat wil zeggen, dat het niet hetzelfde resultaat oplevert), maar er zit rechts naast de issue een 'subscribe' knop - die lijkt me hiervoor bedoeld.

Ik zie hetzelfde op plaatsen als imgur. Een comment met alleen "." omdat ze blijkbaar de weg naar imgur favorites danwel de bookmarks faciliteit in hun eigen browser (in geval van niet-app) niet kunnen vinden, en toch de post later terug willen kunnen vinden (geen notificaties).

Of bij andere fora (zoals UBB), waarbij mensen alleen de comment "following" plaatsen - terwijl er gewoon een 'subscribe to this thread' link is.

Misschien dat de UX van dit soort sites dermate belabberd is dat het makkelijker is om een comment te plaatsen - maar in dat geval zal er weinig aan te doen zijn, en zal je ook nog steeds de +1'ers houden.

[capsoft]

Maar hoe geef je dan aan (toen deze feature er nog niet was) dat je een voorstander bent van de geschetste oplossing, of ook hinder ondervindt het omschreven probleem?
Ze lossen met deze wijziging juist een UX probleem op. De +1 comments waren een soort van workaround.

[Verwijderd]

Dat snap ik - maar het lijkt erop dat er veel mensen zijn die de +1 grotendeels gebruiken om notificaties te krijgen. Twee verschillende problem.
( github zou aan repohouders aan kunnen geven hoeveel mensen ge-subscribed hebben )

[Verwijderd]

Een simpele oplossing zou dan zijn om een optie te geven waarbij je de +1 mailtjes indien gewenst uit kunt zetten.

[capsoft]

nu scheelt het straks ook scrollen, maakt het issue een stuk overzichtelijker wat de discussie ten goede komt

[anargeek]

Voor mij hetzelfde. Ik maakte onlangs een bug aan in een (klaarblijkelijk) veelgebruikte node-module en heb 2 maanden lang elke dag meerdere "+1" mailtjes gehad, van mensen die hetzelfde probleem hadden. Dan kan je email-notificaties wel uitzetten, maar ik wachtte op het mailtje dat de bug verholpen zou zijn

[Reactie gewijzigd door anargeek op 29 juli 2024 08:23]

[svenslootweg]

De toevoeging van een -1 is erg jammer te noemen - dit moedigt downmodden zonder onderbouwing aan, iets dat je absoluut niet wilt op een constructief platform als GitHub. Het restant is op z'n best onduidelijk te noemen; ze hadden het beter gewoon bij een +1-knop kunnen laten.

[adis]

Nou, die -1 kunnen project owners gebruiken om issues snel te identificeren die gebruikt worden als een vraagbaak. Zie comment van @archie2012. Steeds meer mensen vervuilen de issues om hun probleem opgelost te krijgen, omdat ze vinden dat ze op SO bijvoorbeeld niet snel genoeg antwoord krijgen.

Of bijvoorbeeld als je van plan om een nieuwe feature toe te voegen om met de +1 en -1 makkelijk te kunnen pollen of het iets is. En vast meer use cases voor de +1 en -1.

[i-chat]

je komt op een moment in de ontwikkeling van je code dat eigenlijk alles al gezegd is, persoon a vind het goed, en heeft daar goede punten voor, persoon b vind het maar niets en heeft ook goede argumenten, persoon C vind het ook niets, maar heeft hele andere argumenten als persoon B ...

personen d t/m z hebben allemaal hun eigen mening en voorkeuren maar lang niet allemaal even goed, of reeds al verwoord ... kortom +1 of -1 .. is dan voldoende, als je alleen maar +1 zou hebben dan weet je dat er 10 mensen zijn die het willen, maar van de overige 90 weet je niets.. als 89 mensen geen mening heeft en 1 wil het niet, dan is het misschien een idee om het ergens een keer uit te voeren als je tijd over hebt, als er 30 +1 zijnn, zou je denken dat het dus sneller moet, totdat je de 69 -1 ook mee gaat tellen.. dan is het misschien toch niet zo'n goed plan.

[Verwijderd]

Hetzelfde valt te zeggen van de +1, welke dan de 'smile' zou moeten worden op het moment er geen commentaar bij staat? Wellicht is dat dan ook de oplossing voor de -1, een 'sad'?

[Zayl]

Als gebruiker van github ben ik erg blij met deze feature. Maintainers (inc ik zelf) gebruiken dit namelijk om te kijken hoeveel voor en hoeveel tegen zijn. In plaats van alle comments af te gaan, kan je het nu heel makkelijk zijn.

[Jaahp]

Eerst een aggresieve Code of Conduct, daarna het ontslaan van originele werknemers, toen de drag n drop fileuploads, en nu emoji's als +1... Ik vind de "coding" pop cultuur veel te indringend worden.

Dat ze luisteren en +1 implementeren is goed, natuurlijk, maar emoji's vind ik te ver gaan.

[Verwijderd]

Die emoji's met dank aan facebook, waarbij ze uiteindelijk overstag zijn gegaan voor mensen die nou niet bepaald een overlijdensbericht willen 'liken', maar ook geen idee hebben wat ze zouden moeten zeggen (zeker als het nou niet echt iemand is die ze zelf kennnen).

Zelfde zal met github wel het geval zijn - een comment met een oplossing kan je 'liken', een comment waarin uit de doeken wordt gedaan dat de ontwikkelaar mensen de middelvinger geeft is nou niet echt 'like'-waardig.

[Zezura]

De vraag is nu dan, krijgen de watchers dan van een +1 voor elke ook een email.

Want dat lijkt me vreselijk.

[SvenBravo7]

Fijn dat deze functionaliteit er eindelijk is. Weg met de '+1' comments. Wat wel een goede toevoeging had geweest is de mogelijkheid voor de eigenaar om te kiezen welke keuze er zijn bij een issue (bijvoorbeeld alleen +1 en -1, etc.)

[devandrej]

Maar GitLab is toch veel beter op het moment? Er zijn erg veel developers die overstappen naar GitLab.

[fameus]

Als open source platform is github.com onovertroffen, maar alleen omdat het zo veelgebruikt is.
Voor in-house hosting is GitHub buitensporig duur en een erg gesloten platform.
Gitlab CE kun je gratis inhouse hosten en GitLab EE (de betaalde versie) kost een fractie van wat GitHub kost. Ja het is wat langzamer, maar heeft ook meer features en een veel toegankelijker en opener ontwikkel team.

[capsoft]

Mocht je een klein team hebben van 5 developers en graag git als versiebeheer willen, dan kun je ook Microsoft's Team Service overwegen. Dat is gratis. "stakeholders" kun je onbeperkt aanmaken zodat ze bugreports etc kunnen aanleveren.
https://www.visualstudio....dio-team-services-vs.aspx
Dan heb je ook private repo's

[Rafe]

'Veel beter' is niet zo zwart-wit als dat je nu stelt. GitLab zelf hosten voor je bedrijf heeft zo zijn voor- en nadelen, GitLab.com is trager dan GitHub (al wordt daar wel aan gewerkt) en is nog niet zo populair onder de grote open source projecten.

Aangaande deze specifieke feature: GitLab had al ruime tijd +1/-1 knoppen, GitHub heeft zo te zien naar Facebooks nieuwe like-knop gekeken voor hun implementatie.

[Reactie gewijzigd door Rafe op 29 juli 2024 08:23]

[Verwijderd]

en wat is github precies dat mis ik dan weer in het artikel

[Rafe]

GitHub is de grootste hoster van (git) source code repositories. Veel open source projecten gebruiken om samen aan de software te werken. Voor het technische publiek van Tweakers wel als een bekende naam verondersteld.

[Reactie gewijzigd door Rafe op 29 juli 2024 08:23]

[cracking cloud]

Niet iedere tweaker is een developer ...

[Rafe]

Dan nog is GitHub de de facto source code hosting site van het internet momenteel. Als niet-developer heb je er misschien wel eens wat van gedownload of er van gehoord in algemeen technieuws (bijv. nieuws: GitHub haalt repository Popcorn Time offline na takedown-verzoek Hollywood).

[Verwijderd]

ik gebruikte soms sourceforge in het verleden , had dus nog nooit van github gehoord. maar de laatste 5 jaar staat mijn interesse op dat gebied wel erg stil.

[Rafe]

In die tijd is er wel een hoop gebeurd. Lees nieuws: 'GitHub is populairder dan SourceForge' en nieuws: SourceForge stopt met adware bij verlaten projecten voor de opkomst van de een en de neergang van de ander.

[YopY]

Kijk eens op https://github.com/ zou ik zeggen.

[Keiichi]

Ze kunnen beter IPv6 implemteren, dat is denk nog wel een nuttigere feature is.

[haling]

Waar een mens zich toch om druk kan maken......en dat het een nieuws bericht haalt ook nog..

Ik neem aan dat jij Github niet gebruikt als ontwikkelplatform voor jouw producten?

Ik moet het in de praktijk ook nog zien, maar op het eerste oog lijkt het me echt een enorme toevoeging om lange discussies te kunnen cherry-picken!

[Chrotenise]

als jij niet meer dagelijks honderden reacties hoeft af te struinen om een poll te weten, kan dat aardig wat uurtjes tijd schelen op jaarbasis die aan nuttigere zaken besteed kunnen worden.

[adis]

Dit is een van de meest storende comments die je maar kan geven op (open source) Github projecten. De contributors van open source projecten zijn vaak mensen die onbetaald in hun eigen tijd hun bijdrage leveren. Als dan 90% van de emails, want je krijgt een email als iemand reageert op een issue, alleen een +1 comment bevat, dan wordt je daar gek van.

Uiteraard kun je de emails uitzetten maar dan kun je weer belangrijke comments missen van andere contributors. Dus al met al, een dikke +1 van mij voor Github. Beter laat dan nooit!

[HollowGamer]

Wat een onzin, er zijn genoeg vrijwilligers die in hun in vrije tijd (naast hun werk/andere bezigheden) een project hebben op GitHub en simpelweg niet genoeg tijd/energie hebben om alles te kunnen fixen (als het eventueel al relevant is).

Dat laatste merk ik de laatste tijd steeds meer op GitHub, mensen die de Issue-tracker als troubleshooter gebruiken, i.p.v. zelf uit te zoeken waarom het bijvoorbeeld niet goed werkt of een configuratie-error hebben gemaakt.
In mijn ogen zou GitHub dan ook een Q&A-tracker moeten toevoegen (zoals Askubuntu, SO, etc.) naast de issue-tracker.

De +1 is opzicht een goede toevoeging, maar de kracht van GitHub zat/zit hem in het forken en vervolgens contributen naar de main branch d.v.m. pull-request(s).
Ik maak mij nu dan ook zorgen dat er steeds meer publiek komt die simpelweg klikken op +1, i.p.v. oplossingen bieden.
Issues kan je bijvoorbeeld taggen, bijvoorbeeld op basis van prioriteit, met die +1 geef je de kracht aan anderen, wat leuk werkt voor projecten met veel contributors, maar niet werken voor bijvoorbeeld projecten met maar één of twee.

Voorbeeld: Stel er staat een issue open met 'Poort *app* naar GTK-3*. Vervolgens geef ik dit een +1, maar verder doe ik helemaal niks. Zoals het testen of het goed werkt op GTK-3 of uitzoeken hoe ik zou kunnen helpen of leren hoe complex het soms kan zijn om een app te herschrijven en/of afvragen of het project wel genoeg mankracht heeft om het te realiseren.

[Reactie gewijzigd door HollowGamer op 29 juli 2024 08:23]

[The Zep Man]

Voorbeeld: Stel er staat een issue open met 'Poort *app* naar GTK-3*. Vervolgens geef ik dit een +1, maar verder doe ik helemaal niks. Zoals het testen of het goed werkt op GTK-3 of uitzoeken hoe ik zou kunnen helpen of leren hoe complex het soms kan zijn om een app te herschrijven en/of afvragen of het project wel genoeg mankracht heeft om het te realiseren.

Die +1 geeft alleen aan dat jij positief staat tegenover het porten van de app. Dit zal dus wel in jouw belang zijn. Of het te doen is en wat jouw contributie daaraan is (if any), is iets heel anders.

Zie het als een niet-bindende populariteitswedstrijd: het geeft je een idee wat speelt onder de gebruikers (die niet altijd ontwikkelaars zijn). Als ontwikkelaar kan je natuurlijk altijd verzoeken naast je neerleggen. Niemand verplicht je om aan datgene met de meeste +1-tjes te werken.

[HollowGamer]

Dat is nou net het probleem wat ik wil aangeven.
Het vervelende is dat de meeste +1 comments komen van gebruikers die doorgaans niet contributen, wat zich kan vertalen in een mogelijke feature request die misschien niet haalbaar/belangrijk is. De developer(s) hebben inderdaad de eindbeslissing, maar ik kan me ook voorstellen dat deze uiteindelijk hun plezier verliezen en misschien daarom stoppen met hun project.

Dit laatste heb ik helaas al genoeg keren voorbij zien komen, omdat developers een bepaalde druk voelen opkomen, terwijl ze het meestal al druk genoeg hebben met andere bezigheden en het merendeel van hun projecten als 'hobby' hebben ontwikkeld. Dit geld natuurlijk niet voor iedere developer en hangt enorm af van meerdere factoren (schaalbaarheid, ontwikkelaars, geld, etc.).

Voorbeeld: een open router-firmware waar een support-request wordt gedaan voor 'Router X'. Deze bevat helaas zoveel gesloten onderdelen/geen source, dat het te veel tijd wordt om dit te porten. Stel dat er ~250x op +1 wordt gedrukt omdat mensen er naar vragen, dan kan ik mij goed voorstellen dat een developer overspoelt raakt met +1 en/of mensen die vragen waarom het nog niet geport is, er is immers al ~250x +1 op gestemd!

Misschien sla ik te veel door, maar ik ben bang dat er nu mensen op GitHub actief gaan worden, waar je als developer niet echt op zit te wachten. Ik zeg niet dat het +1 publiek allemaal zo is, maar denkend aan de comments die nu vaak met alleen '+1' worden geplaatst (en verder niks meer), uiteindelijk niet je project verder helpen.
Je hebt mensen nodig die je feedback geven waar je iets meer kan (dat is ook contributen), i.p.v. +1'en.

Dit laatste zie vaak ook terug op buglists. Wel een comment posten met 'Ik heb ook dit probleem', maar vervolgens zonder enige input/debug (het probleem kan zich immers ook voordoen via een andere weg/app).
Ja, het zorgt ervoor dat de prioriteit omhoog gaat, maar het kan ook immers niet met elkaar te maken hebben en dus de +1 niet rechtvaardigen.

[Reactie gewijzigd door HollowGamer op 29 juli 2024 08:23]

[The Zep Man]

Dat is nou net het probleem wat ik wil aangeven.
Het vervelende is dat de meeste +1 comments komen van gebruikers die doorgaans niet contributen, wat zich kan vertalen in een mogelijke feature request die misschien niet haalbaar/belangrijk is. De developer(s) hebben inderdaad de eindbeslissing, maar ik kan me ook voorstellen dat deze uiteindelijk hun plezier verliezen en misschien daarom stoppen met hun project.

Als er één ding is dat je als open-source, vrijwillige ontwikkelaar moet weten is dat er altijd een groep gebruikers is met commentaar waar je niets mee kan. Als je niet leert om je van die groep afstand te nemen, dan zal je inderdaad geen plezier hebben in je werk.

Dit laatste heb ik helaas al genoeg keren voorbij zien komen, omdat developers een bepaalde druk voelen opkomen, terwijl ze het meestal al druk genoeg hebben met andere bezigheden en het merendeel van hun projecten als 'hobby' hebben ontwikkeld. Dit geld natuurlijk niet voor iedere developer en hangt enorm af van meerdere factoren (schaalbaarheid, ontwikkelaars, geld, etc.).

Zowel ontwikkelaars als andere groepen adviseer ik van harte de cursus 'omgaan met teleurstellingen'. Door 'nee' te zeggen heb je vaak meer succes dan met 'ja'.

Voorbeeld: een open router-firmware waar een support-request wordt gedaan voor 'Router X'. Deze bevat helaas zoveel gesloten onderdelen/geen source, dat het te veel tijd wordt om dit te porten. Stel dat er ~250x op +1 wordt gedrukt omdat mensen er naar vragen, dan kan ik mij goed voorstellen dat een developer overspoelt raakt met +1 en/of mensen die vragen waarom het nog niet geport is, er is immers al ~250x +1 op gestemd!

Dan sluit je de issue met een omschrijving waarom het niet gedaan zal worden en ga je door. Nieuw geopende issues over hetzelfde sluit je meteen, met een referentie naar de oude issue. Dat kan nu al. Al heb je daar als ontwikkelaar geen zin in, dan stel je een moderator aan.

Misschien sla ik te veel door, maar ik ben bang dat er nu mensen op GitHub actief gaan worden, waar je als developer niet echt op zit te wachten. Ik zeg niet dat het +1 publiek allemaal zo is, maar denkend aan de comments die nu vaak met alleen '+1' worden geplaatst (en verder niks meer), uiteindelijk niet je project verder helpen.
Je hebt mensen nog die feedback geven waar je iets meer kan (dat is ook contributen), i.p.v. +1'en.

GitHub is een publieke plek om code te hosten en van commentaar te voorzien. Als je daar als ontwikkelaar niet tegen kan, zet dan je eigen gesloten omgeving op en werk met iets als uitnodigingen om te filteren bij de poort.

[Reactie gewijzigd door The Zep Man op 29 juli 2024 08:23]

[Loller1]

Nou? Wat zou jij er van vinden als in de reacties op artikels hier steeds +1 zou staan tussen conversaties in waardoor je het overzicht gewoon totaal verliest?