Workshop/Réunion DocHub Q2 Editer

Le 15/02/23, de 18:00 à 20:00.
Online
Organisateur : C4

Personne n'est intéressé pour l'instant Je le suis !

Description

DocHub a encore cartonné pendant les examens, les utilisateurs ont émis des souhaits, des délégués sont venus vers nous pour avoir les droits de modération, plein de bonnes nouvelles !

Prenons un peu de temps pour planifier ce qu'on fera sur DocHub pendant le quadri pour le rendre encore plus cool/utile pendant la session de juin :)

Focus points à garder en tête:

  • Comment rendre les utilisateurs heureux le plus facilement possible
  • Comment rendre le code plus accessible/lisible/pédagogique pour des nouveaux contributeurs
  • Visons des objectifs faisables, on sait bien qu'on a tendance à over-commit, under-deliver

Vague OJ:

  • Comment organiser le développement du projet
    • Qui est motivé de prendre quelle responsabilité ?
  • Quelles sont les features que des utilisateurs demandent ?
  • Comment améliorer la codebase actuelle ?
  • Dans quel ordre est-ce qu'on prioritise les taches qu'on vient d'identifier ?
  • Qui s'engage à prendre quelle tache ? Avec quelle échéance ?
  • Si il reste du temps: condons ensemble \o/

L'image de couverture, malheureusement croppée est une reprise de la couverture du bouquin The Lean Startup

Ordre du jour

  • Comment organiser le développement du projet
    • Qui est motivé de prendre quelle responsabilité ?
  • Quelles sont les features que des utilisateurs demandent ?
  • Comment améliorer la codebase actuelle ?
  • Dans quel ordre est-ce qu'on prioritise les taches qu'on vient d'identifier ?
  • Qui s'engage à prendre quelle tache ? Avec quelle échéance ?
  • Si il reste du temps: condons ensemble \o/

Compte rendu

  • Comment organiser le développement du projet
    • Qui est motivé de prendre quelle responsabilité ?
  • Quelles sont les features que des utilisateurs demandent ?
  • Comment améliorer la codebase actuelle ?
  • Dans quel ordre est-ce qu'on prioritise les taches qu'on vient d'identifier ?
  • Qui s'engage à prendre quelle tache ? Avec quelle échéance ?
  • Si il reste du temps: condons ensemble \o/

Bilan session janvier 2023:
* 1M pages vues
* 1.5k users/jour
* (et puis ça drop la semaine du ski)
* Reçu des suggestions par email et des gens ont cliqué sur le bouton "je suis délégué j'aimerais plus de droit"
* => Dochub est utilisé
* Polytech demande des droits de modération

Quelle est la définition du succès de Dochub? Qu'est ce qu'on veut faire avant tout? piR argumente qu'il faut faire une prioritisation des objectifs et faire des choix
* Un max de monde utilise Dochub et on maximise l'aide apporté (métrique: croissance en nombre de users ?)
* "Si on te demande un doc, tu link dochub par réflexe, pas un google drive ou du genre"
* Que le projet reste en vie (maintenu et à jour) & plus de devs et plus de gens impliqués
* Pérénité du projet ++ via (métrique: croissance en nombre de devs)

Est-ce que les chiffres de croissance sont juste dus à l'augmentation d'étudiants en info, ou est-ce qu'on a pris plus de "parts de marché" ?

Pics d'activité en dev correlés avec les pics d'activité au HS ?
2 ans de COVID: pas d'activités IRL, pas de "brassage social", pas d'occasion de rencontrer des nouveaux devs potentiels
=> Refaire des events sociaux au HS et promote Dochub

Qui veut faire quoi ?
Morti:
coder par burst
motiver des nouveaux étudiants (avec des workshops)
Pinebook
pas coder
aider à l'administratif
contact avec les bureaux
Titou
pas proactivement
C4

Thibault
relancer le hs, par transitivité ça pourrait trouver des dev
Minigrimo
Plus motivé
Bruno/UNixcorn:
il faut demander, il serait peut-être chaud

"C'est le CI qui paye Dochub ? - Je crois qu'ils sont même pas au courant qu'ils payent pour ça"

A mettre dans le readme: workflow

  • Issues le plus possible. Dès que t'as une idée en tête, dès que tu code quelque chose
  • Si c'est un bugfix, ou mineur, pas besoin d'issue
    • PR avec review uniquement si ça demande une review (genre estéthique, feature). Pas pour un bugfix (alors juste open puis merge)
  • Si on deploy master en prod, tagger une release
  • Essayer de tenir un changelog dans la release (au minimum une liste de PR)

Pad de la réunion

https://pad.lqdn.fr/p/dochub-meeting

Membres présents

Aucun membre présent Je serai present !