Owen Sound : Un plan d'affaires municipal sur quatre ans

Accueil › Information, confidentialité et indépendance numérique canadienne › Chapitre 33

Information, confidentialité et indépendance numérique canadienne

Chapitre 33map.ca comme infrastructure publique

16,584 mots · Mike Seiler · Owen Sound, Ontario

Ouvrir dans le lecteur →

Votez sur les propositions, écoutez l’audio, lisez les examens, cherchez dans tout le plan.

Dans ce chapitre

La proposition initiale est délibérément ambitieuse.

Elle stipule :

Ces idées partagent un principe commun :

Certains systèmes numériques deviennent suffisamment importants pour la vie civique que le public ne devrait pas être en dépendance permanente vis-à-vis de plateformes publicitaires, d'organismes politiques ou de fondateurs privés pour y accéder.

Mais il existe un principe tout aussi important :

Une idée d'intérêt public ne justifie pas une mauvaise transaction publique.

J'ai une relation avec map.ca et les idées associées qui sont proposées.

Cela rend la question de la gouvernance plus importante, pas moins.

La ville ne devrait jamais être tenue de :

adopter la plateforme de Mike parce que Mike est devenu maire.

La séquence correcte est la suivante :

  1. définir le problème public ;
  2. définir le standard public ouvert ;
  3. établir les exigences juridiques et de gouvernance ;
  4. rendre publics tous les intérêts privés pertinents ;
  5. évaluer indépendamment la plateforme ;
  6. comparer les alternatives ;
  7. permettre au conseil municipal et au personnel professionnel de décider ;
  8. ne pas poursuivre que si le cas public subsiste sans l'influence du fondateur.

Le document de travail RealMap recommande déjà cette approche. Il identifie un standard municipal ouvert comme première étape préférée, avec un organisme sans but lucratif d'intérêt public indépendant à considérer uniquement si un transfert s'avère légal, abordable et exempt d'avantage privé. La propriété municipale directe est spécifiquement identifiée comme l'option la plus lourde, et non comme le point de départ recommandé.

Cela devrait devenir la règle map.ca également.

Standard public d'abord. Plateforme ensuite. Fondateur en dernier.

33.1Ce que signifie l'infrastructure publique

Appeler quelque chose infrastructure publique devrait signifier plus que :

Le public l'utilise.

Des millions de personnes utilisent des plateformes privées chaque jour.

L'infrastructure publique devrait satisfaire un test plus exigeant.

Elle devrait offrir un bénéfice public défini tout en protégeant :

Le plus important est :

Le but public devrait survivre à l'entreprise, à la technologie et à la personne qui l'a d'abord construite.

33.2Le test d'infrastructure publique

Avant qu'un élément puisse être décrit par la ville comme infrastructure publique, il devrait répondre au moins à ces questions.

But

Quel problème public résout-il ?

Accès

Qui peut l'utiliser ?

Coût

Qu'est-ce qui est gratuit et qu'est-ce qui est payant ?

Gouvernance

Qui contrôle les règles ?

Données

Qui contrôle l'information ?

Vie privée

Qu'est-ce qui est collecté ?

Neutralité

Est-ce que l'influence politique ou commerciale peut modifier la visibilité ?

Portabilité

Est-ce que les renseignements peuvent être transférés ailleurs ?

Accessibilité

Les personnes vivant avec un handicap peuvent-elles l'utiliser ?

Résilience

Que se passe-t-il si les systèmes tombent en panne ?

Finances

Qui paiera à long terme ?

Sortie

Est-ce qu'Owen Sound peut cesser d'utiliser le service ?

Si les réponses à ces questions sont faibles :

Il n'est pas prêt à devenir une infrastructure civique.

33.3« Propriété publique protégée » : Besoin d'une définition

La proposition initiale stipule que map.ca devrait passer en propriété publique protégée avant son adoption municipale.

Cette expression exprime un objectif.

Ce n'est pas, à elle seule, une structure juridique.

Avant qu'elle n'apparaisse dans une proposition finale du conseil, des professionnels juridiques et en gouvernance devront déterminer quelle structure peut effectivement réaliser les protections prévues.

Des modèles possibles incluent :

Le nom de la structure juridique est moins important que le fait que les protections publiques fonctionnent effectivement.

33.4Priorité au standard ouvert

Mon point de départ municipal préféré est le suivant :

Owen Sound définit le standard, pas la plateforme.

La Ville peut établir des exigences pour les renseignements d'intérêt public, telles que :

Ensuite, map.ca ou un autre système admissible peut être évalué selon ce standard.

Cela empêche que la politique publique soit écrite autour d'un seul produit privé.

33.5map.ca doit pouvoir échouer à l'évaluation

C'est l'une des mesures de protection les plus importantes de tout le plan d'affaires.

Le conseil doit conserver la capacité de conclure :

Le concept d'intérêt public est bon, mais map.ca n'est pas la bonne mise en œuvre.

Si cette conclusion est politiquement ou contractuellement impossible :

L'évaluation n'était jamais indépendante.

33.6Aucune adoption municipale prédéterminée

Une campagne peut démontrer map.ca de manière privée.

Elle peut :

Elle ne devrait pas être présentée avant l'approbation du conseil comme :

la plateforme officielle future d'Owen Sound.

La formulation précise est :

Une plateforme d'intérêt public développée de manière privée ou indépendante, proposée pour une évaluation future.

33.7La Ville ne devrait pas commencer par acheter map.ca

La première motion du conseil ne devrait pas être :

Acheter map.ca.

Elle devrait plutôt être proche de :

Définir les exigences en matière d'information numérique publique d'Owen Sound et déterminer s'il y a un rôle municipal.

Le produit suit la politique.

Et non l'inverse.

33.8Inventaire de ce qui existe réellement

Avant d'aborder le transfert, documentez indépendamment ce que signifie « map.ca ».

Les actifs potentiels peuvent inclure :

Négociez pas le transfert d'un nom de marque sans savoir ce qu'il recouvre.

33.9Transférez uniquement ce dont le public a besoin

Une transition publique n'exige pas nécessairement le transfert de chaque élément associé :

Déterminez les actifs minimums nécessaires à l'objectif public.

Tout le reste peut demeurer :

selon la structure finale.

Cela réduit la responsabilité publique inutile.

33.10La propriété du nom de domaine est importante

Pour une plateforme d'infrastructure publique axée sur les cartes, le nom de domaine lui-même est un actif important.

Si le transfert s'effectue vers une structure d'intérêt public :

ne devrait plus dépendre du compte personnel d'une seule personne.

Un nom de domaine public devrait être contrôlé institutionnellement.

33.11La propriété intellectuelle doit être claire

Avant l'adoption publique, établissez :

Un transfert de nom de domaine sans les droits d'exploitation nécessaires peut produire peu de valeur publique.

Un transfert de logiciel sans les droits de nom de domaine nécessaires peut créer un problème différent.

Comprenez l'ensemble du package.

33.12Évaluation indépendante

Toute proposition de :

d'actifs liés à map.ca devrait faire l'objet d'une évaluation indépendante.

Le document de travail RealMap exige déjà une évaluation à distance des actifs, licences, services ou transferts et demande que les relations de propriété et financières soient divulguées.

L'évaluation ne signifie pas que la ville doit payer le montant évalué.

Cela signifie que le public doit comprendre ce qui est transféré.

33.13Un transfert à un dollar est quand même une transaction

Si un fondateur dit :

Je vais offrir cela au public pour un dollar,

cela pourrait être généreux.

Cela nécessite quand même une évaluation de :

Le prix d'achat n'est pas le coût total.

33.14Une donation peut quand même créer un conflit

Offrir quelque chose ne supprime pas automatiquement un conflit.

Une transfert public pourrait quand même :

Ces effets doivent être évalués indépendamment.

33.15Assistance municipale aux entreprises privées

La Loi sur les municipalités de l'Ontario contient des restrictions spécifiques concernant l'assistance municipale aux entreprises manufacturières, commerciales et aux entreprises en général, ainsi que des dispositions légales régissant les cas où l'assistance peut être autorisée. Toute entente dans laquelle la ville accorde de l'argent, des biens, des services commerciaux gratuits ou un autre avantage économique à map.ca ou aux entreprises l'utilisant nécessite donc une revue juridique municipale appropriée plutôt qu'une supposition que l'objectif d'une bonne politique économique rend automatiquement l'entente licite.

Cette même prudence s'applique à :

Concevez le bénéfice public dans le respect de la loi.

La Loi sur le conflit d'intérêts des municipalités de l'Ontario traite à la fois des intérêts pécuniaires directs et indirects et limite l'utilisation de la charge de fonction pour influencer des questions où les règles légales sur les conflits s'appliquent.

Par conséquent, si map.ca est soumis au conseil municipal alors que je conserve un intérêt financier pertinent, je ne devrais pas inventer mon propre interprétation quant à savoir si je peux participer.

Le processus devrait inclure :

33.17Un standard politique plus élevé

Même si les règles légales strictes sur les conflits ne s'appliquent pas à un aspect particulier, j'appliquerais un test plus large sur la confiance publique :

Un résident raisonnable penserait-il que je pourrais personnellement bénéficier de cette décision ?

Si oui :

Retirer le maire de :

La confiance publique est importante à côté du respect minimum de la loi.

33.18Aucun raccourci de type maire fort

Aucune autorité spéciale de maire ne devrait être utilisée pour imposer à la municipalité l'adoption d'une plateforme liée au maire.

Même si une autorité pourrait théoriquement être utilisée dans une situation future :

Le problème de conflit et de confiance publique devrait empêcher ce chemin.

La plateforme devrait réussir grâce à :

Pas par le pouvoir du maire.

33.19Aucun design de commande de fondateur

La personne associée à la plateforme proposée ne devrait pas rédiger un appel d'offres dont les exigences techniques décrivent commodément uniquement son propre produit.

Des professionnels municipaux indépendants devraient définir :

Si map.ca répond réellement à ces exigences :

Il peut être évalué de façon appropriée.

33.20Aucune évaluation par le fondateur

De même, le fondateur ne décide pas :

Cette plateforme vaut X $.

Des professionnels indépendants déterminent la valeur en utilisant des méthodes appropriées.

Le fondateur peut fournir :

Pas la conclusion publique finale.

33.21Aucun droit de veto du fondateur

Si map.ca devient finalement une infrastructure publique :

J'aurais dû perdre la capacité de faire un veto sur ce que l'institution publique en fait.

Le propriétaire ou l'organe de gouvernance public doit pouvoir :

selon sa gouvernance légale.

Un actif public ne peut pas rester sous contrôle privé simplement parce que son créateur a des opinions fortes.

33.22Période de transition du fondateur

Un rôle limité de transition peut être utile si le fondateur possède des connaissances techniques ou institutionnelles importantes.

Ce rôle devrait comporter :

L'objectif devrait être :

Rendre le fondateur inutile à l'exploitation courante.

C'est là une institutionalisation réussie.

33.23Aucune redevance perpétuelle

Un transfert d'intérêt public devrait éviter de créer une redevance privée perpétuelle liée à :

