Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request for maintainer status #77

Closed
movermeyer opened this issue Nov 15, 2022 · 3 comments
Closed

Request for maintainer status #77

movermeyer opened this issue Nov 15, 2022 · 3 comments

Comments

@movermeyer
Copy link

movermeyer commented Nov 15, 2022

Hello @iain,

I'm requesting that I be granted "maintainer" status over http_accept_language.

I'm hoping to exercise more control over the codebase than I feel I can as an outside contributor.

As part of my full-time work at Shopify, I develop and maintain i18n libraries within the Ruby/Rails ecosystem.

For example, I am the maintainer of ruby-i18n/ruby-cldr, and am currently the #7 contributor to ruby-i18n/i18n. I've also contributed minor fixes to rails-i18n and Rails itself. I also maintain shopify-i18n, Shopify's (currently internal) i18n/l10n library.

Of course, I would continue to accept and appreciate any collaboration from you, and will treat your previous contributions with respect.

I'm hoping that you'll allow me this control over the project, or at the very least, start a discussion around how I can gain such control over time.

The rest of this issue gives some more details about who I am, and what I hope to do with more control over the future of http_accept_language.


My vision for http_accept_language

I want http_accept_language to be a solid foundational library upon the Ruby/Rails ecosystem can depend to provide easy and accurate locale resolution.

Note that I do not wish to expand the scope of http_accept_language.

Some examples of changes I want to make

http_accept_language-specific changes:

  • Fix Does not work with traditonal vs simplified Chinese #55, so that http_accept_language can be used correctly with Chinese locales
  • [Long term] Transfer the repo to the ruby-i18n organization (i.e., ruby-i18n/http_accept_language) to ensure that it has more consistent maintenance going forward.

General repos changes:

  • Add GitHub PR and Issue templates
  • Add a CHANGELOG and LICENSE file
  • Introduce RuboCop to CI, and fix all linting issues
  • Change the default branch from master to main
  • Migrate from TravisCI to GitHub Actions, and test against all versions of Ruby
  • Add a CONTRIBUTING guide

My open source CV

I'm not new to the world of open-source maintainership. Beyond those already mentioned, I'm a maintainer/contributor of several well-used libraries in other ecosystems, including:

  • ciso8601 a foundational Python library for parsing ISO 8601 timestamps quickly.
    • It's in the top-1000 most downloaded Python libraries 📈

I also regularly contribute bug reports and bug fixes to all FOSS software I use.

Beyond that, I've been working as a Software Developer for 12 years now. For the past 4, I've been working on i18n systems at Shopify.

My open source values

  • Users should have extreme confidence when upgrading:
    • Maintain backwards compatibility.
      • Breaking changes should be avoided whenever possible.
      • If necessary, should only happen alongside major version bumps, and should have trivial, (preferably automatable) migration paths
    • Keep libraries small in scope, and provide strong invariants that users can always rely on going into the future
    • Follow [the spirit of] SemVer and Keep a Changelog
  • Document and support the path to contribution
  • Prefer permissive FOSS licenses, but any FOSS license is 👌 (http_accept_language is MIT 👍)
    • I include this to express my commitment to "open source", which doesn't include licenses with restrictions on who can use the code

What I'm asking for

  • To be added as a "Collaborator" on iain/http_accept_language
  • Eventually (when you're comfortable):
    • To have you transfer iain/http_accept_language to the ruby-i18n GitHub organization (i.e., ruby-i18n/http_accept_language)
    • To have you give me whatever keys are needed to be able to publish a new version to RubyGems

I'm hoping that you'll allow me this control over the project, or at the very least, start a discussion around how I can gain such control over time.

@DouweM
Copy link
Collaborator

DouweM commented Nov 15, 2022

@movermeyer Thanks for stepping up, I'm supportive! I took over maintenance from @iain in 2012, but lost interest and project access in 2017. I've been saddened by the lack of activity since, but as I'm not longer working with Rails I wasn't able to change that either. I don't know if @iain still watches this project (I don't think he did during the few years I was involved). The best way to reach him may be over Twitter: https://twitter.com/iain_nl.

@roelandmoors
Copy link

If there is no response, maybe start a fork at ruby-i18n for now?

@movermeyer
Copy link
Author

After no response, I'm rescinding this offer. I've moved on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants