preplace

2025-12-08 13:15

Ok, te lo dico senza giri di parole: apparire in TLDR o in altre newsletter tech non è difficile, ma non succede da solo. Devi muoverti in modo mirato, pratico e credibile. E soprattutto nessuno ti recensisce il codice “per favore”: devi rendere la cosa facile e appetibile per chi cura quelle newsletter.

Ecco il percorso concreto:

⸻

1. Prepara il progetto a essere presentabile

Se mandi in giro un repo “mezzo fatto”, non ti considera nessuno.

Checklist minima:
• README impeccabile: cosa fa, a chi serve, come si installa, esempi rapidi.
• Screenshot o GIF (indispensabili).
• Link a demo live, se possibile.
• Versione tagged (v0.1, v1.0, ecc.)
• LICENSE chiara (MIT/GPL/Apache).
• Issue introduttive tipo “good first issue”.
• Changelog.

Se vuoi essere preso sul serio, questa parte non la salti.

⸻

2. Prepara un pitch breve

Le newsletter non vogliono romanzi. Vogliono 2–4 righe chiarissime.
Scrivi:
• Cosa fa il progetto.
• Perché è diverso.
• Perché può interessare ai loro lettori.
• Link diretto al repo.

Esempio:

OpenAPI gateway-as-a-graph. Minimal, Kubernetes-native, zero boilerplate. Disegni il grafo, parte la microservice pipeline. Repo: …

⸻

3. Come apparire su TLDR

TLDR ha una procedura non ufficiale ma funzionante:

✔ Metodo 1: Submission diretta

Scrivi a: tips@tldr.tech
Ogni giorno ricevono parecchie segnalazioni — essere chiari e concisi fa la differenza.

✔ Metodo 2: Twitter/X

Tagga @tldrnewsletter presentando la release.

✔ Metodo 3: Pull Request

A volte accettano progetti via PR nel repository open delle segnalazioni (dipende dal periodo).
Serve un pitch ancora più conciso.

⸻

4. Altre newsletter e come contattarle

Te ne metto alcune già “agganciabili”:

📌 Hacker Newsletter

Mandano sempre progetti nuovi.
→ email: submit@hackernewsletter.com

📌 Console.dev (ottima per dev tools)

→ https://console.dev/submit/
Richiedono un form con pitch + screenshot.

📌 Bytes.dev

Accettano link inviati via form: https://bytes.dev/submit

📌 Javascript Weekly / Go Weekly / This Week in Rust / etc.

Ogni settore ha la sua newsletter. Tutte hanno una sezione “Submit link”.

⸻

5. Ottenere una “code review” vera

Nessuno fa una review completa gratis… a meno che non gli convenga.

Metodo pratico:

❗ Apri una issue pubblica chiamata Request for external code review

E scrivi:
• cosa vuoi che venga revisionato
• criteri (architettura, performance, sicurezza)
• tag con “help wanted”

Poi:

✔ Pubblicala su Reddit

Sottoreddit specifici:
• r/Programming
• r/cpp, r/golang, r/rust (dipende dal linguaggio)
• r/codereview (questo è perfetto)

Il segreto: non chiedere “mi dite se il codice è bello?”
Chiedi: “Sto costruendo X per Y. Vorrei feedback su architettura e scelte tecniche”.

⸻

6. Spingere il repo nei posti giusti

Se vuoi visibilità vera, fai questo:

✔ 1. Submit su Hacker News (“Show HN: …”)

Se il titolo è buono, prendi più visibilità di TLDR.

✔ 2. Post su X, LinkedIn e Mastodon

Ogni community tech importante pesca da lì.

✔ 3. Product Hunt (solo se il progetto è usabile)

Se è troppo early, lascia perdere.

✔ 4. Dev.to

Articolo di 3 minuti su cosa hai costruito.

⸻

7. Vuoi che ti prepari io il pitch?

Se mi dici:
• nome del progetto
• cosa fa
• perché è unico

ti preparo un pitch pronto per TLDR, Console.dev e ShowHN, più un README ottimizzato per colpire.

Dimmi pure.