GitHub

Depuis un an, j'ai pris conscience d'une difficulté inhérente aux organisations qui suivent le paradigme Multirepos, difficulté dont je ne m'étais pas rendu compte auparavant : décider où publier ses issues !

J'ai observé que dès qu'une organisation commence à utiliser plusieurs repositories, la question de l'endroit où créer de nouvelles issues se pose. Par exemple :

• Où poster une issue d'amélioration qui nécessite des changements dans le repository A et B ?
• Où créer une issue d'une proposition d'un process qui ne concerne pas spécifiquement le code source d'un projet hébergé dans un repository ?
• Où créer une issue dont le but est de créer un nouveau service ?

Quand une organisation suit le paradigme Monorepo avec issues colocalisées et utilise, comme je l'explique dans la note "Nom et arborescence de Monorepo" un nom non spécifique, alors la question de l'endroit où publier ses issues ne se pose pas ! Il suffit de publier l'issue dans le Monorepo (par exemple sur GitHub, GitLab ou Forgejo).

Le gestionnaire d'issue du Monorepo est un point de schelling, c'est-à-dire un endroit où tous les développeurs convergent naturellement en l'absence de communication explicite pour trouver et créer des issues.

Ce paradigme évite des débats à propos de l'endroit où publier les issues.

Je suis un adepe du paradigme Monorepo, de la documentation colocalisée et des issues colocalisées.

Je conseille de nommer le repository avec le nom de l'organisation.

Par exemple, si mon organisation se nomme « Dummy Tech » et si elle utilise GitLab, alors je conseille d'utiliser le slug dummy-tech, ce qui donne gitlab.com/dummy-tech/dummy-tech/ et « Dummy Tech Monorepo » comme titre de repository.

La neutralité de ce nom facilite les décisions concernant ce qui peut ou non être inclus dans le repository, sans être limité par un nom trop restrictif. Il est flexible face à l'évolution du projet. Il permet d'éviter bien des débats à propos du nommage.

En 2018, sur GitHub, j'ai découvert un exemple de monorepo d'une organisation. Cet exemple m'a servi de base et je l'ai fait évoluer quand je travaillais chez Spacefill.

Voici un exemple d'arborescence de monorepo que j'aime utiliser :

dummy-tech
├── deployments
│   ├── prod
│   └── sandbox
├── ci
├── docs
├── playgrounds
│   ├── playground_a
│   └── playground_b
├── services
│   ├── service_a
│   ├── service_b
│   └── service_c
└── tools
    ├── tool_a
    ├── tool_b
    └── tool_c

En 2016, Philippe Lafoucrière m'a appris que contrairement aux règles de typographie française, en typographie anglaise, il ne faut pas placer d'espace avant le caractère deux points :.
Je pense d'ailleurs que cette différence est peu connue par les Français et inversement.

Une des conséquences malheureuses de cette différence est la présence généralisée d'une popup de suggestion automatique d'émojis après la séquence <espace>: dans les éditeurs de texte Markdown. Cette fonctionnalité est activée par défaut, sans option pour la désactiver, par exemple, dans GitHub, GitLab ou Discourse.

Exemple :

En 2022, j'ai implémenté et publié un User Styles pour Firefox (maintenant LibreWolf) basé sur Stylus pour désactiver cette autosuggestion automatique d'émojis sur GitHub, GitLab.

Je viens d'ajouter une règle pour Discourse.

Voici ces règles exécutées par Stylus (le fichier) :

@-moz-document regexp("http.*gitlab.*") {
    .atwho-container #at-view-58 {
        display: none !important;
    }
}

@-moz-document domain("github.com") {
    [class^="AutocompleteSuggestions"] {
        display: none !important;
        visibility: hidden !important;
    }
}

@-moz-document regexp(".*discourse.*"), regexp(".*discussion.*") {
    .autocomplete.ac-emoji {
        display: none !important;
    }
}

Comment l'installer ?

• Installer l'extension Firefox : https://add0n.com/stylus.html
• Et ensuite, cliquer sur le lien suivant pour installer mon fichier User Styles : https://github.com/stephane-klein/dotfiles/raw/refs/heads/main/userstyles/disable-gitlab-github-discourse-emoji-picker.user.css

Je vais essayer de rassembler mes User Styles dans ce dossier : https://github.com/stephane-klein/dotfiles/tree/main/userstyles.

Alexandre m'a fait remarquer que GitLab a activé par défaut une extension Markdown de génération automatique de TOC :

