Ping the creator of a new repo

[bfabio]

https://github.com/italia/.github/blob/main/scripts/check-repo-changes.rb checks for new repos in /italia and /teamdigitale and creates issues as reminders to consider adding them to this awesome list.

The problem is we end up with a lot of those issues to handle centrally.
We should ping the creator of the repo in the issue text, inviting them to consider adding / removing the created / renamed repo to the README, because they're the ones knowing the scope / reason / future of the repo the most.

[astagi]

@bfabio I entirely rewrote the core system using Python, is long way more maintainable for us ☺️

Now new repository are auto-added to the profile/README.md as long as they're correctly labeled with their parent group.

I'll write some documentation about the new flow, I promise. For now we can close this issue.

[bfabio]

Ciao @astagi, se migliora la facilità di manutenzione ben venga la riscrittura!

L'idea di Awesome Italia è sempre stata di avere una vetrina che aggiunga valore alla semplice lista di repository delle due organizzazioni (italia e teamdigitale). Una sorta di landing page con contenuto selezionato e organizzato, che contestualizza i repo dal punto di vista esterno.

Con questo nuovo metodo ci sono alcune criticità:

1. Si perdono le issue aperte in automatico quando viene creato un repository nuovo

Queste, per intenderci.

Sono molto utili per chi vuole tenere d’occhio le org e a chi interessa ricevere notifiche appena viene creato un repository (basta attivare le notifiche di GitHub). Questo vale sia per gli esterni che vogliono curiosare, sia per gli admin che hanno sott'occhio cosa viene creato.

Inoltre tengono traccia delle decisioni di inserirli o meno nel README.md e di chi ne è responsabile, proprio tramite l'idea di questa issue - farlo decidere a chi crea il repository (ne scrivo più nel dettaglio sotto)

2. stale_repos.md come file nel repository

Probabilmente è un'errore nella action che non ripulisce questo file temporaneo.
La lista dei repository stale è nella issue #257 ed è ancora aggiornata. Concettualmente è una issue perché è pensata per essere actionable e come una lista di todo di repo da controllare e archiviare, quindi idealmente dovrebbe essere vuota a lavoro finito.

Esempio: un repo come https://github.com/teamdigitale/spid-sp-playbook (il primo della lista), non aggiornato da 8 anni, è da archiviare senza tante cerimonie, ma in generale buona parte di quella lista è archiviabile, cosìcché diventi sempre più piccola.

Alcuni repository è normale che non siano trafficati, anche se ancora in uso (ad esempio cose come https://github.com/italia/unisciti.developers.italia.it, che è un redirect attivo). Per quelli è utile usare l'opzione EXEMPT_REPOS dell'action stale-repos per escluderli.

Non è tanto l'avere una lista di repository stale l'obbiettivo, ma archiviare i repository obsoleti. Avere repository vecchi e abbandonati è spiazzante e scoraggiante per gli esterni

3. L'aggiunta automatica basata sui topic di GitHub

Da come mi sembra di capire ora la descrizione del repository viene presa dal repository stesso, questo però porta diversi nuovi inconvenienti:

• C'è una sola lingua, quindi rende impossibile il risolvere questa altra issue: Have both the English and Italian versions #259
• Il contesto della descrizione del repo è diverso dal contesto del README di Awesome Italia. Quello del repo può essere più tecnico e dare per scontato (giustamente) i concetti e tecnologie, mentre nel README di Awesome Italia il punto di vista è più verso persone che non conoscono (ancora?) i dettagli o l'architettura.
• Essendo scritte da persone diverse senza un vero coordinamento (i maintainer dei repo / fornitori), queste descrizioni tendono a essere disuniformi, o in lingue diverse, o con termini diversi, anche per repository sovrapponibili. Ad esempio i siti web (Sorgente di..., Sito web..., Sito di..., Sorgente del sito di...)
• Vedo che si è persa la descrizione delle sezioni. Quello che è ovvio all'interno non è ovvio da fuori: cosa sia SPID non tutti lo sanno (mi vengono in mente persone dagli altri stati membri, ad esempio) e una breve panoramica è sempre utile.

Ma la cosa più importante, ritornando su questa stessa issue, è che uno o due maintainer di Awesome Italia non scalano per gestire questa lista di repo curata. C'è bisogno della responsabilizzazione di chi crea nuovi repository.

L'idea del pingare il creatore dei nuovi repository, tramite le issue del punto 1, è proprio per automatizzare la decisione di inserire il nuovo repository o meno nella lista, chiedendo alla persona che più è a conoscenza del motivi della creazione del nuovo repo.

Sarà un repo importante da mostrare all'esterno? È tooling interno molto specifico? È un repo temporaneo? È un repo ora vuoto, ma che poi verrà riempito dal fornitore? È un repo vuoto, che però non si sa quando verrà popolato?

Queste sono tutte domande che determinano se metterlo nella vetrina di Awesome Italia e, appunto, chi crea il repository è in grado di rispondere.

Nel flusso del ping al creatore, il creatore stesso chiude l'issue (con una delle label già presenti, per indicare il motivo) o la risolve aggiungendo il repo al README, in due lingue, e mantenendo la consistenza delle descrizioni.
Che ha un ulteriore vantaggio: quando ci sarà il dubbio se archiviare o togliere il repo dalla lista dopo anni di inattività, si sa chi contattare perché sulla issue c'è la history della decisione e di chi l'ha presa. Si può addirittura automatizzare tramite il bot degli stale-repos che pinga a sua volta il creator dicendo sulla issue "Ehi (@)creator, questo repo che hai aggiunto due anni fa non ha più modifiche, forse è bene che lo togli dalla lista e lo archivi? Oppure pinga chi di dovere per farlo per te"

Penso che senza una gestione un po' più distribuita (anche il dire a voce ai maintainer di mettere i tag e poi fare policing in modo non tracciato grava sulle poche persone che devono mantenere Awesome Italia) l'unico risultato possibile sarà avere una lista poco utile e poco awesome.

IMO l'obbiettivo è avere una lista con curatela e una mappa che dà una panoramica capibile da gli esseri umani, non un duplicato della lista dei repository di GitHub.

Riapro la issue se sei d'accordo.