Misc #15487


Clarify default gems maintanance policy

Added by zverok (Victor Shepelev) over 2 years ago. Updated over 2 years ago.



In addition to #15486, I'd like to raise the question of the general maintanance policy for "default" Ruby gems, in particular:

  • who is responsible for each gem and how they should be contacted?
  • what are goals and policies for gems code quality and documentation?
  • where do default gems are discussed?
  • what are some promises/guarantees default gems maintainers try to fulfill?

The most demonstrative example I'd like to point is json gem:

  • The source at ruby/json is NOT authoritative as far as I can tell, the authoritative one is flori/json
  • The gem still holds signs of the times it was independent (Pure and Ext JSON implementations, but Pure is not copied into the ruby/lib on releases, rendering standard docs pretty weird), and has NO mention it is THE json gem of Ruby
  • The gem seems unmaintained, considering the amount of PRs and issues, lot of them without any reaction for months
  • When I tried to update JSON docs, in core tracker issue I was asked to make a PR to "upstream repository", but there, the PRs (#347, #349) was simply ignored; Ruby 2.6 was released without new docs, despite the fact PRs were made at March and require almost no code review (unlike even some promising optimization PRs, that were also hanging there since Feb/Mar)

It is just one unfortunate case (TBH, my experience with contributing to other libraries, like csv and psych was much smoother), but it demonstrates some common lack of transparency in maintaining of Ruby's standard library


Also available in: Atom PDF