sauf si un cas extraordinaire, examiné indépendamment, démontre pourquoi cet arrangement sert la valeur publique.

Le modèle plus clair est la propriété publique ou des droits clairement limités sans un péage personnel perpétuel.

Si map.ca dépend d'une entreprise privée affiliée à son fondateur pour :

ces relations doivent subir la même vérification qu'importe quel autre fournisseur.

Le transfert public ne devrait pas simplement déplacer l'actif visible tout en laissant chaque contrat d'exploitation important à l'intérieur d'une entreprise privée affiliée.

33.25Modèle de gouvernance A : Rester privé

map.ca pourrait simplement rester privé.

Dans ce modèle :

Cela demeure un résultat légitime.

L'ambition d'intérêt public n'exige pas l'adoption par le gouvernement.

33.26Modèle de gouvernance B : Organisation à but non lucratif indépendante d'intérêt public

Une autre option consiste à transférer des actifs définis vers une organisation indépendante dotée de :

Le document actuel sur la gouvernance de RealMap identifie ce modèle comme une structure possible, mais uniquement s'accompagnant d'une évaluation, d'appoints indépendants, de conditions de transfert et de contrôles des intérêts des fondateurs.

Ce modèle mérite d'être étudié sérieusement.

Il ne devrait pas être supposé automatiquement légal ou suffisant.

33.27Modèle de gouvernance C : Norme ouverte municipale

Le modèle municipal le plus fort pourrait simplement être :

La ville publie les règles concernant les informations civiques et permet aux plateformes admissibles d'interagir.

Le travail actuel sur RealMap identifie ce modèle comme présentant un risque moindre de monopole tout en préservant le choix et l'interopérabilité.

Cela permet à map.ca de se prouver sans imposer au conseil municipal de posséder la technologie.

33.28Modèle de gouvernance D : Propriété municipale

Une propriété directe par la ville pourrait offrir la responsabilité municipale la plus formelle.

Cela impliquerait également la responsabilité en matière de :

Le document de travail de RealMap identifie l'exploitation directe par la municipalité comme entraînant la plus lourde charge en personnel, en confidentialité, en sécurité informatique et en déplacement du marché, et ne le recommande pas comme première étape.

Je suis d'accord.

La séquence sur quatre ans devrait donc être :

Premièrement

Définir la norme publique.

Deuxièmement

Tester map.ca de manière indépendante.

Troisièmement

Considérer une structure de propriété indépendante d'intérêt public si cela est justifié.

Quatrièmement

Permettre aux municipalités d'intégrer via des normes ouvertes.

Cinquièmement

Considérer une propriété municipale plus profonde uniquement si des preuves établissent ultérieurement une raison convaincante.

Ne pas passer directement d'un prototype de campagne à une technologie appartenant à la ville.

33.30Conseil d'intérêt public

Si une organisation indépendante détient finalement des actifs publics, son conseil d'administration ne devrait pas devenir :

Les compétences potentielles pourraient inclure :

Le modèle d'attribution exact nécessite une conception juridique.

Le principe est l'indépendance.

33.31Aucune majorité permanente des fondateurs

Le créateur de la plateforme peut être utile pendant la période de transition.

Le fondateur ne devrait pas détenir une majorité permanente sur un conseil d'intérêt public.

Sinon :

La propriété a changé sur le papier.

Le contrôle n'a pas changé.

33.32Aucune majorité politique municipale permanente non plus

Si la plateforme sert finalement plusieurs communautés, il pourrait également être inapproprié qu'un seul conseil municipal contrôle chaque décision future.

Une plateforme d'intérêt public nationale ou intermunicipale nécessite une gouvernance qui puisse survivre à :

Owen Sound peut servir de terrain d'essai sans devenir le dirigeant permanent du réseau.

33.33Municipalités participantes

Si d'autres municipalités décident ultérieurement d'utiliser le système, leur rôle devrait être défini.

Des mécanismes possibles peuvent inclure :

Ne concevez pas une structure de gouvernance nationale avant qu'une municipalité n'ait prouvé le concept.

Adaptez la gouvernance à l'adoption réelle.

33.34La mission publique

Toute organisation d'intérêt public devrait avoir une mission simple.

Par exemple :

Rendre facile la découverte, la portabilité et l'accessibilité d'informations civiques et communautaires liées à un lieu, sans vendre l'attention ou le comportement personnel.

La mission devrait encadrer l'organisation.

Elle ne devrait pas être suffisamment large pour justifier l'entrée dans chaque entreprise technologique imaginable.

33.35Protection de la mission

Si des actifs sont transférés à un prix inférieur à la valeur du marché pour un objectif d'intérêt public, le transfert devrait examiner comment cet objectif reste protégé si l'organisation change ultérieurement :

Les mécanismes juridiques possibles dépendent de la structure organisationnelle finale.

Le principe est :

Les actifs publics ne devraient pas devenir des bénéfices privés sans avertissement.

33.36Dissolution

Avant de créer une organisation, décidez ce qui adviendra si elle ferme.

Des questions incluent :

La planification de la dissolution fait partie de la création.

33.37Rapport annuel public

Une organisation map.ca d'intérêt public devrait publier un rapport annuel couvrant au minimum :

L'infrastructure publique exige une responsabilisation publique.

33.38Vérification financière indépendante

L'étendue de la vérification financière devrait croître avec l'organisation.

Au minimum :

Une organisation publique ne devrait pas reposer sur :

Confiez-nous.

Si les membres du conseil d'administration ou les fondateurs ont des entreprises qui contractent avec la plateforme, ces relations doivent être divulguées et gérées.

Le registre devrait identifier :

Les transactions avec des parties liées peuvent parfois être légitimes.

Le problème réside dans les transactions avec des parties liées cachées.

33.40Mur de campagne

Aucune liste de :

ne devrait être transférée vers l'infrastructure civique de map.ca.

De même, les données de service public de map.ca ne devraient jamais être transférées à une campagne.

Deux mondes

Campagne

et

service public

doivent demeurer techniques et juridiquement séparés.

33.41Aucun avantage pour l'incumbent

Un maire futur ne devrait pas pouvoir envoyer :

Un message du maire

par l'entremise des comptes des résidents pour un avantage électoral.

Les communications officielles de la municipalité doivent comporter :

La plateforme doit servir l'institution.

Et non l'incumbent.

33.42Marque publique

Si map.ca devient une infrastructure publique indépendante, la marque devrait rendre le statut de gouvernance compréhensible.

Les résidents devraient être en mesure de savoir :

Est-ce la Ville?

Est-ce une organisation indépendante d'intérêt public?

Est-ce une entreprise privée?

Est-ce une page soumise par la communauté?

Ne brouillez pas intentionnellement l'identité institutionnelle.

33.43Navigation de base sans compte

La plupart des informations publiques devraient être consultables sans :

Une personne cherchant :

n'ont pas besoin de se faire identifier.

Où l'anonymat fonctionne

Vérification uniquement là où la vérification est nécessaire.

33.44Compte civique facultatif

Un compte peut être utile pour :

La création d'un compte devrait rester facultative pour la navigation de base.

Aucun compte ne devrait devenir une condition de la citoyenneté ordinaire.

33.45La proposition « Courriel pour la vie »

La proposition source promet à chaque résident un courriel pour la vie.

Je conserverais l'ambition.

Je changerais la certitude.

Une ville ne devrait pas promettre un service électronique littéralement pour l'éternité avant d'avoir établi :

La promesse publique finale devrait être :

Développer une adresse civique permanente et portable conçue pour rester avec le résident à long terme, et ne faire aucune promesse sur la durée de vie qu'une fois que la gouvernance peut véritablement la soutenir.

33.46Une adresse civique plutôt qu'une grande boîte de courrier

Le premier modèle à tester pourrait être un alias courriel civique plutôt qu'une boîte postale municipale complète.

Par exemple, le service pourrait potentiellement fournir une adresse stable qui redirige vers un compte courriel choisi par le résident.

Les avantages pourraient inclure :

La conception technique nécessite une revue professionnelle.

Le principe est :

Propriété de l'adresse sans exiger que le gouvernement stocke toute votre correspondance.

33.47Pas d'identification gouvernementale

Une adresse map.ca ne devrait pas prouver automatiquement :

C'est un outil de communication.

Rien de plus à moins qu'un système de vérification légal et distinct soit délibérément créé.

33.48Ne pas placer le vote dans le compte courriel

VoteMap ou d'autres systèmes de consultation civique ne devraient pas reposer uniquement sur la possession d'une adresse map.ca comme preuve d'admissibilité pour voter.

La vérification pour :

doit suivre les exigences appropriées à chaque processus.

La commodité ne devrait pas affaiblir l'intégrité démocratique.

33.49Portabilité lorsqu'une personne déménage

La vision originale dépasse une seule ville.

Une adresse civique conçue pour suivre une personne ne devrait pas cesser simplement parce qu'elle déménage de :

C'est là un autre motif pour lequel une identité civique à long terme pourrait s'inscrire mieux dans une structure indépendante axée sur l'intérêt public que dans un seul service informatique municipal.

33,50 Aucune prétention de portabilité forcée

Tant que d'autres communautés ou une organisation gouvernementale plus vaste n'auront pas accepté :

Owen Sound ne peut pas promettre :

Chaque municipalité canadienne reconnaîtra cette adresse.

Nous pouvons établir le standard.

Nous pouvons inviter à la participation.

Nous ne pouvons pas légiférer sur le système d'une autre municipalité.

33,51 Récupération de compte

Un compte conçu pour durer crée un problème sérieux de récupération.

Les personnes :

Concevez soigneusement la récupération.

Évitez d'utiliser inutilement des renseignements d'identité sensibles simplement parce que la récupération de compte est difficile.

33,52 Mort et héritage numérique

Les comptes à long terme nécessitent une politique concernant :

N'abandonnez pas les familles à deviner ce qui va se produire.

L'infrastructure numérique finit par rencontrer la vie humaine ordinaire.

33,53 Mineurs

Ne créez pas automatiquement des comptes numériques à vie pour chaque enfant sans considérer soigneusement :

YouthMap devrait fonctionner sans exiger que les enfants créent des profils publics permanents.

33,54 Usurpation d'identité par courriel

Un système de courriel municipal pourrait être abusé pour :

Les modalités et l'application doivent traiter les abus réels tout en préservant la communication légitime.

Une adresse permanente ne signifie pas une immunité permanente face aux règles.

33,55 Suspension de compte

Si un compte est restreint :

Fournir une explication appropriée :

L'infrastructure civique permanente ne devrait pas permettre la suppression arbitraire de comptes basée sur un désaccord politique.

33,56 Ne promettez pas un « courriel sécurisé »

Aucun fournisseur de courriel ne peut garantir que les résidents ne recevront jamais :

La plateforme peut offrir :

Ne pas présenter la technologie comme éliminant la tromperie humaine.

33.57Séparer l'identité de la conduite

Un compte municipal ne devrait pas devenir silencieusement la clé reliant :

Ce niveau d'intégration peut être pratique pour le logiciel.

Cela est néfaste pour la vie privée citoyenne.

33.58Une porte ne signifie pas un profil unique

