# Follow-up de https://hackmd.io/pa1jEcdzTj6rcOKloTl3rA?both

> Un autre point random que je n'ai pas abordé, mais c'est pour plus tard : garder un historique des incidents (de tout type, techniques mais pas seulement, du moment que c'est "disclosable" à une certaine audience) permet d'apprendre de nos erreurs et de mettre en place des recherches de solutions à plus grande échelle.

> Un point que je voulais soulever aussi : écrire les choses permet de rendre les gens moins indispensable, être indispensable est une mauvaise chose, pour soi et pour l'entreprise, même si certains peuvent penser le contraire. Nous sommes indispensables pas parce que nous détenons un accès, une information, une connaissance mais parce que nous pouvons continuer à faire des bonnes choses.
Je ne sais pas s'il faut le formuler ici ou pas, peut-être que si.

> Communiquer sur l'importance du wiki pour responsabiliser les gens.
> * Et avoir une page très visible sur le wiki pour rappeler cette importance et comment communiquer (sur le wiki, Slack, par mail, etc.).
> * Un rédacteur technique pourrait être pertinent pour cela.

> TODO : mettre le reste de cette section sur la page du processus de communication.
>
> Canaux :
> - limiter la multiplication des canaux pour un même type d'information (e.g. annonces RH faites sur zoom, slack, mail, affichage bureaux)
> - ne pas mélanger différents types d'information sur les mêmes canaux (discussions éphémères mélangées aux annonces sur slack)
>
> Pour tout partage d'information : identifier celles qui doivent être communiquées à une plus large audience ou conservées de façon pérenne.
>
> Audience :
> - rendre disponible les connaissances à tout le monde s'il n'y a pas besoin de restreindre : transparence, compréhension, résilience (éviter les single point of failure)
> - identifier les audiences (e.g. annonces internes à l'équipe, à tout R&D, ...)
> - communiquer les annonces sur les bons canaux

> Garder les sections Onboarding et Formation ci-dessous pour plus tard.

> # Onboarding
>
> Buts :
> - Meilleur accompagnement (plus humain, ne pas laisser les gens se dépatouiller tous seuls)
> - Efficacité, gagner du temps sur le court et le long terme
>
> Il faut un process bien défini, harmonisé, avec des responsables, des gens formés.
>
> Tronc commun :
> - Avant embauche : RH/sysadmin
> - 1ers jours : RH/sysadmin + "onboardeur"
> - formations de base (pratique, outils, connaissance), peut être guidé par le wiki
> - rencontres
> - tâches d'introduction, suivi par l'onboardeur
>
> Spécialisation :
> - après : au sein de l'équipe
> > zd: à mon avis, il faut aussi un onboarding DT qui présente l'organisation par crew des projets et qui disent clairement l'information relation à avoir avec le DRI et celle à avoir avec le responsable d'équipe car cela dépend des personnes.
> À définir plus précisément à partir de
> - https://gitlab.com/nomadic-labs/private/ouiki/-/wikis/internships_checklist
> - https://codimd.nomadic-labs.com/e4PTNP-STDaXLysw92z6vQ
>
> # Formation
>
> - Mettre en place une formation continue interne.
> - Identifier les priorités.
> - Trouver des formateurs (internes ou externes).
> - Former les nouveaux et re-former les anciens (aux nouvelles choses).
> - Inciter à suivre des formations.
>
> https://codimd.nomadic-labs.com/GC7p_n09RaS96F9keURkew#