Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Suggestions

Offen
  • Stimmt etwas nicht?
#52 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Dokumentation
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
go
Bereich
documentation

Rechercherichtung

Beginne mit der Durchsicht des Repository-README und des verlinkten Abschnitts zur Fehler-Migration in docs/RFCS/20190318_error_handling.md und untersuche anschließend, wie exthttp und extgrpc derzeit dargestellt werden. Das Issue enthält viele separate Vorschläge, daher sollte zunächst eine einzelne abgestimmte Dokumentationsänderung identifiziert werden. Erledigt ist die Aufgabe, wenn eine fokussierte Aktualisierung mit Beispielen oder Links vorliegt, die zum gewählten Umfang passen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

For @knz

I was looking through the docs trying to find out how to register a migrated error, and it took me a little bit. So I wanted to suggest how to make that more visible, and then I thought while I'm at it, a couple more suggestions:

  • First, the docs on migrating/renaming an error are a little buried and could perhaps be linked in the README. You talk about forward compatibility in the README, which I understand in part to involve forwarding errors through unaware intermediaries but from the name it sounds like error migration is part of it, so I was surprised how much I had to dig to re-find this data.
  • RegisterTypeMigration could perhaps be part of the "forwarded methods" so it shows up in the main package, looks like I currently need to import errbase to get at it.
  • The README could use a sample of the ultra-awesome stack trace format!
  • The compatibility table is a bit intense to be at the top of the README. I remember back when I first came across this package, it was a little confusing—my takeaway was, "wow, this thing has lots of features I guess". I feel like you might be better served by having the top of the README dedicated to a simple bullet-point list of features and some code samples showing what it looks like in practice.
  • Could have a godoc badge up at the top of the README: Godoc
  • Perhaps rethink how the data on custom errors is provided. The information is pretty dense and unstructured; I would suggest more subheadings for specific tasks like "Custom Leaf", "Custom Wrapper", "Over the Network", or some such. Also perhaps consider putting the writeup in its own document because there's a lot to the subject and it can be overwhelming to someone landing on the main page of the repo.
  • This is subjective, but I think in general the README could express more through code samples:
    • The section on Available Error Leaves could show little fake error scenarios, using that applicable function, and then retrieving the data, with additional details in comments.
    • The section How to Use could perhaps be shown in code.
  • I question the necessity of API (not constructing error objects), since Godoc is probably better suited for this anyway.
  • I don't think the exthttp package is mentioned as a useful tool, more as an example for when you're building your own error types, but I think it adds value. Also extgrpc isn't mentioned, although that one's entirely my fault because I never added docs for the work I did 😉
  • I feel like the project deserves a cool logo! (😄 ) Maybe a variation of the cockroachdb logo?

I'm aware that I'm armchair-quarterbacking and should probably put a PR where my mouth is, but I'm in the middle of other things and just felt compelled to jot down some notes. Interested to hear your thoughts!

Vorherrschende Sprache
Go
Sterne
2.5k
Forks
75
Ø Merge
2 Std. 5 Min.
Gemergte PRs (30 T.)
1

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cockroachdb/errors

Alle Issues in cockroachdb/errors

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.