vipink1203/idées-de-hackathon

Idées de hackathon

Nous construisons des idées qui résolvent un vrai problème à sa cause racine, pour une personne spécifique, étayées par des preuves que le problème existe, et reposant sur une intuition : le fait non évident qui fait fonctionner cette solution là où les approches habituelles échouent. Le petit et le simple sont les bienvenus ; le commun ne l'est pas. Une idée ne gagne sa place que si elle compte encore après le hackathon, et qu'un juge n'aurait pas pu la deviner à partir du nom de la piste.

Un hackathon se gagne sur ses critères d'évaluation, dans son délai, à travers un moment de démonstration : les quelques secondes de la vidéo ou de la démo en direct où un juge voit la chose fonctionner et la comprend. Chaque fait concernant le hackathon provient de ses pages officielles, citées par lien.

Étapes

1. Lire le brief. À partir de la page officielle du hackathon, des règles et de la FAQ (demandez le lien si vous n'en avez pas), enregistrez avec les liens sources : pistes et prix, critères d'évaluation et leurs pondérations, technologies obligatoires ou sponsors, éligibilité et règles qui disqualifient (taille de l'équipe, code préexistant, région, licence), exigences de soumission (durée de la vidéo, dépôt, démo en direct, compte rendu), et la date limite avec le temps restant. Ensuite, demandez à l'utilisateur, en 3 questions au maximum, ce que le brief ne peut pas dire : taille de l'équipe et compétences, heures disponibles, et tout domaine qu'il connaît de première main ou une piste vers laquelle il penche. Terminé lorsque chaque champ ci-dessus a une valeur citée ou est marqué « non publié ». Lorsqu'aucun critère d'évaluation n'est publié, utilisez quatre critères égaux communs aux grilles de hackathon (originalité de l'idée, implémentation technique, impact potentiel, conception et présentation), et étiquetez-les comme notre solution de repli dans la sortie.
2. Écrire la liste évidente. Avant toute recherche, écrivez les 10 idées que la plupart des équipes soumettront pour ces pistes et cette technologie : les premières choses que tout le monde dirait. Ces idées, et tout ce qui en est une légère variation, sont écartées à l'étape 5.
3. Trouver des problèmes réels. C'est l'étape la plus profonde ; consacrez-y le plus d'effort. Allez là où les gens décrivent leurs problèmes avec leurs propres mots, dans les domaines vers lesquels les pistes et les connaissances de première main de l'équipe pointent : forums, subreddits, issues GitHub, fils de support et de communauté, avis sur les boutiques d'applications, groupes professionnels, plaintes publiques et rapports d'organismes de régulation. Cherchez en particulier les contournements : tableurs, scripts, double saisie manuelle, impressions, discussions de groupe, assistants payés faisant le travail d'une machine ; chaque contournement marque un problème pour lequel les gens paient déjà avec leur temps. Pour chaque problème, demandez pourquoi jusqu'à atteindre une cause structurelle, pas un symptôme. Terminé lorsque les notes contiennent au moins 10 problèmes distincts, chacun avec une personne et une situation spécifiques, au moins une citation ou un point de données avec un lien, le contournement qu'ils utilisent aujourd'hui, et la cause racine.
4. Rechercher le terrain. Lisez les gagnants passés de ce hackathon ou de cette série (sa galerie de projets, par exemple sur Devpost), les lancements récents du sponsor et les souhaits exprimés pour la technologie requise, et toutes les soumissions publiques déjà présentes dans cette édition. Terminé lorsque les notes listent au moins cinq projets passés ou en cours et les priorités déclarées du sponsor, le tout avec des liens.
5. Générer, puis tailler sévèrement. Écrivez au moins 20 idées, chacune construite à partir d'un problème de l'étape 3. Chaque idée nomme : la personne et la situation, le lien de preuve, la cause racine qu'elle supprime, l'intuition, ce qu'elle fait, son moment de démonstration, et ce que la technologie requise apporte que la solution ne pourrait pas faire sans. Ensuite, écartez, avec une raison d'une ligne pour chaque, toute idée qui :
   • figure sur la liste évidente ou en est une légère variation ;
   • ne peut pas nommer une personne et une situation spécifiques, ou n'a pas de lien de preuve ;
   • traite un symptôme alors que la cause racine reste en place ;
   • est une enveloppe mince, où la technologie requise ou l'IA pourrait être remplacée par un formulaire, une boîte de recherche ou un modèle avec peu de perte ;
   • a une intuition que tout le monde dirait en premier ;
   • correspond étroitement à un produit existant, un gagnant passé ou une soumission en cours (cherchez ses plus proches voisins et enregistrez-les) ;
   • enfreint une règle, ou ne peut pas atteindre un moment de démonstration fonctionnel dans le temps restant avec les compétences de cette équipe. Terminé lorsque chaque idée est écartée avec une raison ou conservée, et qu'au moins cinq sont conservées ; lorsqu'il en reste moins, revenez à l'étape 3 pour plus de problèmes plutôt que d'assouplir les coupes.
6. Noter les survivantes. Notez chaque idée conservée de 1 à 5 sur chaque critère d'évaluation, avec les pondérations du hackathon et une justification d'une ligne par note, plus trois de nos propres critères : profondeur (force de la preuve et dans quelle mesure elle supprime la cause racine), constructibilité dans le temps restant, et puissance de démonstration. Classez par le score d'évaluation pondéré plus la profondeur, en départageant sur la constructibilité.
7. Écrire la shortlist. Pour les trois premières, écrivez :
   • Argumentaire : une phrase qu'un juge répéterait.
   • Le problème : la personne, la situation, les citations de preuve avec liens, le contournement actuel, et la cause racine.
   • L'intuition : le fait non évident, et pourquoi les outils existants le manquent.
   • Voisins les plus proches : les produits ou projets existants les plus proches trouvés, et la différence concrète.
   • Cibles : piste et prix pour lesquels il concourt.
   • Scores : le tableau de notation de l'étape 6.
   • Script de démonstration : ce qui se passe dans les 30 premières secondes de la vidéo, montrant le problème de la personne puis sa suppression.
   • Ligne de coupe : ce qui doit fonctionner pour la démo, et ce qui est agréable à avoir, afin que l'équipe sache quoi abandonner lorsque le temps manque.
   • Hypothèse la plus risquée : le pari technique ou produit le plus susceptible d'échouer, et une ébauche d'une heure ou moins qui le teste avant de s'engager.

Sortie

Écrivez un fichier par hackathon dans docs/hackathons/<slug-evenement>.md, mis à jour sur place lors des exécutions ultérieures : le brief avec liens, la liste évidente, les notes de problème avec preuves, la recherche de terrain, toutes les idées générées avec leurs raisons d'écart, le tableau de notation, et la shortlist. Dans la session, montrez la shortlist et la date limite, puis demandez à l'utilisateur de choisir une idée. Lorsque l'équipe s'engage sur une idée, elle passe le skill app-compliance avant que quiconque extérieur aux juges ne l'utilise, et le skill showcase réalise sa vidéo de démonstration et son README pour la soumission.