Hi list!
There's a huge backlog of pull requests on Github. Currently around 300 requests are open, some of them have been waiting for more than half a year. Most of them contain bugfixes or useful additions/new features, and judging by the comments, many have even been reviewed and tested by other users.
What is the reason for the long delays? Lack of manpower perhaps? Is there anything that can be done to speed things up?
Kind regards, Marc Schütz
Hi list!
There's a huge backlog of pull requests on Github. Currently around 300 requests are open, some of them have been waiting for more than half a year. Most of them contain bugfixes or useful additions/new features, and judging by the comments, many have even been reviewed and tested by other users.
What is the reason for the long delays? Lack of manpower perhaps? Is there anything that can be done to speed things up?
Working in pull requests/issues takes time, as a core team member you cannot just read the comments and blindly apply even if the feedback is positive.
In the end, what goes in is your entire responsability, so you need to grab all the context, ofter consider the change from a broader project-level perspective (which normally involves some research), and apply, or reply with feedback, or whatever, in consequence.
Most of us work on Rails in our spare time. I am a freelancer and bill **less** in order to be able to save some time for open source (which is a lifestyle choice). But there is not enough bandwidth.
That said, triaging is the best you can help with. Because the feedback, either positive or negative, certainly helps a lot in building some context you can take as a starting point in your evaluation. Months ago the number of open issues was more than twice the current count, and the recent push by some active community members has dramatically helped in halving that number.
There's also lag time between feedback being given and it actually being implemented, as well. Sometimes pull requests can go back and forth for a long time because it takes a week to get a change, then another week for feedback, then another week for a change...
Take the oldest pull, for example: Add possibility to render partial from subfolder with inheritance by aratak · Pull Request #2045 · rails/rails · GitHub
It was started two years ago, but it's a big new feature, and some of the commits were rebased as newly as a month ago.
Big projects take time, sometimes.
Thanks for the responses so far. This certainly wasn't meant to criticize the people who work on Rails and put in a lot of their free time.
It's just that, quite obviously, for whatever reasons, the Rails team isn't able to keep up with the large number of pull requests (and bug reports anyway). It seems Andrew Vit also talked about this about a month ago, which I hadn't seen before I posted.
It was suggested in Andrew's thread and in this one to triage bugs and help reviewing. However, while this might be useful, I don't think lack of reviewing is the real problem.
I took a closer look at the open PR's on page 4 (i.e. to avoid the really new ones). Of these, there are:
New features: 5 Refactoring: 7 Bug fixes: 11 Documentation: 2 Total: 25
With votes from the community: 2 With comm. feedback/suggestions: 8 Open questions for submitter/WIP: 6 Feedback from core team: 12
This means that for most PRs, there has already been some kind of review/feedback from either the community or the core team (i.e. those that I think are members). "Open questions/WIP" are those where the submitter still needs to do something. There are some others with open questions, but these are waiting for feedback from the core team. Many of the PR's end with someone requesting a specific team members opinion, after which nothing happens.
So... I'd like to ask again, what can be done? Give more people commit access? Funding for some core team members to be able to dedicate more time to Rails development? Maybe a better way to prioritize PR's, as Andrew suggested? Make it easier to decide which features are desired? Other options?
I don’t think we need to do something. If you look at projects with same size of Rails or closer you will see we are very active.
We just released a major feature and, well, I think we deserve some kind of rest. When we need to work you will see that issue page decreasing like crazy.
Funding for some core team members to be able to dedicate more time to Rails development?
That can only help.
Maybe you can get together a local bug fixing support group that meets once every other week and pairs on existing open issues. Active record should be a ripe target.
If you want to pay someone to work on Rails full time, just start doing it. Find a company that will hire a full time open source-er (maybe you) and have them work with pull requests and issues. In time if their work is valuable they will be given commit access. If not, don’t continue to pay them.
If you want to be on rails core then start acting like you’re in rails core. Fix bugs, comment on pull requests, submit docs, and develop a rapport with the core team.
Another option is to reach out to those with commit who freelance. Maybe you can hire them at their rate to work more on Rails.
The key here is to try things today. If they work out then tell everyone about your successes and maybe they can be repeated. If not, keep trying till you find something that does.
Raphael is correct. The team is coming off of a major release and the issues will get better. It still doesn’t stop you from making an effort today.
I can only agree with my previous speakers. While there are a lot of issues, the team is very active. The easy issues are mostly resolved within days and the harder ones of course stay longer. Important issues are usually identified and dealt with priority.
I think everyone who wants to help the project can find his way into it. I found that many people in the core team are willing to answer questions and help people to get up to speed. When I started I went through the issues many times and there is a lot you can do to get them resolved.
If you have money to spend on Rails development that’s great! I’m sure you will find work to do or someone who is willing to work on Rails.
One last point I'd like to make is that 'just giving more people commit' isn't going to work out. Merging bad pull requests just to get the numbers down isn't going to help. It would just add more work to clean up any messes.
The only way to get more committers is for more people to do more work, and then they'll be given commit when they deserve it. Senny and myself are two examples from the past year.
I spent some time today reviewing, rebasing, and fixing pull requests. https://github.com/rails/rails/pulls/Empact
I’m starting with the oldest open PRs and working forward. Focusing on ActiveRecord PRs, as I <3 SQL / AR.
Is this appreciated? Is there anything you would change about? Let me know.
-Ben
Hi Ben,
I spent some time today reviewing, rebasing, and fixing pull requests. Pull requests · rails/rails · GitHub
I'm starting with the oldest open PRs and working forward. Focusing on ActiveRecord PRs, as I <3 SQL / AR.
If I don't like what I see, I'll comment If the change looks good I'll +1
Thats nice 
It helps a lot to revive issues.
If it looks like it may have merit but needs improvement or updating, I'll try to improve it and open a new pull request.
I think the policy is to wait for the original implementor to improve and update, after providing feedback. Unless they dont respond a new PR won't be considered.