map.ca peut offrir une seule porte d'entrée publique sans créer un dossier universel des résidents.

Derrière l'interface, les informations devraient rester séparées selon :

Interface pratique

Responsabilités des données séparées

Les deux sont possibles.

33.59Aucun score social citoyen

Ne jamais créer un score de résident basé sur :

Il ne devrait pas y avoir de :

bon score de citoyen.

La participation publique est volontaire.

Les droits ne sont pas acquis par l'activité sur la plateforme.

33.60Carte publique, pas carte des personnes

La carte centrale devrait principalement représenter :

Elle ne devrait pas représenter publiquement :

Cartographiez l'opportunité. Protégez la personne.

33.61Couches d'infrastructure publique

Des couches publiques vérifiées pourraient inclure :

Chaque couche devrait identifier :

33.62Couche d'infrastructures sensibles

Tous les biens municipaux ne doivent pas apparaître sur la carte publique.

Des informations détaillées concernant :

peuvent devoir rester internes.

La version publique peut montrer ce dont les résidents ont besoin sans publier d'informations qui créent un risque inutile.

33.63Informations officielles, partenaires et communautaires

Chaque entrée sur la carte devrait rendre le type de source compréhensible.

Catégories possibles :

Officiel

Publié ou validé par l'autorité publique compétente.

Partenaire

Géré par une organisation participante identifiée.

Communautaire

Soumis par un utilisateur et non nécessairement vérifié officiellement.

Cela réduit la tentation de faire paraître chaque élément comme s'il avait la même autorité.

33.64La vérification doit signifier quelque chose de spécifique

Un badge "vérifié" devrait expliquer :

Qu'est-ce qui a été vérifié ?

Les possibilités incluent :

N'utilisez pas une case bleue pour suggérer que tout à propos d'une organisation est fiable.

33.65Date de la dernière vérification

Les informations liées à un lieu changent.

Chaque liste publique importante devrait afficher :

Un résident devrait pouvoir distinguer :

confirmé hier

de

soumis il y a cinq ans.

33.66Correction communautaire

Les utilisateurs devraient pouvoir signaler :

Un signalement déclenche une vérification.

Il ne réécrit pas automatiquement les informations officielles.

33.67Historique des corrections

Pour les biens publics officiels importants, conservez suffisamment d'historique pour comprendre :

N'inscrivez pas en public de manière permanente chaque correction orthographique.

Utilisez votre jugement.

33.68Désaccords

Une plateforme de cartographie :

donneront lieu à des contestations.

Il devrait y avoir des procédures pour :

La plateforme ne devrait pas tenter de résoudre des litiges juridiques complexes en dehors de ses compétences.

Renvoyer les affaires de façon appropriée.

33.69Modération impartiale

Les informations communautaires peuvent inclure des organisations ayant :

des points de vue.

La modération devrait se concentrer sur des problèmes définis tels que :

Ne pas supprimer des organisations communautaires licites simplement parce que les administrateurs de la plateforme sont en désaccord avec elles.

33.70Calendrier communautaire

Le plan initial prévoit :

tous les événements, activités et occasions en un seul endroit sécurisé, gratuit pour être listé, gratuit pour être consulté, sans publicité, sans traçage.

Cela devrait devenir l'une des premières fonctionnalités d'intérêt public.

Le mot sécurisé devrait signifier :

Il ne devrait pas signifier que la Ville garantit la sécurité physique de chaque événement tiers.

33.71Catégories du calendrier

Des catégories possibles incluent :

Les utilisateurs décident ce qu'ils veulent voir.

La plateforme ne devrait pas décider algorithmiquement quelles activités communautaires méritent l'attention.

33.72Aucun classement payant du calendrier

Une grande organisation ne devrait pas apparaître au-dessus d'une activité communautaire locale simplement parce qu'elle a payé davantage.

Trier selon des facteurs transparents tels que :

La visibilité n'est pas à vendre.

33.73Événements politiques

Si les listes d'événements publics licites respectent les règles neutres du calendrier, les événements politiques ne devraient pas être exclus simplement parce qu'ils sont politiques.

La liste devrait clairement identifier :

La ville qui met à disposition un calendrier neutre ne cautionne pas l'événement.

33.74Événements liés à la foi

La même disposition s'applique à :

Règles d'égalité d'affichage.

Aucune préférence religieuse.

Aucune exclusion anti-religieuse.

33.75Événements commerciaux

Les entreprises peuvent également organiser des événements publics légitimes.

La plateforme devrait définir s'ils sont admissibles et, le cas échéant, comment.

Ne forcez pas chaque événement commercial à figurer dans :

Un calendrier public est utile en partie parce qu'il montre ce qui se passe réellement.

33.76RealMap.ca

RealMap doit demeurer un service distinct au sein du système plus vaste.

Son standard d'intérêt public a été établi à l'article 25 :

La ville devrait pouvoir adopter ces normes sans adopter la plateforme RealMap.

33.77Les données de RealMap doivent rester séparées

Un résident qui consulte :

des maisons comprises entre 450 000 $ et 550 000 $

ne devrait pas voir automatiquement modifier :

La recherche de propriétés est une information sensible sur le comportement.

Gardons-la séparée.

33.78YouthMap.ca

Le plan initial prévoit que YouthMap.ca cartographie les opportunités pour les jeunes à travers le comté de Grey et au-delà.

Le principe du Civic Corps s'applique :

Cartographier les opportunités. Pas les jeunes.

YouthMap peut lister :

Il ne devrait pas publier publiquement les noms d'individus jeunes.

33.79Vérification des opportunités

Les opportunités pour les jeunes devraient indiquer :

La carte n'offre aucune garantie :

Les organismes demeurent responsables de leurs programmes.

33.80Confidentialité des jeunes

Un jeune ne devrait pas être tenu de publier :

afin de consulter les possibilités.

Les demandes s'effectuent par l'intermédiaire de l'organisme compétent.

La carte demeure une couche d'information.

33.81Magasiner local

map.ca pourrait également être relié à la stratégie Magasiner local.

Les résidents pourraient trouver :

La découverte publique de base devrait demeurer distincte de la mise en page payante.

Une entreprise disposant d'un petit budget marketing ne devrait pas disparaître de la carte.

33.82Étiquettes d'appartenance locale

Là où l'information sur les entreprises identifie :

les critères devraient être factuels et publiés.

Ne pas faire d'hypothèses basées sur un nom de marque.

Les entreprises devraient pouvoir corriger leur classification.

33.83Information publique sur les entreprises et assistance municipale

Si la Ville elle-même finance ou fournit des services gratuits aux entreprises commerciales par l'intermédiaire de map.ca, une révision juridique municipale est nécessaire, car la loi de l'Ontario contient des règles spécifiques concernant l'assistance aux entreprises et aux entreprises commerciales.

Cela signifie que nous devons séparer :

Ne les mélanger pas de manière aléatoire.

33.84Fonctionnalités payantes

Un opérateur d'intérêt public futur pourrait offrir des services payants facultatifs.

Dans ce cas :

Les fonctionnalités payantes ne devraient jamais acheter une mise en évidence supérieure au sein de la couche d'information publique de base.

Les services payants possibles pourraient inclure :

Le noyau public demeure neutre.

33.85Aucune commission de transaction

L'infrastructure publique de map.ca ne devrait pas être tenue de prendre une part chaque fois que les résidents :

Là où c'est possible, les transactions devraient rester directement entre :

L'infrastructure aide les gens à se trouver mutuellement.

Elle n'a pas besoin de posséder la transaction.

33.86Aucune vente de leads

Un résident cherchant :

plombier

ne devrait pas devenir un bien mis aux enchères auprès de plusieurs plombiers.

Une personne cherchant des renseignements devrait obtenir des renseignements.

Si elles demandent explicitement aux entreprises de les contacter :

Il s'agit d'un service différent et nécessite un consentement clair.

33.87Aucune publicité

La proposition initiale du calendrier s'engage explicitement à ne pas faire de publicité et à ne pas faire de traçage.

Je voudrais prolonger cette philosophie à la couche cartographique publique fondamentale.

Couche civique fondamentale

Non :

Si des fonctionnalités commerciales existent ailleurs :

Garder-les visiblement séparées de l'infrastructure publique.

33.88Aucun traçage comportemental

Le système ne devrait pas établir de profils tels que :

Ce résident fréquente ces églises, recherche ces maisons, visite ces entreprises et consulte ces événements politiques.

Il s'agit précisément du type de concentration d'information qu'un système public devrait éviter.

Mesurer la plateforme sans profiler le résident.

33.89Analyse minimale

Des analyses utiles pourraient inclure :

Là où c'est possible, obtenir ces mesures sans conserver des historiques comportementaux individuels à long terme.

La question est :

Le service fonctionne-t-il ?

Et non :

Qui est cette personne et que pouvons-nous en déduire ?

33.90Aucune vente de données

L'opérateur d'intérêt public ne devrait pas se financer par la vente de :

Si une proposition future modifie cette règle :

Elle devrait nécessiter une décision explicite de gouvernance publique.

Et non une mise à jour silencieuse des conditions d'utilisation.

33.91Loi municipale sur la vie privée

Les systèmes d'information municipaux sont soumis au cadre provincial sur la vie privée de l'Ontario. La LIPM limite la collecte d'informations personnelles au nom d'une institution municipale aux cas autorisés par la loi, utilisés pour l'application de la loi, ou nécessaires à l'administration adéquate d'une activité autorisée légalement.

Cela fournit une question utile de conception :

Pourquoi avons-nous besoin de ces informations ?

Si le service public fonctionne sans elles :

Ne les collectez pas.

33.92Les rôles de l'opérateur doivent être juridiquement définis

Si map.ca est géré par :

les rôles en matière de vie privée peuvent varier.

Avant le lancement, documenter :

Ne pas supposer qu'une structure à distance armée résout automatiquement les obligations en matière de vie privée.

33.93Séparer les dossiers municipaux du contenu des utilisateurs

Des informations différentes peuvent avoir différents statuts.

Exemples :

Dossier municipal

Une demande de service soumise à la mairie.

Contribution publique

Un résident met à jour une note sur un sentier public.

Contenu d'utilisateur privé

Une liste personnelle enregistrée.

La plateforme devrait reconnaître la différence.

La conservation et l'accès devraient suivre l'objectif et la loi applicable.

33.94Droits sur le contenu des résidents

Les conditions devraient expliquer ce qui se produit lorsque les résidents soumettent :

La plateforme pourrait avoir besoin d'une licence pour afficher le matériel.

Cela ne nécessite pas nécessairement d'acquérir un droit d'utilisation illimité à perpétuité.

Utiliser des conditions compréhensibles.

33.95Supprimer ce qui peut être supprimé

Lorsque les informations ne sont pas requises en tant que :

les utilisateurs devraient avoir un contrôle raisonnable pour supprimer leur contenu privé sur la plateforme.

Expliquer les exceptions.

Ne pas faire de publicité :

Supprimer signifie supprimé

si les sauvegardes ou l'obligation légale de conservation empêchent une destruction immédiate et complète.

