Should the installer be more Omakase?

[gmarziou]

I find that the InstallGenerator at v0.5.11 asks too many questions.

For newcomers, it could be overwhelming and this reflects also in documentation.

I know that your approach is to have opt-ins but I think RED should be more opinionated and ask less questions while still retaining settings in initializer.

There are 4 groups of options:

• Notification options: these are valid questions and easy to answer
• Performance options:
  • async_logging, :async should probably be the default choice because it does not impact main data flow and does not require additional infrastructure. Not sure why people would want to set false. Question could be removed.
  • error_sampling, not easy to decide initially,
  • separate database, major choice, required for installing migrations
  • database name, question could be removed and manually configured afterwards
• Advanced analytics options: not easy to answer for newcomers, I think these 7 questions should be skipped and opinionated choices should be done, manual settings can be implemented in initializer.
• Developer tools options

For each option, it's not always easy to assess what is the drawback of enabling them, is it a performance penalty upon each web request or only when an error is logged, is it only at review time later on in dashboard or as a daily background job (when?)?

Could some questions be turned into editable settings from dashboard, maybe saved in a table?

Also, some settings have more implications than others, in particular breadcrumbs enable a lot of features that cannot be easily understood from a single question. Maybe there should be a link to documentation below the question to help answering.

[AnjanJ]

Hey @gmarziou — thank you for taking the time to write this up so clearly. You're right, and "omakase" is exactly the word for what the installer should be.

A few specific things you raised that I'm going to act on:

async_logging defaulting to false is a mistake. The :async adapter is Rails' built-in ActiveJob async adapter — no Sidekiq, no SolidQueue, nothing to install. There's almost no reason a user would want synchronous inline logging as the default. Flipping this to true is a straightforward fix.

The 7 advanced analytics questions should go away. You're correct that these are the hardest questions to answer before you've seen a single error. They also all run at query time in the dashboard or as background jobs — zero overhead on normal requests. The right default is ON, and users who want to disable them can edit the initializer.

The cost context is missing. Your point about "is it a performance penalty on every request or only when an error is logged?" is the sharpest observation here. The descriptions in the current installer don't make this clear. I'm going to add a cost label to each feature — [request-path overhead], [error-time only], or [background/dashboard only] — so the tradeoff is legible before you answer.

Breadcrumbs needs a better description. Enabling it activates 6 different ActiveSupport::Notifications subscribers — SQL, cache, jobs, mailers, Rack::Attack, ActionCable. The one-liner completely hides that scope. I'll expand the description and add a doc link.

Dashboard-editable settings is something I've thought about — storing runtime config (retention days, thresholds, sampling rate) in a DB table so you can change it without a deploy. It's a more involved change but the use case is real, especially for teams where non-engineers need to adjust settings. Tracking this as a future milestone.

What the new installer will look like: I'm planning to reduce it down to essentially two questions — which notifications do you want, and which database mode? Everything else ships with an opinionated default. There'll also be a --quick flag for zero-prompt installs that gets you to a working dashboard in under a minute.

Does this action plan sound right to you? I'd love to know if there's anything I've missed or any part of the install flow that still feels off. If you've run the installer recently and hit friction beyond what's described here, that context would be really useful.

Appreciate you taking the time — this kind of feedback is exactly what makes the gem better.

[gmarziou]

Thanks @AnjanJ your plan is perfect, it addresses all my points in a clever way.

Thanks a lot for RED, it's a nice project.