Why

Despite having never publicized this library anywhere myself, over the years people found it, used it, and contributed to it. I'm honored and grateful to everyone who supported the project.

That said, I no longer actively write Go. I still write occasional small script, but it's been a long time since I wrote anything serious production-level, and I'm not fit to maintain the quality this library deserves or capture the needs of people actually using it today.

I'm truly sorry for the years of neglect. The people who took time to file issues and send PRs deserved much better turnaround than I gave them.

What

I'd like to hand this project to a new maintainer who actively writes Go and is willing to steward the library going forward.

No prior involvement is required, though existing contributors and commenters are especially welcome.

If you're interested, please comment with a short note about your Go and OSS-maintenance background, and whether you'd prefer to take this on solo or as part of a small team. I'm open to adding co-maintainers or transferring the repo altogether.

Design principles (for reference)

Thought I'd share how I've been thinking about this library, as a reference point for whoever takes over.

• Keep it simple: The scope is narrow by design. For example:
  • Adding validation (Add require field tag  #36) feels out-of-scope to me and I wouldn't recommend going there.
  • Unset (Unset() #42, PR feat(unset): support unset value to zero. (#42) #44) is an interesting idea, but I'm not sure it's worth the added complexity as-is, nor whether there's defensive real-world use-cases. If someone wanted to pursue it, I'd probably create an internal function with an argument "operation mode" (set/unset) that use the shared data traversal/parsing logic with different mode of operations, so that Set and Unset are guaranteed to work as a proper pair.
• Stay comprehensive: I believe that high test coverage and broad type support are core to what makes this library trustworthy.
  • However, how the current tests are written and structured is terrible to be honest. A shared big-fat data struct, and not using a proper testing library. Migrating to something like stretchr/testify and create chunks of a locally-defined struct would be a meaningful improvement. -- Refactoring per se wouldn't take time (let the agents do it), but I'd review currently opening PRs before doing so.

Surely, once you take over, the decisions are yours; Adapt as you see fit.