Cleaning up Ransack

[scarroll32]

This is an open post to the Ransack community about the direction of the gem.

I volunteered to be maintainer on Ransack as it is an essential part of the Rails ecosystem. It is an extremely useful gem for any Rails app and it also a key plank in the newly revived ActiveAdmin.

For more responsive searching against large sets of mixed data, I have begin to move to Elasticsearch, and recommend the fantastic Searchkick gem to anyone considering this. That being said, Ransack will always be important, as many Rails apps won't have the sort of data to warrant ElasticSearch.

As of this writing there are currently 102 open issues and 15 open pull requests against the repo. All the pull requests are failing CI. Some of these could be easily fixed, and are due to gem incompatibilities etc.

I think the bigger issue with Ransack is that it has grown in response to individual issues, and it is trying to do too many things. It feels like we are chasing a never-ending set of edge cases.

The other problem is many issues are actually requests for help rather than issues with the gem. Despite what it says on the README, many issues are also "how to" requests that could be better handled on Stack Overflow.

I'm reaching out to the community for suggestions on direction, and volunteers to help get Ransack back on track. The work done on ActiveAdmin to bring it up to date is inspiring.

IMHO

IMHO I believe Ransack is already has most of the features that is needs, and work should focus on stabilising the code, cleaning up and closing all issues and merging or closing all pull requests. Jon Atack did an incredible job of managing the many pull requests and closing issues in past. I'm happy to manage the pull requests but they need to pass tests but also be a part of a core features list.

Let's do this:

• Update the README to clearly describe the Ransack philosophy and core features
• Extract useful HOW-TOs from closed issues and publish them in the Wiki
• Get the build passing again
• Merge or close all pull requests
• Close all issues

I'm looking for agreement from the community on this approach, and assistance on the cleanup.

Thoughts?

[jonatack]

Thanks @seanfcarroll. I agree with your direction. Keeping the code up to date with the build passing on the various Rubies and Rails versions is the main thing. Personally I still use Ruby for work and contribute as a Ruby Together developer member (I encourage everyone to join https://rubytogether.org/members), but as long as DHH is still involved in the Rails ecosystem then I don't plan to be. Thanks for your work on Ransack.

[ernie]

Hey @seanfcarroll. I'm coming out of "hiding" today to say an emphatic yes, especially to the first point, updating the README. There was a philosophy and intended problem space in my head when I created the gem and initially managed it. Unfortunately a lot of that stayed in my head rather than being written out, and I instead focused the README on useful examples and such. I see that for the most part, that tradition has continued in the README, but over time I've had a look at issues, PRs, and code that's made it into the release and it's clear that things have gone a bit off the (ahem) Rails.

I do apologize for not setting a stronger direction for the gem before I turned it over. Unfortunately, by the time I let go, I was utterly burned out from the process of working on it and its predecessor for almost 4 years, and by that point, as you probably know, even the simplest undertaking can feel monumentally difficult. :(

All of this is to say that I absolutely feel your pain, and I fully support buttoning down the gem's documentation with core philosophy, use cases, and (more importantly) anti-use cases, and aggressively closing issues and PRs that stray from this.

The primary challenge, and one that's enough for any developer to deal with, is tracking Rails's frequent breaking changes in a way that is even remotely elegant while allowing support across versions. Ransack was pretty much feature-complete for its intended use cases long before I turned it over for new maintainership. Adding many kinds of features can increase the burden of maintainership far more than it might for a gem that isn't attempting to track through 3 major versions of ActiveRecord and (inexplicably) a version of Mongoid.

Thanks.

[scarroll32]

I think that's a great point about tracking versions. Some of the recent pull requests, e.g. are breaking on Ruby 2 which is de-supported. Even Rails 3 will be dropped at some point.

As for Mongoid, I guess I see the point but I wonder if anyone is actually using it.

I will start extracting HOW-TOs out of old issues and put them in the Wiki. The README can be reworked and a lot pushed into the WIki also.

@ernie You certainly don't need to apologise: a gem like this is a massive amount of work, and I really believe it is a key part of the Rails ecosystem. If you have any time, could you author some articles in the Wiki, with any brain dump or ideas for direction?

@jonatack Rubytogether is a great idea. We use Rails heavily at work, and I'll put it to the boss that we should subscribe. I'm not close enough to core Rails to understand the DHH comment, but it's not the first time I've heard it. You made an amazing amount of contributions to Ransack in 2014-16, thank you, and also for updating the demo.

I wouldn't have any issue with having a small banner pointing to Rubytogether in the header of the README.

[scarroll32]

Closed