Looking for co-maintainers #407

Activity

1. caarlos0

   pinned this issue on Feb 3, 2026
2. ethanjameslong1 commented on Feb 5, 2026

   

   ethanjameslong1

   on Feb 5, 2026

   Last edited by ethanjameslong1

   More actions

   I just finished looking over all the source code, I'm super interested in helping out. I'm working on issue #406 right now, I figured I should first figure out if implementing this is something you'd actually want. I think it'd involve another option be added and reworking of the getOr function which wouldn't be hard but probably messy. You can reach me on email, ethanjameslong1 at gmail dot com
   edit: fixed email.. a habit I need to get into

   ❤️React with ❤️1Reacted by Carlos Alexandro Becker
3. caarlos0 commented on Feb 10, 2026

   

   caarlos0

   on Feb 10, 2026

   OwnerAuthor

   More actions

   sounds good - let me know if i can help!

   carlos at becker dot software

   👍React with 👍1Reacted by Ethan Long
4. leemeo3 commented on Jul 5, 2026

   

   leemeo3

   on Jul 5, 2026

   More actions

   Hi @caarlos0, I'd like to help maintain env over time.

   I can start with small, compatibility-safe work: reproducing reported edge cases, adding focused tests, reviewing stale PRs, and helping keep behavior changes easy to evaluate. Since this is a mature library, I would be conservative with default parsing behavior and avoid broad feature changes unless there is maintainer alignment.

   A practical first step from me would be to look at #422 or #385, check overlap with the current open PRs, and either submit a narrow test-backed change or leave a concise triage summary that helps decide next steps.

   I use AI assistance during development, but I review and validate changes myself before submitting them. If you'd prefer contributors to build trust through a few small PRs before considering co-maintainer access, that works well for me.
5. SiluPanda commented on Oct 1, 2026

   

   SiluPanda

   on Oct 1, 2026

   More actions

   Hi @caarlos0, I'd be interested in helping with a small reproduction and regression-testing scope before discussing any co-maintainer permissions.

   I work on ML infrastructure and production reliability. My recent upstream contributions include Qdrant's typed-facet correctness fix and ONNX Runtime's concurrent allocator-initialization fix.

   I read that env is feature-complete. I'd therefore start by checking a reported parsing edge case against the documented behavior, recording the exact version and a minimal example, and agreeing on a focused test if there is a real regression. I would avoid changing empty-value/default semantics or adding new options without your agreement.

   I'm new to contributing here. Is the invitation still open, and would that be a useful starting point?
6. SkipGip commented on Oct 27, 2026

   

   SkipGip

   on Oct 27, 2026

   Last edited by SkipGip

   More actions

   Hi @caarlos0,

   I'd like to help co-maintain env with a conservative bias: reproduce edge cases, land test-backed fixes, and help triage/review stale PRs without changing default empty/default semantics unless you agree.

   I'm @SkipGip (OpenAI Codex for OSS). I use Cursor cloud agents for focused work and review everything before submitting.

   Greeting PR: #453 for #398 (native map[string][]string with separators).

   Happy to start from small PRs and earn trust before any write access. If another volunteer already owns nearby work, I'll stay clear of #440-related threads.