Le retour de la vengeance des statistiques

Que seraient des données non-discrètes ? Dans tous les cas il y a un pas de temps discret, non ?

Discrète est effectivement un mauvais terme. Régulière et espacée serait une meilleure description.

Pour des données non discrète, je dirai que c’est le cas d’une fonction, qui peut être continue et cohabiter sur un graphe avec des points de mesure (typiquement si on ajoutait une courbe de tendances). Si mon exemple ne te conviens pas, je t’invites à en discuter par MP, pour ne pas polluer la discussion.

Je préfère les barres mais comme l’a dit Situphen, pourquoi pas un bouton pour passer de l’un à l’autre histoire de contenter tout le monde .

@Eskimon, comment passe-t-on de la version à une courbe à celle avec plusieurs ? Il serait très appréciable d’avoir l’option de ne pas afficher toutes les courbes (ou barres), par exemple pour ne comparer que deux sections.

Sous les graphs il y a un tableau avec toutes les pages du contenu qui reprend les données du graph sous forme tabulaire (somme/moyenne des données sur la période de temps étudiée)

Une courbe = quand tu es sur la page "d’accueil" qui visualise les données de toutes les pages du tuto cumulées OU quand tu sélectionnes une page a visualiser en particulier (en cliquant sur la page dans le tableau).

Plusieurs courbes = quand tu sélectionnes plusieurs pages a comparer entrés elles (sélectionnées via des cases a cocher dans le tableau).

C’est plus clair ? (Si non, je pourrais éventuellement te faire des captures d’écran demain)

Plusieurs courbes = quand tu sélectionnes plusieurs pages a comparer entrés elles (sélectionnées via des cases a cocher dans le tableau).

Parfait !

par contre les gens, faites des rebase, pas des merge, là on sera obligé de faire un "squash" d’après github

My bad :s si je revert le merge pour faire un rebase, ça passera ?

pas sûr que ça marcherait, je dirais plutôt qu’il faudrait faire un rebase -pi {sha_avant_ton_premier_commit} puis squasher les commits de merge.

Cependant je ne suis pas sûr. @sandhose en saura peut être plus.

Ça risque d’être très marrant tout ça. Mais je suis pas sûr de comprendre pourquoi le fait d’avoir mergé dev dans ma branche ferait du bazar pour ensuite mergé ma branche dans dev’.

sur zds on ne peut faire que "rebase & merge" ou bien "squash & merge".

si tu fais "rebase & merge" alors il faut absolument qu’aucun commit ne soit en conflit avec la base. Or, lorsque tu choisis de faire un "merge" tu gardes le commit conflictuel et tu y ajoutes un commit "de merge" qui corrige le conflit. De ce fait je n’ai plus le droit que de faire "squash" et je n’ai aps envie de mettre ce développement complet en un seul commit.

Bon, le moins que l’on puisse dire c’est que à chaud, 12h après, on a a autant de préférence pour les barres que pour les lignes (6v6). Je vais récupérer les modifications proposées par Situphen, testé et donner quelques illustrations, mais j’ai confiance, je pense que tout ira bien

Voili voila ca donne ca (et Vayel, j’ai pensé à toi, on voit aussi comment sélectionné une seule page ou un ensemble de pages) :

Les tests passent, on est à jour sur dev’, toutes les features sont là, bref on est content d’être heureux. Le code pourra bientôt venir grossir la base commune !

Un gros GG et merci à toutes les personnes qui ont filé un coup de main, de près ou de loin, pour cette nouvelle fonctionnalités. On tient là une feature différenciante et qui va tout à fait dans le sens de la transparence et l’ouverture de l’association. Bravo à tous (et merci à la masse silencieuse qui a mis des +1 au fil des annonces, ca fait toujours plaisir et c’est motivant de voir que ce que l’on fait est attendu, consulté et apprécié ).