A table of contents is an unordered list that links to subheadings in the document. You can add a table of contents to issues, merge requests, and epics, but you can’t add one to notes or comments.

Add one of these tags on their own line to the description field of any of the supported content types:

[[_TOC_]]
or
[TOC]

• Markdown files.
• Wiki pages.
• Issues.
• Merge requests.
• Epics.

source

Je trouve cela excellent que cette extension Markdown soit supportée un peu partout, en particulier les issues, Merge Request… 👍️.

Cette fonctionnalité a été ajoutée en mars 2020 🫢 ! Comment j'ai pu passer à côté ?

GitHub permet d'afficher un TOC au niveau des README, mais je viens de vérifier, GitHub ne semble pas supporter cette extension TOC Markdown au niveau des issues… Pull Request…

#JeMeDemande si Obsidian ou SilverBullet.mb supportent la syntax URL text fragment 🤔.

Claude.ia m'a appris que les URL text fragment se nomment aussi des "deep linking to text".

J'ai effectué les recherches suivantes sur GitHub :

• « obsidian deep linking » et j'ai trouvé :
  • deep-notes mais le README "vide" ne m'a pas donné envie de le tester
• « obsidian fragment » mais je n'ai rien trouvé de pertinent

J'ai effectué les recherches suivantes sur https://forum.obsidian.md :

• « deep link » et j'ai trouvé :
  • En lisant "Link to Block does not work with non-default themes" #JaiDécouvert la fonctionnalité d'Obsidian nommée "Link to a block in a note" qui est à l'usage très pratique.
• « fragment » et j'ai trouvé :
  • "I think text fragment could be very useful in Obsidian" qui correspond à la question que je me pose.

Pour le moment, je pense qu'avec Obsidian la seule solution est d'utiliser la fonctionnalité "Link to a block in a note".

---

Voici mes recherches concernant SilverBullet.mb.

Dans la page "Links" j'ai trouvé la fonctionnalité "Anchors."

J'ai effectué les recherches suivantes sur https://community.silverbullet.md:

• « deep »
• « fragment »

et je n'ai rien trouvé d'intéressant.

J'ai ensuite effectué des recherches sur GitHub :

• « deep »
• « fragment »

je n'ai rien trouvé d'intéressant non plus.

---

J'ai posté le message suivant sur « I wonder if SilverBullet could take advantage of the “URL text fragment” standard 🤔 ».

Version française :

Il y a quelques jours, j'ai découvert la fonctionnalité URL text fragment (ma note à ce sujet en français). Depuis, j'utilise l'extension Firefox "Link to Text Fragment" pour partager des liens précis et je trouve cela très simple d'usage.

J'ai bien identifié la fonctionnalité Anchors de Silverbullet pour créer un lien vers une position précise dans une page interne à SilverBullet.

Je me demande si SilverBullet pourrait tirer parti de la norme "URL text fragment" 🤔.

J'imagine une syntaxe du type [[MyPage#:~:text=foobar]].

Pour le moment, j'ai du mal à imaginer les avantages /inconvénients de cette idée de fonctionnalité par rapport à l'utilisation de "Anchors".

J'ai cherché si Obsidian supportait les URL text fragment, je constate que non.
Chez Obsidian l'équivalent de Anchors semble être Link to a block in a note.

Quelle est votre intuition à ce sujet ?

Version anglaise :

A few days ago, I discovered the URL text fragment feature (my note about this in french). Since then, I've been using the Firefox extension “Link to Text Fragment” to share specific links, and I find it very easy to use.

I did identify Silverbullet's Anchors feature for linking to a specific position on a SilverBullet internal page.

I wonder if SilverBullet could take advantage of the “URL text fragment” standard 🤔.

