Le fait de mettre en place deux votes séparés permet de faire la distinction, c'est ce qu'on disait également sur le drive. Sauf qu'à la fin il faut proposer un classement général unique (c'est en tout cas l'idée dans cette première édition, où on a eu un classement général même si on a accès au détail des classements par critères), donc on déplace simplement le problème. Quel rapport d'importance donner au classement du public par rapport au classement des devs ? En tout cas, pas une moyenne des deux moyennes séparées, car si un des deux avait un effectif très inférieur, ça n'aurait aucun sens. Au pire une moyenne générale (chaque vote compte pour autant), mais ça reviendrait exactement au même qu'actuellement, et au final les deux classements séparés ne seraient utile qu'à titre indicatifs...
Ou bien, dans le cas où on prévoirait deux classements totalement séparés, avec leurs récompenses propres (pour faire le parallèle avec cette édition, toujours), même problème : si au final un des deux classements tape dans les 5 votes, c'est vraiment valable de le maintenir ? Si on était sur un event massif avec 1000 votes par jeu en moyenne je dis pas, même si un des deux classements tombait à une moyenne de "seulement" 100 votes ça resterait valable. Mais là, à cette édition, comment les 40 votes moyens ont été répartis entre les devs et le public ? Perso j'en au aucune idée.
Pour ce qui est de la phrase que je t'ai cité, c'est une phrase utilisée pour du développement agile (méthode de dev en informatique). Basiquement, c'est un style de développement qui implique de faire très souvent des réunions, équipe uniquement (ou équipe + client, mais plus rarement), et de rectifier régulièrement les features du produit final et le planning de développement, en fonction du retard ou de l'évolution de la demande. Ca implique que les acteurs du projet peuvent avoir un gros impact sur les features du produit, en se disant que "moi si je dois m'en servir, je ferais ça comme ça"... Sauf que le but c'est de satisfaire les besoins du client, et on arrive très vite à des dérives qui font que le produit satisfait plus les devs que le client à la fin. En terme d'ergonomie, notamment, un dev et un utilisateur lambda attendent pas la même chose... D'où le "Personne dans cette salle n'est l'utilisateur", que le Scrum Master (rôle de médiateur dans ces réunions) utilise comme support si les gens commencent à partir n'importe où.
Bref, je m'étale pour pas grand chose là. En gros, quand je vais regarder les jeux de la jam, je vais malgré tout garder un état d'esprit un peu dev. Typiquement, plutôt que penser "ah ouais, ce jeu il est bien foutu !", je vais avoir tendance à penser "ah ouais, le mec il a codé une mécanique qui a pas dû être simple". A mon sens, ça rend les deux points de vue, utilisateur et dev, très différents, et à l'origine si je crée un jeu c'est notamment pour créer un truc qui va vendre du rêve au public, sinon je le garderais pour moi. D'ailleurs, j'ai été surpris de voir que itchio permettait aux devs de voter, au départ je pensais que seul le public pourrait le faire (bon, vu le nombre de votes, heureusement au final...), mais au choix je préfèrerais m'intéresser uniquement à l'avis de gens complètement extérieurs à la jam.
'fin bref, je l'ai déjà dit mais c'est un avis très subjectif, et je comprends totalement que tout le monde ne le partage pas. Là où moi je vais préférer l'avis du public, certains préfèrent l'avis des autres devs (participants*). Ca reboucle sur mon premier paragraphe, pour ce qui est de privilégier l'un ou l'autre. Si tu distingue, tu dois équilibrer le poids des deux. Si tu fais ça, c'est un choix personnel. Garder un classement général (participants+public) est sans doute le choix le plus équilibré au final.
(Re-pavé césar. Une balise spoiler pour réduire la taille de mes posts, ce serait vraiment pas de trop...)