33.96L'accessibilité est un travail de conception obligatoire

Si map.ca devient un site Web ou un service Web municipal, les règles d'accessibilité de l'Ontario s'appliquant aux sites Web publics désignés doivent être intégrées à la mise en œuvre. Les normes intégrées actuelles de l'Ontario exigent que les sites Web et le contenu Web des organisations du secteur public désignées soient conformes au niveau AA de WCAG 2.0 selon le règlement.

L'accessibilité devrait donc être testée avant l'adoption.

Ne pas l'ajouter après les plaintes.

33.97Tests d'accessibilité

Utiliser à la fois :

Inclure des personnes qui utilisent :

Un rapport logiciel indiquant :

98 pour cent accessible

ne nous dit pas si une personne réelle peut accomplir la tâche.

33.98Accessibilité des cartes

Les cartes posent des défis particuliers en matière d'accessibilité.

Les informations importantes devraient également être accessibles par le biais de :

Un résident qui ne peut pas interpréter visuellement une carte ne devrait pas être exclu des informations qu'elle représente.

33.99Informations d'accessibilité objectives

Pour les lieux publics, les caractéristiques objectives des cartes telles que :

Éviter les promesses générales telles que :

Complètement accessible

sauf si une autorité compétente soutient effectivement cette conclusion.

Décrire.

Ne pas sur-certifier.

33.100Papier et accès téléphonique

map.ca devrait améliorer l'information publique.

Il ne devrait pas éliminer :

Un résident peut appeler la mairie et demander :

Où se trouve la salle de bain accessible la plus proche ?

Le personnel devrait pouvoir utiliser le même système d'information publique pour répondre.

La technologie sert les deux côtés de la conversation.

33.101Terminaux publics

Là où c'est utile, les ordinateurs publics existants situés à :

peuvent offrir un accès aux résidents qui n'ont pas leurs propres appareils.

Ne pas construire un réseau de kiosques spécialisés map.ca avant d'avoir démontré un besoin.

Utiliser ce qui existe déjà.

33.102Premier à agir

map.ca pourrait devenir à terme une porte visuelle vers le système de services Premier à agir.

Un résident pourrait marquer :

L'élément important n'est pas le repère.

L'élément important est ce qui suit :

  1. le rapport entre dans le système de services officiel ;
  2. le département approprié le reçoit ;
  3. le statut est suivi ;
  4. le résident reçoit une réponse appropriée.

Ne pas construire une carte de signalement publique déconnectée des opérations réelles.

33.103Signalement public versus dossier de service privé

Un résident peut signaler publiquement :

Une lampe de rue est éteinte ici.

Le dossier de service interne de la ville peut contenir :

Ces données ne sont pas nécessairement identiques à celles accessibles publiquement.

L'interface devrait séparer :

33.104Aucune carte publique des signaleurs

Une carte d'issues publiques ne devrait pas indiquer :

Mike Seiler a signalé ce nid-de-poule depuis cette adresse.

L'issue est importante.

Le signaleur ne l'est généralement pas.

33.105Index des infrastructures

L'index des infrastructures et des systèmes pourrait alimenter des couches cartographiques publiques appropriées.

Un résident pourrait voir :

Les informations sensibles sur l'ingénierie et la sécurité restent protégées.

Cartographier la couche de compréhension publique.

Pas l'ensemble du système d'ingénierie interne.

33.106Os de la rivière

L'Os de la rivière pourrait devenir l'une des applications publiques les plus fortes de map.ca.

Information possible :

Cela transforme la géographie des sections 18 et 19 en quelque chose que les résidents peuvent explorer directement.

33.107Owen Sound à l'extérieur

Une activité telle que :

Je veux essayer la pagaie

pourrait montrer :

La carte organise l'écosystème.

Elle n'a pas besoin de gérer toutes les activités.

33.108Partenaires communautaires

Les organisations communautaires devraient pouvoir maintenir une information publique appropriée sur :

Elles restent responsables du service.

La carte permet de le découvrir.

33.109Information d'urgence

En cas d'urgence, map.ca pourrait afficher des informations publiques sûres telles que :

Les informations d'urgence doivent provenir de l'autorité compétente.

Les utilisateurs communautaires ne devraient pas pouvoir marquer :

Abri d'urgence officiel

parce qu'ils ont entendu un bruit de couloir.

33.110Une seule source officielle

map.ca ne devrait pas créer une autorité d'information d'urgence concurrente.

Il devrait afficher ou se connecter à l'enregistrement officiel.

Une seule source officielle

De nombreuses interfaces utiles

Ce principe survive à la plateforme.

33.111Aucune carte de vulnérabilité

Ne pas cartographier publiquement :

Cartographier :

Protéger les vulnérabilités.

33.112Connaissances locales

Les résidents peuvent contribuer :

Là où l'information devient officielle pour la municipalité :

Le personnel ou les professionnels compétents la valident.

La communauté contribue

L'autorité vérifie

Cela demeure le modèle.

33.113Connaissances autochtones

Les connaissances de la Saugeen Ojibway Nation ne devraient jamais être traitées comme des données municipales gratuites simplement parce que map.ca peut les stocker.

Toute utilisation impliquant :

doit se faire dans le cadre d'une relation appropriée, avec le consentement et un gouvernance convenue.

La carte n'est pas propriétaire de la connaissance qu'elle affiche.

33.114Dénomination officielle

Là où des lieux publics portent des noms officiels, la carte devrait utiliser le nom autoritatif.

Des noms alternatifs :

peuvent être affichés de façon appropriée lorsqu'ils sont appuyés et respectueux.

Ne permettez pas à la popularité de la carte de modifier accidentellement la géographie officielle.

33.115Neutralité des résultats de recherche

Les résultats de recherche publics devraient reposer sur des critères publiés.

Des facteurs potentiels :

Ne boostez pas secrètement :

La recherche devrait être suffisamment prévisible pour être auditable.

33.116Aucune réalité civique personnalisée

Les plateformes commerciales affichent souvent à différents utilisateurs des fils d'information différents.

Une carte civique publique devrait être bien plus prudente.

Deux résidents qui demandent :

Où se trouve la salle de bain publique la plus proche ?

ne devraient pas recevoir des réponses différentes en raison de profils comportementaux supposés.

La personnalisation peut être contrôlée par l'utilisateur.

Les faits publics devraient rester des faits publics.

33.117Filtres utilisateurs

Les résidents peuvent quand même choisir :

Cela est différent du fait que la plateforme décide secrètement de ce que la personne devrait voir.

Préférence de l'utilisateur

Bon.

Manipulation comportementale cachée

Éviter.

33.118Intelligence artificielle

L'IA pourrait aider map.ca dans les domaines suivants :

Il ne devrait pas devenir une autorité invisible qui décide de ce que la communauté est.

Utiliser l'IA comme un assistant.

Conserver :

33.119L'information générée par l'IA devrait être identifiable

Si l'IA génère :

il faut en faire clairement mention là où la précision est importante.

Un résumé généré par machine ne devrait pas remplacer silencieusement la source municipale officielle.

33.120Aucune donnée de résident privée ne devrait être utilisée par défaut pour l'entraînement de l'IA

Résident :

ne devraient pas devenir automatiquement des données d'entraînement pour des modèles commerciaux d'IA non liés.

Toute utilisation d'informations protégées nécessite une autorité et un gouvernance appropriés.

La contribution publique et le comportement privé sont différents.

33.121Données publiques pour l'innovation publique

Des ensembles de données publics et ouverts peuvent être réutilisés par :

Des exemples possibles incluent :

Publier des documents pour que les gens comprennent :

Les données ouvertes sans contexte peuvent produire des conclusions erronées.

33.122Interfaces ouvertes

Lorsque pertinent, map.ca devrait offrir des méthodes documentées pour que d'autres systèmes puissent :

des informations publiques approuvées.

Cela permet :

d'interagir entre eux.

La carte publique devient une infrastructure plutôt qu'un site web fermé.

33.123Aucune monopole d'API

Si une API publique existe, les règles d'accès devraient être :

Ne pas accorder à une seule entreprise un accès exclusif aux données publiques parce qu'elle a une relation avec le fondateur.

33.124Limites de fréquence et abus

L'accès ouvert ne signifie pas un abus illimité.

Les interfaces peuvent nécessiter :

Protéger le service tout en permettant le réutilisation légitime.

33.125Logiciel libre là où c'est pratique

Certaines parties de l'infrastructure publique peuvent être adaptées à une publication sous licence logicielle libre.

Les avantages peuvent inclure :

Toutes les dépendances ou configurations de sécurité ne devraient pas être publiques.

L'objectif est d'atteindre l'ouverture maximale pratique sans compromettre :

33.126Le manuel ouvert compte même si le code est fermé

Même si certains logiciels ne peuvent légalement ou pratiquement pas être libres, Owen Sound peut quand même publier :

Une autre municipalité devrait pouvoir apprendre de nous sans avoir à acheter chez nous.

33.127Hébergement canadien

Les principes de souveraineté numérique de la section 32 s'appliquent directement.

Pour les informations publiques importantes :

L'hébergement canadien peut être préférable s'il améliore matériellement le contrôle public et les risques.

Il devrait quand même être évalué sur :

33.128Le domaine map.ca devrait durer plus longtemps que les fournisseurs

Les fournisseurs d'hébergement peuvent changer.

Les développeurs peuvent changer.

Les fournisseurs d'IA peuvent changer.

Le public :

devrait rester.

L'architecture devrait permettre le remplacement sous un service public stable.

33.129Sauvegardes

Les informations publiques importantes nécessitent une sauvegarde indépendante.

Tester :

Une sauvegarde contrôlée par le même compte qui contrôle tous les systèmes actifs peut ne pas offrir assez de résilience.

Les professionnels techniques déterminent l'architecture appropriée.

33.130DNS et contrôle administratif

Pour un map.ca d'intérêt public, le contrôle administratif sur :

devrait utiliser une sécurité institutionnelle.

Pas :

Le fondateur a le mot de passe.

Cela constitue un point de défaillance unique.

33.131Sécurité informatique

Avant l'intégration municipale, exiger une revue professionnelle en matière de sécurité informatique portant sur des domaines appropriés tels que :

Ne pas publier les détails qui faciliteraient un cyberattaque.

Publier le fait qu'une gouvernance a eu lieu.

33.132Incidents de sécurité

Si RealMap.ca subit un incident important impliquant des informations publiques :

L'exploitant responsable devrait suivre :

Ne pas cacher un incident, car la réputation de la plateforme est importante.

La confiance publique exige une réponse honnête en cas d'échec.

33.133Continuité des activités

Posez-vous la question suivante :

Si RealMap.ca est hors ligne pendant trois jours, qu'est-ce qui cesse de fonctionner?

Un arrêt de calendrier communautaire est gênant.

Un service municipal d'urgence essentiel serait plus grave.

Ne pas placer des services essentiels sur la plateforme avant qu'une continuité appropriée n'existe.

33.134RealMap.ca ne devrait pas devenir la seule porte d'accès

Même si la plateforme est très réussie :

Les citoyens devraient quand même pouvoir accéder aux services municipaux essentiels par le biais de :

