Règlements et critères

Des liens vers Swapcard et Slack vous seront remis pour faciliter les communications directes.

Règlements généraux

    1. Les équipes devraient être composées de quatre à six personnes. Les employés du gouvernement et des villes sont invités à contribuer à l’événement comme mentor ou bénévole.
    2. Les équipes travaillent à distance pendant une période de 10 jours et les finalistes sélectionnés se présentent sur place à la finale du HackQC. Au moins un participant par équipe doit être présent et le transport est remboursé.
    3. Dès le lancement de la compétition, chaque équipe est invitée à créer une fiche de projet et à remplir la section A. Les section B et C pourront être remplies avant la fin de la compétition :
      • A. Une brève description du projet, les noms des participants formant l’équipe et s’il y a lieu, la possibilité pour un autre participant de se joindre à l’équipe
      • B. Les données et la technologie utilisée.
      • C. Ce qui a été réalisé, les défis et les bons coups, ce que vous avez appris, les suites possibles et le partage de code.
    1. Les participants développent une application qui doit utiliser au minimum un jeu de données offert sur le portail de Données Québec.
    2. L’utilisation de framework ou de scaffolding pour accélérer la réalisation est permise. Les équipes sont tenues de citer dans la fiche de projet les librairies externes utilisées ainsi que la version utilisée pour leur projet.
    3. La sélection des gagnants se fera selon une grille de critères fournie aux juges par les organisateurs et disponible sur le site HackQC.
    4. Les gagnants doivent rendre le code de leur application disponible sur une forge publique et en spécifier la licence. L’utilisation d’une licence libre approuvée OSI est fortement encouragée.
    5. Toute organisation qui fournit un prix ou une bourse additionnelle peut désigner un représentant pour juger en son nom.
    6. Le HackQC se veut un évènement inclusif, sans violence, injures ou harcèlement, en regard au sexe, à l’identité ou à l’orientation sexuelle, à l’âge, à un quelconque handicap, à l’apparence physique, au poids, à l’origine ou à la religion de qui que ce soit. Toute personne, participant, présentateur ou commanditaire qui, en ligne ou en présence, violerait ces règles pourra être rappelé à l’ordre, voire exclu de la compétition, sans préavis, sans remboursement, à la discrétion des organisateurs de l’évènement.

Processus
de sélection
des gagnants

La grille des critères d’évaluation est utilisée par le jury pour choisir les gagnants. Elle est également utilisée par les mentors pour accompagner les équipes et pour la sélection des finalistes.

Les étapes suivantes mèneront à la sélection des gagnants :

    1. Validation des sections A et B de la fiche de projet par le mentor et rétroaction.
    2. Choix des 5 à 10 équipes finalistes par les évaluateurs
    3. Présentation par les finalistes devant le jury (5 min + 3 min de questions)
    4. Choix des gagnants par le jury

Grille des critères
d’évaluation
(sélection et finale)

Critère

Description

Score

Pondération

0-3

4-7

8-10

Respect de la thématique :

Dans quelle mesure la solution est-elle en phase avec le thème du hackathon ?

L’équipe a-t-elle clairement identifié le problème qu’elle tente de résoudre ? La solution est-elle pertinente pour le thème identifié ?

Mauvais alignement avec la thématique.

Le problème n’est pas clairement formulé et la solution n’est pas pertinente.

Alignement moyen avec la thématique.

Le problème a été clairement identifié, mais la solution n’est que modérément pertinente

Alignement exceptionnel avec la thématique.

Le problème a été clairement identifié et la solution est très pertinente

20%

Innovation et originalité

Dans quelle mesure le concept de la solution est-il unique ?

Mesure dans laquelle la proposition est intelligente, inventive, et/ou habile en ce qui concerne le concept et la forme et/ou utilise des technologies novatrices (IA, RA, RV,…)

Le concept de la solution n’est pas unique.

Idée intéressante, mais pas fondamentalement intelligente ou créative.

La solution propose une nouvelle approche pour une solution existante.

Intelligente, inventive et habile ou utilise des technologies novatrices, mais ne change pas la donne

La solution est un concept unique qui a de la valeur.  

Proposition habile, intelligente, inventive ou utilisant des technologies novatrices qui génèrent enthousiasme et appui.

20%

Utilisation des données et couverture territoriale (Application utilisable dans plus d’une municipalité)

Dans quelle mesure la solution utilise-t-elle les données ouvertes ?

Nombre de jeux de données, nombre d’organisation dont des données ouvertes sont utilisées, nombre de jeu de données normalisées utilisés

La solution utilise peu de données ouvertes, et de façon accessoire. Les données ouvertes ne sont pas indispensables à la solution.

La solution exploite peu de données ouvertes et aucune ne sont des données normalisées.

La solution exploite des données normalisées ou qui touchent plusieurs municipalités.

20%

Expérience du citoyen

Comment est l’expérience en général pour le citoyen utilisant le produit, facile ou agréable à utiliser?

Flux logique et fonctionnalité

L’apparence mérite d’être améliorée. Les besoins de l’utilisateur aident à naviguer dans l’application.

La solution ne sert pas les attentes ou comportements des clients identifiés. Mauvaise expérience de l’utilisateur.

Bonne apparence. Principales caractéristiques faciles à trouver, certaines fonctionnalités sont trop enfouies.

La solution correspond bien aux attentes et comportements des clients ciblés.
Bonne expérience utilisateur

Très bonne apparence. La navigation est facile et intuitive.

La solution correspond très bien aux attentes et comportements des clients ciblés. Excellente expérience utilisateur.

10%

Fonctionnalité

Dans quelle mesure le produit ou la solution peut-il être utilisé ?

Application échoue sur certaines fonctions.

L’application fonctionne, mais n’est pas entièrement fonctionnelle.

Application est entièrement fonctionnelle.

10%

Approche technique

Dans quelle mesure l’approche technique de la solution est-elle efficace, réaliste et pertinente ?

La solution est-elle techniquement possible? Comment la solution peut-elle être déployée facilement? La solution répond-elle aux besoins d’affaires?

L’approche technique de la proposition n’est pas réaliste.

La proposition n’est pas alignée techniquement avec les besoins de la solution.

L’approche technique est quelque peu réaliste et démontre une faisabilité.

La proposition répond moyennement aux besoins de la solution.

L’approche technique est réaliste et bien démontrée.

L’approche technique est en adéquation avec la solution proposée.

10%

Qualité de présentation et potentiel commercial

Dans quelle mesure la présentation permet-elle d’apprécier la solution ?

Le problème et la solution proposée sont bien identifiés. Clientèle cible et modèle d’affaires identifiés. Démonstration de l’application.

La présentation ne permet pas d’apprécier la solution et son potentiel.

Problème, solution, clientèle cible ou modèle d’affaires non identifiés. Démonstration de l’application échoue lors de la présentation.

La présentation permet en partie d’apprécier la solution et son potentiel.

Un ou des éléments demandés ne sont pas identifiés. Démonstration de l’application fonctionne en partie lors de la présentation.

La présentation permet d’apprécier pleinement la solution et son potentiel.

Problème, solution, clientèle cible et modèle d’affaires bien identifiés. Démonstration de l’application réussie et EFFET WOW!

10%