Bruno Michel a écrit 3181 commentaires

  • [^] # Re: 1ère série - préparer le terrain dans l'espace de rédaction

    Posté par (page perso) . En réponse à l'entrée du suivi Implémenter le nouveau design de LinuxFR. Évalué à 4 (+1/-0).

    Sans l'ombre d'un doute, vaut mieux les stocker sur le système de fichiers.

  • [^] # Re: 1ère série - préparer le terrain dans l'espace de rédaction

    Posté par (page perso) . En réponse à l'entrée du suivi Implémenter le nouveau design de LinuxFR. Évalué à 4 (+1/-0).

    Si on commence à faire intégrer une image par article, est-ce qu'il faut commencer à proposer le stockage des images directement sur le serveur de LinuxFr ? L'idée, c'est qu'avec ce nouveau design, l'image fait vraiment partie de l'article, du coup, faudrait-il un stockage pérenne ou on continue d'accepter des liens qui peuvent casser ?

    Oui, j'avais en tête de proposer de stocker les images sur le serveur de LinuxFr.org (au moins l'image principale des articles dans un premier temps). Mais je n'ai encore rien fait et vaut mieux ne pas compter sur moi. Un patch est le bienvenu ;-)

  • [^] # Re: Cas d'usage pour le téléchargement en markdown ?

    Posté par (page perso) . En réponse à l'entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 3 (+0/-0).

    J'ai 2 cas d'usage en tête :

    • une très grande majorité des contenus du site sont sous des licences libres, avoir le markdown permet de les réutiliser plus facilement ailleurs
    • ça permet d'apprendre la syntaxe markdown via des exemples : quelqu'un qui voit un contenu avec un tableau, une équation, des notes de bas de page peut aller voir le markdown pour comprendre comment faire quand il voudra écrire un prochain contenu avec l'une de ses fonctionnalités.
  • [^] # Re: CSS à ajuster ?

    Posté par (page perso) . En réponse à l'entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 3 (+0/-0).

    Je ne pense pas que ça vaille la peine de trop se casser la tête pour IE. Tant que les contenus restent lisibles, c'est suffisant.

  • # Humm

    Posté par (page perso) . En réponse à l'entrée du suivi Remplacer "modéré" par "affiché". Évalué à 4 (+1/-0).

    Le « affiché par » me laisse très perplexe. Ça ne me semble pas très compréhensible par le commun des mortels.

  • [^] # Re: Merci pour le patch

    Posté par (page perso) . En réponse à l'entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 3 (+0/-0).

    Très bonne idée !

  • # Merci pour le patch

    Posté par (page perso) . En réponse à l'entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 3 (+0/-0).

    Sommaire

    Merci pour la contribution.

    Pour information, Mathieu m'avait également donné une suggestion pour l'ordre des modifications à faire. Je la mets ci-dessous.


    Décomposition des changements

    Ci-dessous on décompose les changements qui nous paraissent essentiels. On propose d'implémenter ces changements par série, de sorte à garder la cohérence des changements liés entre eux et que chaque série apporte une amélioration perceptible.

    Priorité 1

    1ère série - préparer le terrain dans l'espace de rédaction

    Objectif : lister plus de contenus sur un même écran, inciter à consulter d'abord les contenus publiés sur LinuxFr, et à aller voir les ressources externes dans un second temps.

    • [ ] [Rédaction] faire évoluer le gabarit d'article pour inciter à écrire un chapeau
    • [ ] [Rédaction] faire évoluer le gabarit pour intégrer au moins une image
    • [ ] [Rédaction] faire évoluer le gabarit pour toujours afficher les liens à la suite de l'article
    • [ ] [Rédaction] permettre de créditer les auteurs des images
    • [X] [Actualités] sur la liste des articles, retirer les liens
    • [X] [Actualités] sur les articles, placer les liens externes à la suite du texte

    Dans chaque article, on peut placer les liens externes dans deux colonnes à la suite du texte :

    https://github.com/mjourdan/linuxfr-design/blob/master/experimentations_5/3.1.0_article.png

    Priorité 2

    2ème série - soigner l'accueil

    Objectif : faciliter le premier contact, la compréhension de l'objet du site et des différents types de contenus.

    • [ ] [Navigation] déplacer le menu utilisateur vers la partie droite du bandeau de navigation
    • [ ] [Navigation] ajouter le bouton « À Propos » dans le bandeau du haut
    • [ ] [Navigation] màj la terminologie pour la rendre plus accessible
    • [ ] [Accueil] afficher les unes (?) / actualités / billets séparément avec leurs traitements visuels respectifs
    • [ ] [Accueil] faire apparaître les sondages, derniers messages de forums, et dernières modifications de wiki
    • [ ] [Préférences] supprimer les préférences liées à l'accueil devenues obsolètes

    Sur la maquette ci-après, on a pas de « une » persistante. On garde la possibilité de mettre en avant des articles (cf Paperwork 1.1) mais ceux-ci peuvent descendre dans la liste au fil du temps :

    https://github.com/mjourdan/linuxfr-design/blob/master/experimentations_5/1.0.0_accueil.png

    La barre de navigation en haut et le menu utilisitateur doivent s'adapter au mobile :

    https://github.com/mjourdan/linuxfr-design/blob/master/experimentations_5/barre_de_navigation.png

    3ème série - affiner la liste des articles

    Objectif : inciter à consulter les articles publiés sur LinuxFr, distinguer les différents types de contenus

    • [ ] [Actualités] sur la liste des articles, afficher les chapeaux (ou un texte tronqué) et illustrations
    • [ ] [Actualités] sur la liste des articles, retirer la possibilité de pertinenter / inutiler
    • [ ] [Actualités] sur la liste des articles, implémenter le traitement visuel
    • [ ] [Actualités] sur la listes des actualités, faire apparaître les articles les plus visités et les derniers commentaires

    4ème série - affiner la liste des billets

    Objectif : inciter à consulter les billets, renforcer la distinction articles éditoriaux / billets personnels

    • [ ] [Blogs] sur la liste des billets, afficher les chapeaux et illustrations
    • [ ] [Blogs] sur la liste des billets, retirer la possibilité de pertinenter / inutiler
    • [ ] [Blogs] sur la listes des blogs, faire apparaître les billets les plus visités et les derniers commentaires
    • [ ] [Blogs] sur la liste des billets, implémenter le traitement visuel

    Priorité 3

    5ème série - améliorer le suivi des commentaires

    Objectif : améliorer le confort de navigation parmi les commentaires, augmenter le rapport signal / bruit.

    • [ ] [Commentaires] mise en forme des commentaires (avatars arrondis, notes…)
    • [ ] [Commentaires] mettre en valeur les commentaires jugés pertinents par les auteurs des articles auxquels ils répondent (les messages des autres utilisateurs et ceux des auteurs eux-mêmes)
    • [ ] [Commentaires] permettre de rédiger un commentaire sans perdre le contexte (ni quitter la page ni perdre le suivi des commentaires non lus)
    • [ ] [Commentaires] nouveaux filtres de navigation (selon la note, afficher/masquer les erreurs de français)
    • [ ] [Commentaires] permettre de signaler des erreurs de français (fil positionné à la suite des autres commentaires)

    6ème série - nouvelle barre de navigation

    Objectif : adapter la navigation aux mobiles et aux interfaces tactiles

    • [ ] [Tribune] regrouper les espaces de discussion instantanée
    • [ ] [Tribune] permettre de les afficher/masquer à volonté sur mobile, depuis les barres de navigation
    • [ ] [Navigation] implémenter la nouvelle barre pour naviguer parmi les contenus / commentaires
    • [ ] [Rédaction] implémenter la nouvelle barre pour naviguer dans l'espace de rédaction
    • [ ] [Rédaction] implémenter la nouvelle barre pour rédiger les articles
    • [ ] [Navigation] màj la liste des catégories, plus courte et accessible

    Priorité 4

    7ème série - blogs

    Objectif : transformer les journaux en des blogs attrayants

    • [] [Blogs] soigner la présentation des profils
    • [] [Blogs] permettre d'éditer son profil depuis la page idoine
    • [] [Blogs] séparer les différents contenus par onglets
    • [] [Blogs] permettre d'épingler quelques contenus

    8ème série

    Objectif : améliorer le confort de rédaction & de navigation

    • [ ] [Rédaction] lister l'ensemble des articles et billets auxquels les gens participent sur la page de rédaction
    • [ ] [Notification] mettre en place le système de notification
  • # Benchmarks pas très intéressants

    Posté par (page perso) . En réponse au journal Navigateur web, l'impossible choix. Évalué à 10 (+14/-0).

    Pendant un paquet d'années, les navigateurs se faisaient concurrence sur les performances et les benchmarks étaient les juges en la matière. Chaque éditeur avait plus ou moins son benchmark où, étonnamment, son navigateur s'en sortait mieux que dans les benchmarks des autres navigateurs. Depuis 2 ou 3 ans, les éditeurs ont changé de bord et abandonnent ces benchmarks. Ils se sont rendus compte qu'ils étaient arrivés à une situation où améliorer le score pour les benchmarks donnait souvent des résultats moins bons dans la vraie vie (un phénomène de sur-optimisation pour des cas spécifiques).

    D'autre part, les benchmarks mettent souvent en avant les calculs en JS, ce qui est rarement là que l'impression de vitesse pour les utilisateurs se joue. Les accès au DOM ou savoir charger les bonnes ressources au bon moment sont souvent plus importants.

    Bref, aujourd'hui, Firefox est généralement considéré comme le navigateur le plus rapide (suite à pas mal d'optimisations très récentes), suivi de très près par Chrome. Chrome est généralement considéré comme le navigateur le plus avancé en termes de sécurité (séparation en plusieurs processus notamment), suivi de près par Firefox. Derrière, j'entends de temps en temps parler en bien de Falkon, mais les autres navigateurs jouent surtout sur le côté plus léger (moins de fonctionnalités, moins d'extensions, etc.).

  • [^] # Re: Il faudra s'en occuper un jour

    Posté par (page perso) . En réponse à l'entrée du suivi Ruby Sass est déprécié. Évalué à 3 (+0/-0).

    A priori, sass-rails va devenir un wrapper autour de sassc-rails : https://github.com/rails/sass-rails/pull/424.

  • [^] # Re: Yep

    Posté par (page perso) . En réponse à l'entrée du suivi Avoir une meilleure configuration HTTPS. Évalué à 3 (+0/-0).

    On a maintenant un score de A sur https://tls.imirhil.fr/https/linuxfr.org

  • # Il faudra s'en occuper un jour

    Posté par (page perso) . En réponse à l'entrée du suivi Ruby Sass est déprécié. Évalué à 3 (+0/-0).

    C'est effectivement un problème connu depuis un bout de temps. Pour le moment, la communauté Rails n'a pas l'air très décidée sur le chemin à prendre :

    • certains proposent effectivement d'utiliser Dart Sass en l'embarquant dans une gem Ruby, mais personne n'a l'air d'avancer dans ce sens (ie écrire du code et être prêt à le maintenir)
    • d'autres suggèrent de passer à sassc-rails, mais ce n'est pas très clair si le mainteneur de sassc-rails va encore maintenir cette gem très longtemps, et là encore, il n'y a pas de contributeurs
    • enfin, Rails est en train de migrer progressivement de son assets pipeline vers webpack, et possiblement, la manière conseillée d'utiliser sass avec Rails 6.0 sera de passer via webpack.

    Bref, pour le moment, le mieux est sûrement de continuer à attendre https://github.com/rails/rails/issues/32896, sachant qu'il n'y a pas d'urgence. Même si la version Ruby de Sass n'est plus prise en charge officiellement, elle ne va pas s'arrêter de marcher du jour au lendemain.

  • [^] # Re: Prêt à être ingégré

    Posté par (page perso) . En réponse à l'entrée du suivi Changement icone pour dépêche kde. Évalué à 4 (+1/-0).

    Merci, c'est fusionné et déployé en prod.

  • # Une réponse

    Posté par (page perso) . En réponse au lien Wayland can’t be keylogged, unlike X11.. Évalué à 10 (+9/-1).

    Il semblerait qu'une bonne partie de ces critiques de Wayland ne sont plus valides actuellement, voir ont toujours été inexactes/fausses.

    Source : https://drewdevault.com/2019/02/10/Wayland-misconceptions-debunked.html

  • [^] # Re: Coquille

    Posté par (page perso) . En réponse à la dépêche Financement participatif pour Akira. Évalué à 2 (+0/-1).

    Merci, c'est corrigé.

  • [^] # Re: scenari

    Posté par (page perso) . En réponse au journal Gestion de documentation. Évalué à 3 (+0/-0).

    Je me suis permis d'éditer le commentaire pour corriger le lien vers le Site de dokiel.

  • # Erreur sur un lien

    Posté par (page perso) . En réponse à l'entrée du suivi Impossible de soumettre une dépêche. Évalué à 3 (+0/-0).

    J'ai regardé rapidement, ça plante sur un lien avec ce message d'erreur :

    URI::InvalidURIError (URI must be ascii only "https://inkscape.org/fr/~wwderw/\u{2605}inkstitch-embroidery-extension")
    
  • # Lien trop long

    Posté par (page perso) . En réponse à l'entrée du suivi Impossible de soumettre une nouvelle dépêche. Évalué à 3 (+0/-0).

    En lisant rapidement les logs, le problème vient d'un lien avec un titre trop long pour la colonne dans MySQL : 'From the bitstream to the netlist, la démonstration qu'il est possible de faire la rétro-ingéniérie des bitstream'.

  • [^] # Re: La taille ça compte...

    Posté par (page perso) . En réponse à la dépêche git-bug: un bug tracker distribué intégré dans git. Évalué à 4.

    Ce qui peut être très pénalisant quand tu dois cloner souvent comme par exemple les serveurs de build.

    Pour des serveurs de build, ça se contourne facilement en ne clonant que la branche à builder, voir même que les n derniers commits de la branche en question. C'est ce que fait travis par exemple (avec n = 50). On peut même aller plus loin avec les sparse checkout.

  • [^] # Re: en même temps

    Posté par (page perso) . En réponse au lien Weboob se prend un coup de pied dans les c***. Évalué à 3.

    le merge request proposant un nouveau nom à eu une réponse via le bug tracker

    La réponse vient d'une personne qui n'est pas un des développeurs de weboob et qui regrette l'absence de réponse :

    I have no power here and I am a bit sad your ticket has no answer

  • [^] # Re: en même temps

    Posté par (page perso) . En réponse au lien Weboob se prend un coup de pied dans les c***. Évalué à 2.

    Bref, on adapte la "règle" pour que ça rentre dans le "acceptable" en faisant de sorte que ça passe pour ce qu'on aime et que ça ne passe pas pour ce qu'on n'aime pas.

    Non, je n'adapte pas la règle. Oui, c'est un plus pour un projet que d'être dans les dépôts standard, mais ce n'est pas pour autant que c'est de la censure que d'exclure un projet.

    Si je prends un parallèle : sur LinuxFr.org, on refuse les dépêches qui parlent de logiciels propriétaires avec peu de rapport avec Linux. Je ne considère pas ça comme de la censure, vu que ces logiciels peuvent faire trouver d'autres endroits pour parler d'eux. Et pourtant, je suis convaincu que ça serait un plus pour ces projets que d'être cités sur LinuxFr.org (c'est un bon relai pour toucher certains publics).

  • [^] # Re: en même temps

    Posté par (page perso) . En réponse au lien Weboob se prend un coup de pied dans les c***. Évalué à 3.

    Je ne considère pas que Debian soit l'autorité compétente sur les publications, émissions et spectacles destinés au public. Debian fournit de base les outils pour utiliser des dépôts tiers et n'a mis en place aucune restriction pour empêcher un dépôt tiers de fournir weboob. Debian ferait de la censure s'ils empêchaient d'avoir weboob sur les ordinateurs qui tournent avec Debian, ce qui n'est pas le cas ici.

  • [^] # Re: en même temps

    Posté par (page perso) . En réponse au lien Weboob se prend un coup de pied dans les c***. Évalué à 4. Dernière modification le 21/12/18 à 09:25.

    Mes affirmations s'appuient sur ce mail de Ian Jackson (ancien Debian Project Leader) : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907199;msg=32. je cite :

    Well, others have definitely been trying that. There is an issue in
    the upstream tracker (mentioned in the footnote of Niels's message);

    https://git.weboob.org/weboob/devel/issues/154

    This was reported in early August and has had no responses from the
    upstream maintainers, despite several pings from other people. I
    think it is clear that upstream are aware of the complaint but are not
    dealing with it (perhaps because it's no fun, or perhaps as deliberate
    strategy).

    […]

    So it's true that we don't know for sure what upstream's current view
    is on this situation, but that's not because no-one has tried to talk
    to them about it.

    […]

  • [^] # Re: en même temps

    Posté par (page perso) . En réponse au lien Weboob se prend un coup de pied dans les c***. Évalué à 5.

    l'équipe Debian a contacté les développeurs de Weboob par d'autres canaux (mails a priori) et n'a vraiment reçu aucune réponse

    En fait, il y a aussi cette entrée sur le bugtracker de weboob : https://git.weboob.org/weboob/devel/issues/154

  • [^] # Re: en même temps

    Posté par (page perso) . En réponse au lien Weboob se prend un coup de pied dans les c***. Évalué à 4.

    Ils ont accepté les merge request pour virer les insultes; je n'appelle pas ça aucun effort.

    Je n'ai pas été très clair :

    • l'équipe Debian n'a pas fait cette merge request, j'ai mis la merge request que pour illustrer les commentaires litigieux
    • l'équipe Debian a contacté les développeurs de Weboob par d'autres canaux (mails a priori) et n'a vraiment reçu aucune réponse
    • par aucun effort, je voulais dire que les développeurs de Weboob n'ont fait aucun effort pour collaborer avec l'équipe Anti harrasement de Debian.
  • [^] # Re: en même temps

    Posté par (page perso) . En réponse au lien Weboob se prend un coup de pied dans les c***. Évalué à 10.

    les distros sont de plus en plus lisse, et acceptent de moins en moins l'humour

    Dans le cas de weboob, on peut difficilement qualifier ça d'humour. L'article l'explique mal mais la décision de Debian ne s'appuie pas sur le nom weboob et les logos associés. Quand la question avait initialement été levée, Debian avait d'abord choisi de conserver le paquet. En parallèle, l'équipe Anti-Harassment de Debian a essayé de travailler avec les développeurs de weboob pour améliorer les choses. Ils ont suggéré de trouver un autre nom (mais ça restait une simple suggestion, pas une obligation ou une menace) et surtout il y a eu une demande pour retirer des commentaires homophobes du code (cf https://git.weboob.org/weboob/devel/merge_requests/228/diffs). Les développeurs de weboob n'ont fait aucun effort, pas même de répondre à l'équipe Debian pour leur donner leur point de vue. Et c'est tout ce contexte ensemble qui a mené à inverser la décision et à retirer le paquet de Debian.