kennethreitz/records

Would `records` benefit from a backup maintainer

vlcinsky opened this issue · 2 comments

vlcinsky commented

Similarly to tablib (see kennethreitz/tablib#329) records project could benefit from additional maintainer.

Facts:

  • @kennethreitz is Development lead (184 commits)
  • apart from that, nobody seems to be assigned as a maintainer
  • commits:
  • Issues: 47 closed, 34 open
    • 17 open issues younger than 12 month
  • pull requests: 56 closed, 6 open
    • all are fresh (created by me)
    • last merged ones are from February (relatively not long time ago)
  • last version 0.5.2 is from September 2017
  • git repo has 4246 stars (versus 2917 at tablib). I do not have numbers from pypinfo (run out of free tier today)

To summarize:

  • clear interest from users as well as from contributors
  • development (resolving issues and accepting PRs) goes relatively well
  • the biggest risk is, the project probably relies on only one (bright) person.

Proposal for next actions:

  • @kennethreitz would you consider assigning backup maintainer or propose another option to make your great records playing well in long term?
Tethik commented

I agree that having more maintainers would be helpful. I noticed that it takes long to push new versions and resolved issues go unclosed.

While I'm not super into the specifics, there seems to also be the issue around connection pooling #131 which I believe could use some feature push. Without it I think the library is not that useful on it's own, and most developers end up going back to sqlalchemy. Having another maintainer might also help write these types of new features.

vlcinsky commented

@kennethreitz allowed me to manage pull requests (thanks).

We shall see how I will manage (some PRs are already merged) and how we manage publishing new versions into pypi.

For this reason I will keep the issue open and possibly close that at the moment, next version appears on pypi.

  • 👍7
  • 🎉6