150 African Workers for ChatGPT, TikTok and Facebook Vote to Unionize, Gradle still sucks, The Complete Guide to the Kano Model, Thinking about our passive exposure to IPv6 issues
More than 150 workers whose labor underpins the AI systems of Facebook, TikTok and ChatGPT gathered in Nairobi on Monday and pledged to establish the first African Content Moderators Union, in a move that could have significant consequences for the businesses of some of the world’s biggest tech companies.
[…]
Those two judgments against Meta include one from April in which a Kenyan judge ruled Meta could be sued in a Kenyan court—following an argument from the company that, since it did not formally trade in Kenya, it should not be subject to claims under the country’s legal system. Meta is also being sued, separately, in a $2 billion case alleging it has failed to act swiftly enough to remove posts that, the case says, incited deadly violence in Ethiopia.
[…]
Workers who helped OpenAI detoxify the breakout AI chatbot ChatGPT were present at the event in Nairobi, and said they would also join the union. TIME was the first to reveal the conditions faced by these workers, many of whom were paid less than $2 per hour to view traumatizing content including descriptions and depictions of child sexual abuse. “For too long we, the workers powering the AI revolution, were treated as different and less than moderators,” said Richard Mathenge, a former ChatGPT content moderator who worked on the outsourcing company Sama’s contract with OpenAI, which ended in 2022. “Our work is just as important and it is also dangerous. We took an historic step today. The way is long but we are determined to fight on so that people are not abused the way we were.”
En lien direct avec un article précédemment partagé sur l’exploitation de travailleurs pour la modération de contenus générés sur les réseaux ou par les IAs. J’espère que l’impact sera à la hauteur des ambitions, et curieux de voir comment les GAFAM & co trouveront de nouveaux moyens d’exploiter les inégalités pour leur marge.
What sucks about the above process is not that it’s long. It’s the sheer number of concepts that must be learned and interacted with: subbuilds, subprojects, plugins, tasks, providers, extensions, source sets, configurations, artifacts, dependencies, and all of the quirks and workarounds involved with each of those things.
All of this complexity makes working with Gradle a slog. You can fully, deeply understand every single aspect of your build until you want to do one thing slightly differently and suddenly it doesn’t work because you were supposed to be using some totally different part of Gradle you never heard about before.
The whole idea of using community-developed plugins becomes a minefield because the chance of them applying all of the concepts completely correctly is essentially 0%, meaning you might be okay as long as you’re only doing basic stuff, but as soon as you stray off the beaten path stuff starts breaking and you have almost no chance to fix it properly yourself.
La liste des étapes est longue, mais si vous en avez le courage, et lisez entre les lignes, vous reconnaîtrez sûrement d’autres outils que vous utilisez sur vos projets.
Je vois déjà dans l’audience un sourire de maniaque grandir sur le visage d’un utilisateur pragmatique de Gradle, prêt à jeter son casque Bluetooth à travers la pièce. Oui l’auteur s’est acharné à suivre le chemin de la « best practice », et bien sûr plus quelque chose est adaptable, moins il est adapté. Et si l’outil permet de sortir de ces best practices, c’est probablement justement parce qu’il serait idiot de les appliquer en tout contexte. Cela dit, l’article fait mouche volontairement et involontairement sur plusieurs points :
Et ce n’est pas propre à Gradle. Vous avez tenté d’introduire des étapes custom de génération à partir de source avec webpack sans bidouiller ? (Btw ce site est généré grâce à de telles étapes) Au fond, le seul outil qui m’a donné le moins de fil à retordre pour organiser des étapes de build est aussi le plus vieux : Makefile.
The features you choose to study should be those where the user will get any sort of meaningful benefit out of them. Your backlog may contain a number of different kinds of items you may need to include such as technical debt payment, something for the sales or marketing teams, a reporting system, or a design refresh. All of these are out of scope of the Kano analysis.
We’re measuring customer satisfaction among externally tangible features, but products are way more than that. If you need data to support not doing something an internal stakeholder is asking of you, you’ll be doing a disservice to your team, your customers and yourself if you use a Kano study for that.
[…]
If you’re seeing multiple results without a clear category, there may hidden customer profiles that you’re not considering. In this case you should probably go back to the customer responses to look for patterns; try checking which customers’ answers are usually the same as other customers’, to find “demographic clusters” you may be missing.
From the results table, you can rank features according to their importance. After that, the general rule of thumb to use when prioritizing is to go after all Must-be features, then add as much Performance ones as you can and finally include a few Attractive ones.
This type of analysis is great to give you a first level of understanding and it’s useful in many contexts where you don’t need a more rigorous approach (e.g., testing design ideas or making a rough draft of your roadmap.)
Une fois priorisés dans un backlog la valeur de chaque story semble facilement comparable, leur ordre apparaît évident, mais ce n’est que le résultat d’un processus absolument pas linéaire. Confondre ce résultat et les moyens pour y parvenir nous empêche d’ajuster rapidement notre trajectoire, et donne très souvent pour résultat un bête alignement d’epics dont on se demande parfois pourquoi on les découpe en tickets si fins. Cet article présente un modèle qui permet de classer des fonctionnalités en prenant compte l’aspect dynamique de la « valeur » de chacune. C’est à dire que même si l’on montre très souvent le graphe du modèle de Kano, il s’agit d’un outil qui est loin de ne considérer que 2 dimensions.
If I were an evil threat actor, I'd be learning as much about #ipv6 as possible right now. I'm convinced that many companies that say they "aren't using" IPv6 are in reality just ignoring IPv6, and it would be easy to set up a "shadow network" consisting of IPv6 traffic where you could get away with murder. Nobody at the company is logging IPv6 traffic and events, none of the tools are configured to monitor it, and a large majority of the staff knows nothing about it.
"But we disable IPv6!"
Really? On your users mobile devices? On printers? On random IoT devices? And most of all, on your remote user's networks? Good luck, my guy.