La redondance protège à la fois l'accès et la souveraineté.

33.135Financement du noyau public

L'infrastructure publique coûte toujours de l'argent.

Les coûts potentiels comprennent :

Avant la mise en œuvre :

Publier le modèle d'exploitation complet.

33.136Gratuit ne signifie pas non financé

La proposition initiale inclut plusieurs fonctions publiques gratuites.

Si les citoyens ne paient rien au moment de l'utilisation :

Quelqu'un paie quand même.

Des sources légales de financement pourraient inclure :

Chaque source crée des compromis.

Les publier.

33.137Ce qui doit rester gratuit

Dans le cadre de ce plan, je protégerais l'accès gratuit à la couche de base axée sur l'intérêt public.

Cela inclut :

Le standard de liste de base gratuit de RealMap demeure soumis à l'examen juridique et de gouvernance établi à l'article 25.

33.138Aucune barrière payante sur les faits municipaux

Un résident ne devrait pas avoir à s'abonner pour connaître :

Si la ville finance ou adopte la couche publique :

Les informations municipales de base demeurent publiques.

33.139Le logiciel commercial peut être distinct

Un opérateur indépendant pourrait éventuellement développer des outils optionnels au-delà de l'infrastructure publique.

Des exemples possibles pourraient inclure :

Ces outils devraient être séparés financièrement et visuellement du noyau municipal.

La propriété publique ne devrait pas devenir un prétexte pour que le gouvernement intervienne dans chaque marché du logiciel.

33.140Aucune subvention croisée cachée

Si un service commercial perd de l'argent et que l'infrastructure publique paie la facture :

Montrez-le.

Si les revenus commerciaux soutiennent la couche publique :

Montrez cela aussi.

Un comptabilité séparée protège les deux côtés.

33.141Mécénat

Un mécène pourrait potentiellement aider à financer :

Le mécénat ne devrait jamais acheter :

La reconnaissance peut être appropriée.

L'influence est différente.

33.142Donations

La philanthropie privée pourrait aider à construire l'infrastructure publique.

Toute donation substantielle devrait dévoiler :

Une donation ne devrait pas acheter un pouvoir permanent sur la plateforme.

33.143Subventions

Des subventions gouvernementales pourraient aider à financer :

Ne construisez pas un système permanent dont le modèle d'exploitation ne fonctionne que si la même subvention temporaire revient chaque année.

Question sur les subventions

Qui paie après la subvention ?

33.144Aucune garantie de dette municipale pour une plateforme expérimentale

La ville ne devrait pas garantir une dette importante d'une plateforme privée ou à but non lucratif simplement parce qu'elle soutient l'idée.

Toute future arrangement financier devra passer par la normale :

tests.

L'enthousiasme numérique n'est pas un substitut à la solvabilité.

33.145Coût par résident

Si un financement municipal est éventuellement proposé, montrez le coût pratique.

Par exemple:

Contribution annuelle municipale

divisée par

les résidents desservis

peut offrir une perspective.

Cela ne devrait pas être la seule mesure.

Mais les résidents méritent de comprendre l'échelle.

33.146Coût par service

Comprenez aussi les coûts des fonctionnalités majeures.

Combien coûte-t-il d'exploiter:

Une fonctionnalité ne devrait pas se cacher derrière le budget global de la plateforme.

33.147Aucun développement pour vanité

Ne construisez pas de fonctionnalités parce que:

Il serait cool si map.ca faisait cela.

Chaque fonctionnalité financée publiquement devrait répondre à la question suivante:

Quel problème résidentiel cela résout-il?

Si aucune réponse:

Ne le construisez pas avec de l'argent public.

33.148Plan d'action public

Si le système devient une infrastructure publique, publiez un plan d'action à haut niveau.

Statut possible:

Proposé

En cours d'examen

Financé

En développement

Essai

Opérationnel

Arrêté

Cela réduit la tendance à décrire chaque idée comme si elle existait déjà.

33.149Prototype n'est pas infrastructure

Cette distinction devrait apparaître tout au long du plan.

Prototype

Une idée qui fonctionne sous des conditions limitées.

Essai

Un test structuré avec des utilisateurs réels.

Service

Un programme opérationnel avec soutien.

Infrastructure

Un service doté de:

Ne sautez pas les étapes.

33.150Ne surestimez pas les capacités actuelles

Les matériels de campagne devraient être précis sur ce que map.ca:

Un calendrier futur ne devrait jamais être décrit comme une infrastructure opérationnelle simplement parce qu'une page de concept existe.

La crédibilité est plus précieuse qu'une apparence d'avance.

33.151Bêta publique

Certains services d'intérêt public de map.ca pourraient raisonnablement être lancés comme suit :

bêta

ou

démonstration pilote.

Informez les utilisateurs :

Expérimentez ouvertement.

33.152Owen Sound en tant que communauté pilote

Owen Sound pourrait devenir la première communauté à tester certains standards publics.

Cela ne signifie pas que les résidents deviennent des sujets technologiques non rémunérés.

La conception de la démonstration pilote devrait inclure :

La ville teste un service.

Pas d'expérimentation sur les personnes sans limites.

33.153Autres municipalités

Si le modèle fonctionne, publiez librement le manuel d'exploitation.

Le plan initial s'engage déjà à publier les systèmes municipaux réussis afin que d'autres communautés canadiennes puissent les adopter.

Ce principe devrait s'appliquer fortement ici.

33.154Ne pas faire d'Owen Sound un service de vente de logiciels

La ville elle-même ne devrait pas devenir responsable de :

sauf si un cas commercial futur établit une structure municipale appropriée et un objectif public légal.

Il est plus probable que :

Une organisation indépendante d'intérêt public gère l'expansion.

Owen Sound partage ce qu'il a appris.

33.155L'adoption municipale devrait être volontaire

Une autre municipalité devrait pouvoir utiliser :

sans être contrainte à entrer dans l'ensemble de l'écosystème map.ca si possible.

La modularité augmente l'adoption.

33.156Les données locales restent sous autorité locale là où approprié

Une plateforme nationale peut fournir une infrastructure commune.

Chaque municipalité participant devrait conserver l'autorité appropriée sur :

L'architecture nationale ne devrait pas effacer la responsabilité locale.

33.157Standard commun, autorité locale

L'idéal pourrait ressembler à :

Commun

Local

Cela permet d'atteindre une échelle nationale sans nationaliser chaque décision municipale.

33.158Cadenas de données des résidents

Le plan initial propose également un cadenas de données des résidents pouvant être transféré d'une municipalité à l'autre.

Il s'agit d'un concept futuriste ambitieux.

Il devrait rester un sujet d'étude pendant le premier mandat, sauf si des examens sur la vie privée, la cybersécurité et la gouvernance démontrent un design sécuritaire.

Un dépôt de données personnelles crée un risque nettement plus grand qu'une carte publique.

33.159Apprenons avant de stocker

La section 31 a établi la meilleure première étape :

Apprenez aux citoyens à organiser, à sauvegarder et à contrôler leurs propres informations avant de leur demander d'en stocker davantage auprès d'une institution publique.

Cela demeure la priorité.

33.160Un cadenas de données ne devrait pas devenir un dossier

S'il est développé ultérieurement, un cadenas contrôlé par le résident ne devrait pas combiner automatiquement :

Les mots :

tout en un seul endroit

peuvent sembler pratiques.

Ils peuvent aussi décrire un gigantesque piratage.

33.161Connexions contrôlées par le résident

Si les services peuvent se connecter à un cadenas, le résident devrait comprendre et contrôler la connexion là où la loi le permet.

Par exemple :

Permettez à ce document d'être partagé avec ce service à cet effet.

Et non :

En créant un compte, vous consentez à tout pour toujours.

33.162Portabilité

Un concept véritablement contrôlé par le résident devrait permettre à la personne de transférer ses informations vers un autre système compatible.

La plateforme ne devrait pas dire :

Vos informations sont portables

quand l'exportation est illisible ailleurs.

La portabilité doit être pratique.

33.163Suppression et déconnexion

Les utilisateurs devraient pouvoir se déconnecter des services optionnels.

Si un utilisateur cesse d'utiliser :

la plateforme ne devrait pas conserver des liens comportementaux inutiles simplement parce que le compte municipal continue.

33.164Minimisation des données par axe fonctionnel

Chaque axe fonctionnel ne devrait demander que ce dont il a besoin.

YouthMap Browse

Presque rien.

Organisateur d'événements

Informations sur l'événement et l'organisateur.

Vendeur RealMap

Informations sur la propriété et les contacts autorisés.

Signalement de service municipal

Informations nécessaires pour acheminer et suivre la demande de service.

N'utilisez pas un seul formulaire universel exigeant tout de tout le monde.

33.165La carte publique devrait fonctionner sans profil de résident

Cela devrait être un objectif technique.

Un visiteur de :

Devrait pouvoir utiliser la carte publique.

Les renseignements municipaux sont utiles aussi aux personnes qui ne sont pas résidentes inscrites.

33.166Touristes

Les visiteurs ont besoin de :

La carte peut soutenir le tourisme sans créer des profils à long terme des visiteurs.

Des renseignements de qualité sont suffisants.

33.167Entreprises

Les entreprises devraient pouvoir maintenir des renseignements publics précis.

Champs possibles :

La plateforme ne devrait pas exiger la création continue de contenu simplement pour rester visible.

Une entreprise existe, qu'elle publie ou non quotidiennement.

33.168Aucun concours de popularité

Ne pas classer les entreprises selon :

Un plombier ne devrait pas devoir devenir créateur de contenu pour apparaître lorsqu'on recherche :

un plombier à proximité.

L'emplacement et la pertinence devraient compter davantage que l'attention portée.

33.169Avis

Une plateforme civique publique n'a pas besoin de devenir un autre :

système.

Des plateformes privées d'avis existent déjà.

Le rôle de la carte publique est :

Qui est ici ? Quelles sont ses activités ? Comment puis-je le contacter ?

Cela suffit.

33.170Corrections, pas punition publique

Si les renseignements d'une entreprise sur :

sont erronés :

Corrigez-les.

Ne pas créer un score public indéfini documentant chaque erreur commise par l'entreprise.

L'infrastructure devrait faciliter la découverte.

Et non pas fonctionner comme une cour de réputation.

33.171Crédits pour contribution communautaire

Si les futurs contributeurs à la carte reçoivent :

pour un travail utile au public, le système devrait s'assurer que les récompenses ne deviennent pas un statut civique.

La reconnaissance des contributions peut motiver la participation.

Elle ne devrait pas affecter :

33.172Cartographie communautaire rémunérée

Certains travaux de cartographie peuvent devenir des travaux rémunérés légitimes par l'entremise de :

Si la ville a besoin de données vérifiées de manière récurrente :

Rémunérez-les de façon appropriée.

Ne construisez pas d'infrastructures fondamentales sur un travail non rémunéré infini.

33.173Cartographie bénévole

Les contributions bénévoles peuvent tout de même être précieuses.

Exemples :

L'état de bénévole devrait être clair.

La plateforme ne devrait pas promettre un revenu simplement parce que quelqu'un contribue.

