Issue triage & process

There are currently hundreds of open issues & pull requests.

The "Contributing to Rails" guide is great, but it feels like too many tickets sit a long time without being looked at.

I'd like to ask if there's a process somewhere that the core team follows for triaging, reviewing & prioritizing issues? As a community member, what can I do to help? Is there room for improvement to get fixes organized & moved through the pipeline?

As an example, I submitted a while back: https://github.com/rails/arel/pull/165

This has happened with a few issues before, and it gets discouraging. What could I (or we) do better?

Andrew Vit

I personally read each and every single comment, pull request, and issue.

That said, I can't always help, so when I can't, I don't say anything.

There isn't really a process, as almost nobody is actually paid to work on Rails. People do the work when they feel like it and however much they feel like it, and everyone has their own process.

That said, of course, we do make sure that there aren't known regressions in releases, things like that.

As a community member, what can I do to help?

Ask for reproductions on issues that don't have them, writing reproductions is even better. Verify that older bugs haven't gotten 'accidentally' fixed and are still an issue. Write patches for bugs that are open.

I encourage people to volunteer to look at tickets. Get one a day in your inbox:

If you want people to look at your pull requests and issues the best way to start is to look over other people’s.

You are the community.

I personally read each and every single comment, pull request, and issue.

That said, I can’t always help, so when I can’t, I don’t say anything.

I just took a month to reply to my own rant here. I don’t fault anyone else in the community for the valuable time they contribute.

There isn’t really a process, as almost nobody is actually paid to

work on Rails. People do the work when they feel like it and however

much they feel like it, and everyone has their own process.

That said, of course, we do make sure that there aren’t known

regressions in releases, things like that.

“There isn’t really a process” is totally fine, but there should be a better way for us to see what’s going on.

Maybe there could be a wider role for prioritizing tickets. Reviews and +1s on issues are one thing, but how can anyone find the issues that should float to the top of the “priority list” (which seems like there is none) and get more attention from the community? Sorting through hundreds of open, untagged issues is pretty daunting.

It could even be as simple as a “focus” tag with a capped number of important items (pseudo-kanban style), rolled & reviewed periodically.

Or be more aggressive about assigning tickets to milestones, even if provisionally: currently there’s ONE open issue for 4.0.1 and 3.2.14 each, and I’m sure there are many more that should be included there.

I think more visibility into the issue list would help the community to move things along a lot better. It helps to know where to push.

As a community member, what can I do to help?

Ask for reproductions on issues that don’t have them, writing

reproductions is even better. Verify that older bugs haven’t gotten

‘accidentally’ fixed and are still an issue. Write patches for bugs

that are open.

Yup, I get it… it’s just that if I want to invest the time to pick at issues from the sidelines, I’d like to know whether I’m advancing the next item in the pipe, or if it’s just an obscure “nice to have” that’ll eventually fade away.

Cheers all, Andrew Vit