I can imagine a syntax like [[MyPage#:~:text=foobar]].

For now, I'm struggling to imagine the advantages/disadvantages of this feature idea compared to using “Anchors”.

I've looked to see if Obsidian supports URL text fragments, and find that it doesn't.
Obsidian's equivalent of Anchors seems to be Link to a block in a note.

What's your feeling about this?

La fonctionnalité "Activité" de GitLab me manque dans GitHub.

Voici trois exemples concrets de fonctionnement de cette fonctionnalité, dans trois contextes différents.

Le premier, dans le projet GNOME Shell :

Le second, dans le groupe Wayland : https://gitlab.freedesktop.org/groups/wayland/-/activity

Et le troisième, pour l'utilisateur Lucas Stach: https://gitlab.freedesktop.org/users/lynxeye/activity

Je trouve cette fonctionnalité très utile quand on travaille sur un projet. Elle permet d'avoir une vue d'ensemble de ce qui s'est passé sur un projet sur une période. Elle vient en complément de l'historique Git qui est limité aux changements effectués sur le code source.

Dans certaines situations, je sais qu'un collègue travaille sur un sujet qui me concerne et la fonctionnalité "Activité" me permet de mieux comprendre où il en est, de suivre facilement ce qu'il fait.

Cette fonctionnalité "Activité" permet de pratiquer la stigmergie.

J'utilise aussi cette fonctionnalité lors de la rédaction d'un rapport d'activité ou d'un message de Daily Scrum. Elle m'aide à retrouver précisément ce que j'ai fait dernièrement.

Je trouve la page "Contribution activity" d'un user GitHub limité, par exemple, elle ne contient pas l'historique des commentaires.

Même chose au niveau d'un projet, dans la page "Pulse", par exemple : https://github.com/sveltejs/kit/pulse.

Je viens de regarder du côté de Codeberg / Forgejo : <https://codeberg.org/forgejo/forgejo/activity. Même constat que pour GitHub, les informations sont très réduites.

J'aime être explicite, j'évite l'utilisation des acronymes, j'essaie de désigner les ressources (lien vers un paragraphe, une fonction, une issue, un contrat, un client…) avec des URLs, afin d'éviter toute ambiguïté.

J'ai de plus en plus l'intuition que l'usage d'un Organisation knowledge management combiné à de multiples Personal knowledge management de type Obsidian, SilverBullet.mb sont très utiles dans un contexte de travail en équipe et dans une organisation.

Partant de cette préférence et de cette intuition, j'ai eu une idée, j'ai ressenti un besoin que je vais expliquer dans cette note.

Je suis en train de rédiger une issue dans GitHub.
Dans la description de l'issue, je souhaite faire mention de la notion de PII et d'un champ de base de données.

J'aimerais développer une extension navigateur qui permet de saisir des wikilink ([[PageName|custom title]]) dans les zones de texte supportant de Markdown de GitHub, GitLab, Trello, Mattermost, Zullip, etc, avec le support de la recherche / autocomplétion.

J'aimerais ajouter une fonctionnalité qui affiche, lors du survol d'un wikilink, un popup contenant un aperçu de la page liée. Cela permet, par exemple, de consulter rapidement la signification d'un acronyme ou d'identifier une ressource.

J'aimerais que cette extension puisse être connecté à un ou plusieurs knowledge management system.

Quelques ressources pour migrer de GitHub à Codeberg :

• https://codeberg.org/Recommendations/Mirror_to_Codeberg
• https://www.rahuljuliato.com/posts/github_to_codeberg

#JaiDécouvert Sourcebot (from) :

Sourcebot is an open-source code search tool that allows you to quickly search across many large codebases.

C'est une alternative à Sourcegraph.

Je suis ravi de voir qu'il existe de plus en plus d'alternatives communautaires à GitHub ou GitLab, comme Forgejo, Weblate, Woodpecker CI et maintenant Sourcebot.

Lorsque vous collaborez avec moi et partagez du code source ou des extraits de terminal dans un logiciel compatible avec le format Markdown, tel que GitHub, GitLab, Mattermost, Zulip, etc., je vous encourage à entourer vos extraits avec des balises ```. Par exemple :

De même, pour les citations de texte en prose, utilisez les caractères > au début de chaque ligne, comme illustré ci-dessous :

> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse justo neque, facilisis ut commodo in, auctor at tellus. Morbi non mattis risus. In vehicula risus felis, ac ullamcorper magna consequat et.
> Sed finibus, lorem a rutrum pulvinar, magna urna rutrum tortor, eget faucibus dolor enim sit amet lacus. Nulla pulvinar ligula eu leo rhoncus faucibus.

Ce qui produira :

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse justo neque, facilisis ut commodo in, auctor at tellus. Morbi non mattis risus. In vehicula risus felis, ac ullamcorper magna consequat et. Sed finibus, lorem a rutrum pulvinar, magna urna rutrum tortor, eget faucibus dolor enim sit amet lacus. Nulla pulvinar ligula eu leo rhoncus faucibus.

Ces deux recommandations permettent d'améliorer le confort de lecture de vos messages.

Voir aussi je préfère recevoir les extraits de vos textes au format texte plutôt que sous forme de captures d'écran.