33.174Sécurité des contributeurs

Les instructions de cartographie communautaire ne devraient jamais envoyer des personnes sur :

La règle est :

Observez depuis des endroits légaux et sûrs.

L'inspection professionnelle demeure un travail professionnel.

33.175Photographie

La photographie sur les cartes publiques devrait éviter l'inclusion inutile de :

Une carte de localisation n'a pas besoin de devenir un dépôt d'archives de surveillance.

33.176Précision géographique

Certaines ressources publiques profitent de coordonnées précises.

D'autres informations peuvent nécessiter moins de précision.

Ne publiez pas les emplacements exacts de ressources sensibles si cela crée :

un risque général.

La précision n'est utile que lorsqu'elle est appropriée.

33.177Informations historiques

map.ca pourrait également conserver :

Distinguez clairement :

actuel

de

historique.

Un touriste ne devrait pas se rendre à un restaurant fermé en 1974 parce que la couche historique semblait actuelle.

33.178Le temps comme dimension de la carte

Une carte civique solide devrait pouvoir répondre à terme à :

Qu'y a-t-il ici maintenant ?

et séparément à :

Qu'y avait-il ici avant ?

Cela crée de la valeur pour :

Ne mélangez pas les deux par erreur.

33.179Historique des actifs publics

Pour les actifs publics importants, les citoyens pourraient éventuellement voir un historique sécurisé tel que :

Cela s'applique à l'Index des infrastructures.

L'entretien devient visible.

33.180Aucun historique des travaux personnels des employés

L'historique des actifs ne devrait pas devenir :

L'employé X a commis cette erreur en 2028.

Le public a besoin de :

La gestion des employés demeure une responsabilité distincte.

33.181Marché public par map.ca

map.ca ne devrait pas devenir un système alternatif de sous-traitance par l'arrière.

Un fournisseur apparaissant sur la carte n'a pas droit à :

Les marchés publics municipaux continuent sous la section 11.

33.182Découverte de fournisseurs

La carte pourrait aider le personnel des marchés publics à découvrir qu'il existe des fournisseurs locaux.

C'est une bonne chose.

Les achats réels suivent toujours :

exigences.

La découverte n'est pas une attribution.

33.183Informations sur le développement

Les informations publiques sur la planification et le développement pourraient éventuellement être cartographiées.

Des couches possibles :

Utilisez des informations officielles.

Ne pas utiliser les rumeurs communautaires comme statut d'utilisation du sol.

33.184Zonage

Une carte publique pourrait montrer des informations sur le zonage.

Elle devrait orienter les citoyens vers :

où une interprétation juridique est nécessaire.

Une carte pratique ne devrait pas être présentée comme un avis juridique garanti.

33.185Limites des propriétés

De même, les lignes visibles sur la carte ne devraient pas automatiquement être représentées comme :

Étiquetez les données selon leur source réelle et leur précision.

33.186Interprétation AI des propriétés

Ne permettez pas qu'un assistant IA dise :

Vous pouvez certainement construire ceci ici

basé uniquement sur les données de la carte.

Une meilleure réponse est :

Ces informations suggèrent que ces règles pourraient s'appliquer. Confirmez par le processus municipal approprié.

La technologie facilite la navigation.

L'autorité gouvernementale demeure là où la loi la place.

33.187Consultation publique

map.ca pourrait aider les résidents à voir :

Cela pourrait améliorer la participation.

Il ne devrait pas inférer silencieusement l'opinion des résidents à partir de :

La participation exige une entrée intentionnelle.

33.188Données électorales et de consultation

Si VoteMap est jamais relié techniquement à map.ca :

Garder l'opinion politique dans un environnement séparé et protégé.

L'activité d'une personne sur la carte publique ne devrait jamais révéler comment elle a voté dans :

33.189Le vote secret demeure secret

Rien concernant une plateforme civique unifiée ne devrait affaiblir :

La commodité d'un seul compte ne devrait jamais primer sur les fondamentaux démocratiques.

33.190Commentaires publics

Si map.ca supporte finalement des commentaires publics :

Concevoir avec soin.

Une carte civique n'a pas nécessairement besoin d'un flux de commentaires ouvert et infini.

Parfois, une entrée structurée est meilleure :

Ne pas simplement recréer un réseau social parce que les commentaires favorisent l'engagement.

33.191L'engagement n'est pas l'objectif

Les plateformes commerciales optimisent :

L'infrastructure publique devrait optimiser :

Si un résident trouve la réponse en trente secondes et quitte :

Cela est un succès.

33.192Aucun design addictif

Ne pas utiliser :

simplement pour augmenter l'utilisation de la plateforme.

L'infrastructure civique devrait respecter l'attention.

33.193Choix des notifications

Les résidents devraient choisir ce qu'ils reçoivent.

Exemples :

Ne pas inscrire automatiquement quelqu'un dans toutes les catégories.

33.194Les alertes d'urgence sont différentes

Les vraies alertes d'urgence peuvent suivre des systèmes juridiques et opérationnels distincts.

map.ca peut afficher des informations officielles sur les urgences.

Il ne devrait pas prétendre les remplacer par :

33.195Souveraineté des données

L'article 32 a établi le principe numérique fondamental :

Conserver la capacité de partir.

map.ca devrait démontrer ce principe de manière plus forte que le fournisseur commercial moyen.

Si elle prétend modéliser la souveraineté numérique :

Elle devrait être portable elle-même.

33.196Test de sortie map.ca

Avant l'intégration par la ville, démontrer :

Exportation des données

Est-il possible d'exporter les données de la ville ?

Exportation des médias

Est-il possible de récupérer les photographies et les fichiers ?

Métadonnées

Les relations sont-elles préservées ?

Comptes

Est-il possible de transiter les utilisateurs ?

API

Les intégrations sont-elles documentées ?

Domaine

Quel reste s'il y a un changement de plateforme ?

Remplacement

Est-il possible qu'un autre fournisseur reconstitue le service public ?

Testez-le.

Ne vous contentez pas de le promettre.

33.197Fork public

Pour les composants ouverts pertinents, considérer si une autre municipalité pourrait exploiter le logiciel de manière indépendante si l'organisation centrale échouait.

Cela peut ne pas être réalisable pour chaque composant.

Là où c'est possible :

Cela fournit un mécanisme de continuité puissant.

33.198Une plateforme ne peut retenir la population en otage

Si un conseil municipal futur dit :

Payez ce que nous exigeons ou votre carte civique disparaît,

le modèle de gouvernance a échoué.

Les partenaires publics ont besoin de droits contractuels et techniques de sortie.

33.199Accords de niveau de service

Pour les intégrations municipales, définir des niveaux raisonnables de :

Une organisation à but non lucratif d'intérêt public a besoin d'accords professionnels d'exploitation.

Les bonnes intentions ne sont pas des niveaux de service.

33.200Accords de niveau d'accessibilité

De même, l'accessibilité devrait être maintenue par le biais de :

Un site public peut devenir inaccessible au fil du temps à mesure que des fonctionnalités sont ajoutées.

L'accessibilité est une maintenance.

33.201Conception par défaut de confidentialité

Chaque nouvelle fonctionnalité devrait passer par :

Pouvons-nous offrir cela avec moins d'informations personnelles ?

Cela devrait devenir partie intégrante de la revue de développement.

La confidentialité ajoutée après le lancement coûte généralement davantage et fonctionne moins bien.

33.202Sécurité par conception

De la même façon :

doivent être intégrés dès la conception.

Ne construisez pas rapidement et ne promettez pas :

Nous y ajouterons la sécurité plus tard.

L'infrastructure publique mérite mieux.

33.203Accessibilité par conception

Le même principe s'applique à l'accessibilité.

Ne lancez pas :

la version 1 pour tout le monde

et promettez aux résidents handicapés la version 2.

Concevez correctement l'accès fondamental dès le début.

33.204Soutien humain

Un système numérique public doit permettre aux personnes de signaler :

Ceci est incorrect.

ou :

Je ne peux pas utiliser ceci.

Fournissez un soutien humain adapté à l'échelle du service.

L'automatisation devrait réduire le soutien répétitif.

Pas éliminer la responsabilisation.

33.205Coûts de soutien

Le soutien humain coûte de l'argent.

Incluez :

Le développement logiciel n'est qu'une partie des coûts d'une plateforme.

33.206Équipe de lutte contre la fraude

À mesure que l'utilisation augmente, une forme de gestion de la fraude et des abus peut devenir nécessaire.

Les problèmes possibles comprennent :

Commencez proportionnellement.

Ne construisez pas un service national de lutte contre la fraude pour un projet pilote local.

Adaptez les mesures de contrôle à l'échelle du risque réel.

33.207Demandes de forces de l'ordre

Une plateforme publique devrait établir un processus légal pour répondre aux demandes provenant de la police ou d'autres autorités.

Ne remettez pas facilement les informations des résidents sous prétexte que quelqu'un affirme :

C'est pour la sécurité.

Suivez :

33.208Rapports de transparence

À mesure que le système croît, un opérateur indépendant à l'intérêt public pourrait publier des informations agrégées concernant des catégories appropriées de demandes gouvernementales ou légales, dans la mesure autorisée par la loi.

L'objectif est la responsabilisation.

Pas l'obstruction d'enquêtes légales.

33.209Messages privés

Si map.ca introduit un jour les messages privés :

Cela crée une autre catégorie d'informations sensibles.

N'ajoutez pas cela de manière aléatoire.

Demander:

Est-ce que le bien public exige réellement que nous offrions un service de communication?

Un lien vers:

peut suffire.

33.210Restreindre les fonctionnalités

Le meilleur map.ca peut être plus petit que le map.ca le plus grand imaginable.

Une plateforme devient fragile lorsqu’on ajoute chaque bonne idée au même système.

Le noyau pourrait rester:

D’autres services peuvent s’intégrer sans être absorbés.

33.211Architecture modulaire

RealMap.

YouthMap.

Calendrier communautaire.

Premiers à agir.

Acheter local.

Ces modules peuvent partager des normes tout en restant modulaires.

Si un module:

le système d’information civique entier ne devrait pas s’effondrer.

33.212La séparation protège l’innovation

Une structure modulaire permet aussi à une équipe d’améliorer:

sans risquer:

Des limites claires favorisent un rythme d’innovation plus rapide.

33.213La séparation protège la vie privée

La même architecture réduit la pression pour créer un seul gigantesque ensemble de données.

Chaque module peut fonctionner avec la quantité minimale d’information nécessaire.

C’est une meilleure conception civique.

33.214Le Conseil de la carte ne voit pas la base de données

Les résidents peuvent voir une interface visuellement unifiée.

Internement, les informations peuvent rester séparées par:

Une seule carte n’a pas besoin d’une seule base de données.

33.215La recherche publique n’exige pas l’historique des utilisateurs

Un système de recherche locale de haute qualité peut fonctionner en utilisant:

Il n’a pas besoin d’années d’historique comportemental.

Cela devrait être la norme.

33.216La propriété communautaire ne signifie pas que tout le monde peut modifier tout

La propriété publique ne doit pas être confondue avec:

n’importe quel utilisateur peut modifier les informations officielles.

Les autorisations demeurent.

Exemples:

Personnel municipal

Gère les données municipales officielles.

Entreprise

Gère ses propres renseignements d'entreprise.

Organisateur d'événements

Gère son événement.

Résident

Peut suggérer des corrections.

Une propriété publique implique une gouvernance responsable.

Pas un accès libre éditable à l'envi.

33.217Provenance

Les renseignements importants devraient conserver leur source.

Par exemple :

Source : Ville d'Owen Sound

Source : Propriétaire d'entreprise

Source : Soumission communautaire

Cela permet aux résidents d'évaluer la fiabilité.

33.218Incertitude

Parfois, les renseignements sont incomplets.

Indiquez :

Non vérifié.

ou :

Dernière vérification en juin 2027.

Ne remplissez pas les blancs avec une certitude générée par l'IA.

33.219Aucune complétude fictive

Une carte peut montrer dix entreprises dans une catégorie.

Cela ne signifie pas nécessairement :

Ce sont toutes les entreprises d'Owen Sound.

Si la participation est incomplète :

Indiquez-le.

Les utilisateurs publics devraient comprendre la couverture.

33.220Participation ouverte

Les organisations et entreprises admissibles devraient avoir un moyen raisonnable de :

leur présence.

Le système ne devrait pas exiger un accès réservé.

33.221Aucun paiement pour être trouvé

La découverte locale de base devrait rester indépendante des dépenses publicitaires.

C'est l'une des différences les plus fortes en matière d'intérêt public que map.ca pourrait offrir.

Si la visibilité devient payante :

Le cas d'intérêt public devient plus faible.

33.222Aucune course à la visibilité en interne sur la carte publique

Les entreprises ne devraient pas avoir à publier :

juste pour apparaître.

Utilisez des catégories factuelles structurées.

Le mécanicien local devrait apparaître parce qu'il est :

un mécanicien local.

Et non parce qu'il a engagé la meilleure entreprise d'optimisation.

33.223Balises d'entreprise simples

Balises possibles :

Les normes de balises devraient être compréhensibles.

Ne créez pas 15 000 classifications obscures que seuls les employés de la plateforme comprennent.

33.224Catégories contestées

Une entreprise peut être en désaccord avec sa classification.

Fournir une correction.

Ne permettez pas aux concurrents de saboter les catégories les uns des autres.

Le propriétaire de la liste et les règles de la plateforme déterminent la description publique.

33.225Découverte de produits canadiens

Les fonctionnalités de Shop Local pourraient aider les résidents à découvrir :

Toute affirmation sur l'origine devrait être basée sur des informations fournies par un :

Ne déduisez pas l'origine nationale à partir de la marque.

33.226Achat public indépendant

Même si map.ca montre des fournisseurs canadiens :

La ville continue d'acheter conformément à la :

La visibilité sur la carte n'implique pas une préférence d'achat.

33.227Informations environnementales

Les informations environnementales publiques peuvent être utiles.

Exemples :

Ne permettez pas aux utilisateurs de la plateforme non qualifiés de publier :

comme des faits officiels.

Utilisez l'autorité appropriée.

33.228Informations sur la santé

De même, des services du style HealthMap pourraient un jour exister.

Une carte publique peut montrer :

Elle ne devrait pas diagnostiquer :

Les informations médicales méritent un seuil de gouvernance plus élevé.

N'étendez pas cela de manière légère.

33.229Informations sur la sécurité

Évitez les étiquettes générales telles que :

Endroit sûr

sauf si le terme a une définition précise d'un programme.

Les conditions changent.

Une carte peut décrire :

Permettez aux utilisateurs de faire des choix éclairés.

33.230« Sécuritaire » n'est pas une garantie

Ce principe s'applique à l'ensemble de map.ca.

Une base de données peut aider quelqu'un à prendre des décisions.

Elle ne peut pas promettre :

Préférez une description objective à des assurances trop larges.

33.231Responsabilité des informations publiques

L'exploitant devrait maintenir des dénigrements clairs adaptés aux informations pouvant :

Un avertissement ne doit pas devenir un prétexte pour des données négligées.

La précision demeure l'objectif.

33,232 Assurance

Un opérateur indépendant peut nécessiter une assurance appropriée concernant :

La couverture exacte relève de l'avis professionnel et de la structure finale.

Incluez l'assurance dans le coût total.

Le document de travail actuel indique correctement que l'étape finale suivante :

nécessite un avis juridique qualifié sur les municipalités, la vie privée, l'approvisionnement et les questions connexes, basé sur la loi et les faits au moment où la décision est prise.

Cet avertissement doit demeurer permanent dans cette initiative.

Ce plan est un cadre de gouvernance.

Pas un substitut au travail juridique transactionnel.

33,234 Examen technique indépendant

L'approbation juridique n'est pas suffisante.

Une plateforme peut être licite et mal conçue sur le plan technique.

Avant l'adoption municipale :

Examinez :

L'examinateur ne devrait pas être choisi par le fondateur seul.

33,235 Examen indépendant sur la vie privée

La même chose s'applique à la vie privée.

Demandez :

Publiez un résumé compréhensible pour le public.

33,236 Examen indépendant sur l'accessibilité

Testez à la fois :

Impliquez des personnes vivant avec un handicap dans l'évaluation avant l'approvisionnement final.

33,237 Examen financier indépendant

Avant le transfert public :

Publiez :

Numéro :

C'est essentiellement gratuit puisque le code existe déjà.

Le code existant n'est que le début des coûts d'exploitation.

33.238Examen de la concurrence indépendant

Demander :

L'adoption municipale déformerait-elle injustement un marché ou accorderait-elle un avantage inapproprié à une entreprise privée?

Le travail de RealMap a déjà identifié cela comme faisant partie du mur juridique et de gouvernance.

Si la réponse révèle un problème :

Rédiger à nouveau.

33.239Porte de décision 1 : Intérêt public

Avant l'adoption, le conseil municipal doit répondre à la question suivante :

Quel intérêt public municipal spécifique est-il satisfait?

Non :

La technologie est impressionnante.

33.240Porte de décision 2 : Propriété

Identifier exactement :

Aucune ambiguïté.

33.241Porte de décision 3 : Intérêt du fondateur

Publier les éléments pertinents suivants :

Faites-le avant le vote.

33.242Porte de décision 4 : Évaluation indépendante

Aucun transfert sans une compréhension appropriée à distance des valeurs.

Confirmer que la ville a l'autorité pour :

Ne pas inférer l'autorité à partir de l'enthousiasme.

33.244Porte de décision 6 : Conformité aux conflits

Confirmer :

La personne ayant un intérêt ne dirige pas la décision.

33.245Porte de décision 7 : Achat

Déterminer si :

s'applique.

Publier la justification.

33.246Porte de décision 8 : Confidentialité

Effectuer un examen complet de la confidentialité.

Aucune question non résolue :

avant le lancement.

33.247Porte de décision 9 : Sécurité cybernétique

Effectuer un examen technique complet de la sécurité et identifier :

Le résumé public peut protéger les détails sensibles.

33.248Porte de décision 10 : Accessibilité

Démontrer que le service fonctionne pour les personnes vivant avec un handicap.

Pas seulement que le fournisseur le dit.

33.249Porte de décision 11 : Portabilité

Exporter les informations.

Démontrer qu'elles peuvent être utilisées ailleurs.

33.250Porte de décision 12 : Durabilité financière

Démontrer :

Aucune facture future cachée.

33.251Porte de décision 13 : Alternative non numérique

Demander :

Un résident peut-il encore recevoir un service municipal essentiel sans map.ca ?

Si non :

Le système est devenu une infrastructure obligatoire et nécessite un niveau de continuité nettement plus élevé.

33.252Porte de décision 14 : Aucun profit privé

Le conseil municipal devrait recevoir un rapport explicite répondant à la question suivante :

Cette transaction crée-t-elle un avantage privé direct ou indirect lié à un élu, au-delà de ce qui a été indépendamment examiné et justifié ?

Ne laissez pas la question la plus importante sans réponse.

33.253Porte de décision 15 : Sortie publique

Avant l'entrée :

Démontrer comment la ville peut sortir.

Une relation sans plan de sortie est une dépendance.

33.254Premiers 30 jours

Le premier mois ne devrait pas impliquer l'adoption par la ville.

Il devrait impliquer la divulgation et l'indépendance.

Le document de travail actuel propose déjà une divulgation précoce des propriétés et des conflits, des conseils juridiques et professionnels indépendants, ainsi qu'un processus d'évaluation neutre.

Actions

  1. Publier les relations actuelles entre map.ca et RealMap pertinentes pour l'évaluation publique.
  2. Déclarer les intérêts personnels ou corporatifs pertinents.
  3. Demander un conseil juridique et d'intégrité municipal indépendant.
  4. Demander au personnel de définir le problème d'information publique sans supposer que map.ca est la solution.
  5. Établir le standard d'infrastructure numérique publique.
  6. Empêcher le maire de diriger l'évaluation de la plateforme là où les règles de conflit l'exigent ou que la confiance publique exige une séparation.

33.255Jours 31 à 60

Pendant le deuxième mois :

  1. inventaire des actifs;
  2. évaluation préliminaire;
  3. examen de l'architecture technique;
  4. commencer l'examen de la vie privée;
  5. commencer les tests d'accessibilité;
  6. évaluer les questions d'assistance municipale et de concurrence;
  7. documenter les coûts sur cinq ans;
  8. tester l'exportation des données;
  9. comparer les options de gouvernance;
  10. identifier au moins une alternative crédible à map.ca.

Une évaluation réelle exige des alternatives.

33.256Jours 61 à 100

Le cadre RealMap actuel exige déjà la publication des conclusions juridiques, des coûts, des résultats des consultations et d'une décision du conseil municipal sur l'opportunité d'adopter un modèle de gouvernance.

Pour map.ca spécifiquement :

Publier :

Ce que map.ca fait actuellement

Ce qui reste en version prototype

Actifs

Propriété

Évaluation

Décisions concernant les conflits

Décisions concernant la confidentialité

Décisions concernant la cybersécurité

Décisions concernant l'accessibilité

Options de gouvernance

Modèle financier sur cinq ans

Décisions concernant la portabilité

Recommandation

Le conseil municipal décide ensuite si une évaluation supplémentaire mérite des ressources publiques.

Et non si le maire remporte la victoire.

33,257 Première année

Pendant la première année :

Aucune fonction municipale essentielle ne devrait dépendre exclusivement de map.ca en première année.

33,258 Deuxième année

Si la première année réussit :

Passer d'un pas à la fois.

33,259 Troisième année

Si la gouvernance demeure solide :

Ne pas introduire des fonctionnalités à haut risque simplement parce que l'adoption a augmenté.

33,260 Quatrième année

D'ici la quatrième année, publier un rapport complet sur l'infrastructure publique de map.ca.

Poser les questions suivantes :

L'objectif public est-il clair ?

L'accès civique de base est-il gratuit ?

Est-il possible de naviguer sans compte ?

Le calendrier est-il exempt de classement payant ?

La recherche civique de base est-elle exempte d'influence publicitaire ?

Les résidents sont-ils inutilement traqués ?

Les entreprises et les organismes peuvent-ils corriger leurs informations ?

Les personnes vivant avec un handicap peuvent-elles utiliser le service ?

Existe-t-il un itinéraire non numérique significatif ?

Est-ce que RealMap demeure optionnel ?

Est-ce que YouthMap cartographie les possibilités plutôt que les enfants ?

Est-ce que les données politiques et les données du service civique sont séparées?

Le maire conserve-t-il un quelconque avantage financier ou contrôle-t-il encore quelque chose?

L'organisation est-elle indépendante de son fondateur?

La ville peut-elle exporter ses données?

Cette exportation a-t-elle été testée?

Une autre plateforme peut-elle utiliser le standard public?

Owen Sound peut-elle quitter map.ca sans perdre le service public?

Le modèle d'exploitation peut-il survivre sans subvention temporaire?

Une autre municipalité canadienne a-t-elle pu réutiliser ce modèle sans renoncer à son propre pouvoir?

Si ces questions ne peuvent pas être répondues de façon satisfaisante:

N'appelez pas cela une infrastructure publique.

33.261L'Épreuve du fondateur

À la fin du mandat, appliquez un test inhabituel mais important:

Que se passe-t-il si Mike Seiler disparaît demain?

La plateforme:

Si la réponse est:

Nous avons besoin de Mike,

alors je n'ai pas réussi à en faire une infrastructure publique.

33.262L'Épreuve électorale

Demandez alors:

Que se passe-t-il si le maire suivant déteste map.ca?

Si l'institution publique peut:

par le biais d'une gouvernance légitime:

C'est bon.

Si je conserve le pouvoir d'arrêter cela:

Cela n'était jamais vraiment public.

33.263L'Épreuve du fournisseur

Demandez:

Que se passe-t-il si le fournisseur d'hébergement double son prix?

Pouvons-nous nous déplacer?

33.264L'Épreuve cybernétique

Demandez:

Que se passe-t-il si le système principal est compromis?

Pouvons-nous:

33.265L'Épreuve de la vie privée

Demandez:

Est-il possible d'utiliser ce système pour reconstituer la vie d'un résident?

Si oui:

Nous avons collecté ou connecté trop d'informations.

33.266L'Épreuve d'accessibilité

Demandez à quelqu'un qui n'utilise pas la carte de manière visuelle:

Pouvez-vous quand même trouver ce que vous cherchez?

Si non:

La carte n'est pas assez publique.

33.267L'Épreuve du résident pauvre

Demandez:

Est-ce que quelqu'un peut participer sans carte de crédit et avec un appareil plus ancien ?

Si non :

Examinez la revendication d'accès public.

33.268L'Épreuve sans smartphone

Demandez :

Est-ce que quelqu'un peut accéder aux informations municipales essentielles sans posséder un smartphone ?

La réponse doit rester :

Oui.

33.269L'Épreuve des affaires

Demandez à une petite entreprise locale :

Est-ce qu'un client peut vous trouver sans payer la plateforme pour sa visibilité ?

La réponse devrait être :

Oui.

33.270L'Épreuve de l'opposant politique

Demandez :

Est-ce que quelqu'un qui s'oppose fortement au maire peut obtenir exactement la même accès à la plateforme ?

La réponse doit être :

Oui.

33.271L'Épreuve de la foi

Demandez :

Est-ce qu'une église, une mosquée, un groupe laïc et une association politique peuvent toutes utiliser les fonctions éligibles du calendrier public sous les mêmes règles ?

La réponse devrait être :

Oui.

33.272L'Épreuve de l'enfant

Demandez :

Est-ce qu'un adolescent peut trouver une opportunité sans que la plateforme construise un profil comportemental permanent de lui ?

La réponse devrait être :

Oui.

33.273L'Épreuve de la municipalité

Demandez :

Une autre municipalité canadienne pourrait-elle utiliser notre norme sans devenir dépendante d'Owen Sound ?

Si oui :

Nous avons construit une infrastructure.

Si non :

Nous avons peut-être simplement construit un autre fournisseur.

33.274L'Épreuve de la propriété publique

L'épreuve la plus profonde est :

Est-ce que le public contrôle réellement le but public ?

Pas :

Est-ce que le gouvernement possède chaque ligne de code ?

Le contrôle public signifie :

La propriété est un outil possible.

Pas le seul.

33.275Ce que map.ca ne devrait jamais devenir

map.ca ne devrait jamais devenir :

Si c'est l'un de ces éléments :

L'expérience d'infrastructure publique a échoué.

33.276Ce que pourrait devenir map.ca

Si elle est construite correctement, map.ca pourrait devenir quelque chose de beaucoup plus simple et utile :

Une couche d'intérêt public qui aide les gens à comprendre ce qui existe autour d'eux.

Où se trouve :

Qui entretient l'information ?

Quand a-t-elle été vérifiée ?

Comment puis-je en apprendre davantage ?

Cela seul peut créer une valeur civique importante.

33.277L'infrastructure publique devrait réduire les obstacles

L'essai n'est pas :

Combien de fonctionnalités map.ca possède-t-elle ?

L'essai est :

Combien de questions ordinaires un résident peut-il répondre plus facilement ?

Si elle devient suffisamment complexe au point que les résidents aient besoin d'une formation simplement pour trouver un parc :

Nous avons échoué.

33.278L'infrastructure publique devrait accroître les choix

Une carte saine devrait mener vers l'extérieur.

Elle devrait aider les résidents à atteindre :

Elle ne devrait pas piéger chaque interaction à l'intérieur d'elle-même.

33.279L'infrastructure publique peut parfois être banale

Une infrastructure réussie devient souvent invisible.

Vous ne célébrez pas la conduite d'eau tous les matins.

Elle fonctionne simplement.

map.ca devrait finalement être jugée de la même façon.

Pas par :

Par le fait que les résidents puissent compter sur les informations.

33.280L'infrastructure publique dépasse les personnalités

C'est le dernier test institutionnel.

Le meilleur résultat possible pour quelque chose que j'ai aidé à créer ne serait pas d'avoir mon nom attaché à jamais.

Ce serait d'atteindre le point où mon nom n'a plus d'importance.

Un autre maire.

Un autre conseil municipal.

Un autre développeur.

Un autre fournisseur de technologies.

L'intérêt public continue.

C'est ce que signifie construire quelque chose pour la communauté plutôt que pour le fondateur.

L'engagement en matière d'infrastructure publique de map.ca

La vision originale est audacieuse :

propriété publique protégée, une adresse civique durable, RealMap, YouthMap, un calendrier communautaire et des outils de données contrôlés par les résidents.

La gouvernance protégeant cette vision doit être encore plus forte.

L'engagement est le suivant :

Définir le problème public avant de sélectionner la technologie.

Établir la norme publique ouverte avant d'adopter map.ca.

Permettre au conseil municipal de rejeter map.ca tout en conservant la norme publique.

Divulguer toutes les relations pertinentes en matière de propriété et financières.

Obtenir une évaluation indépendante.

Obtenir une revue indépendante en matière municipale, d'approvisionnement, de confidentialité, de conflit, de concurrence, d'accessibilité et de cybersécurité.

Éloigner le maire des décisions où un conflit existe ou où la confiance publique exige une indépendance.

Ne jamais utiliser l'autorité de maire fort pour imposer l'adoption d'une plateforme liée au maire.

Aucun design d'approvisionnement du fondateur.

Aucune évaluation du fondateur.

Aucun veto du fondateur.

Aucune redevance perpétuelle automatique.

Aucune dépendance cachée à une entreprise liée.

Utiliser d'abord une norme municipale ouverte.

Considérer une structure de propriété indépendante d'intérêt public seulement après qu'elle ait passé la revue.

Ne pas considérer la propriété municipale directe comme la première hypothèse.

Transférer uniquement les actifs que l'objectif public exige réellement.

Assurer le contrôle institutionnel des domaines publics et des systèmes administratifs.

Rendre la plateforme fonctionnelle sans son fondateur.

Rendre l'information civique de base gratuite à consulter.

Ne pas exiger un compte pour accéder à l'information publique ordinaire.

Ne pas confondre une adresse courriel civique avec une identité juridique.

Transformer le « courriel pour la vie » en un modèle de gouvernance portable avant d'offrir une garantie littéralement pour la vie.

Cartographier les opportunités, les services et les lieux, pas les résidents vulnérables.

Garder YouthMap axé sur les opportunités pour les jeunes, pas sur leurs profils.

Garder RealMap facultatif.

Garder le calendrier communautaire gratuit à publier et gratuit à consulter sous des règles neutres.

Aucun classement payant dans la couche publique.

Aucune publicité comportementale.

Aucune vente des historiques de recherche des résidents.

Aucune utilisation politique des données des services civiques.

Une seule porte d'entrée ne signifie pas un seul profil résidentiel énorme.

Séparer les données selon leur objectif.

Recueillir uniquement ce dont le service public a réellement besoin.

Rendre claires la source et la vérification.

Permettre les corrections et les recours.

Garder l'information officielle distincte de l'information soumise par la communauté.

Utiliser l'IA pour aider les gens à comprendre l'information, pas pour devenir une autorité civique invisible.

Ne pas utiliser d'informations privées des résidents pour l'entraînement d'IA non lié.

Intégrer l'accessibilité dans la plateforme avant l'adoption municipale.

Préserver les services téléphoniques, sur papier et humains.

Publier des données ouvertes sécuritaires là où applicable.

Utiliser des interfaces ouvertes et des normes portables là où pratique.

Garder la capacité de changer de fournisseur technologique.

Tester l'exportation.

Tester la sauvegarde.

Tester la restauration.

Tester la sortie.

Savoir qui paie après la fin des subventions.

Publier le coût complet sur cinq ans.

Ne permettez pas que les infrastructures publiques deviennent ultérieurement un profit privé.

Si d'autres municipalités canadiennes adoptent ce modèle, permettez-leur de conserver leur propre autorité locale.

Publiez librement le manuel.

Rendre map.ca inutile à la politique et rendre le fondateur inutile à map.ca.

La preuve la plus forte que map.ca est devenue une infrastructure publique ne serait pas qu'Owen Sound ne pourrait jamais se passer de map.ca.

Ce serait l'inverse.

Owen Sound pourrait remplacer le logiciel demain et conserver tout de même l'information publique, les normes publiques, l'identité publique, la gouvernance publique et le service public.

C'est la différence entre une plateforme et une infrastructure.

Une plateforme se demande:

Comment gardons-nous l'utilisateur?

Une infrastructure publique se demande:

Comment assurons-nous que le service fonctionne pour le public?

Établissez d'abord la norme. Protégez l'objectif public. Séparez l'avantage privé du pouvoir public. Gardez l'information transportable. Garantissez la liberté des citoyens. Puis, permettez à la technologie de gagner le droit d'être infrastructure.

← Chapitre 32: Souveraineté numérique canadienneChapitre 34: Une relation formelle avec la Saugeen Ojibway Nation →