I have used and enjoyed rails for 10 years. I’ve made a few (a dozen) small documentation and code contributions over the years. Most recently I helped, in my small way, with the upgrade to tzinfo 2. But, some time in the last year, it feels like contributing has become a lot harder.
Staleness seems overused, or used for the wrong reasons. I understand the purpose of staleness, and support it, when used correctly. I just feel it’s being used more broadly than it should, particularly with PRs. For example, I have a simple docs-only PRs that’s been repeatedly marked stale for two years now. It shouldn’t take two years to reach a yes/no decision on a docs-only PR. Most likely “un-stale-ed” things are simply forgotten, and that’s understandable, but it can feel like they’re being ignored. In one case, it felt to me that staleness was being used as a way to avoid disagreement. I get it, saying “no” is hard.
Perhaps “un-stale-ing” something should result in a notification?
Perhaps more maintainers could be recruited?
When repeated “un-stale-ing” does not garner attention, maybe there could be an “appeal” process? Which brings me to …
The mailing list requires a Google account, which not everyone has.
Maybe the mailing list could be opened to non-Google users?
So, contributing has felt too hard lately, and I just … haven’t. I hope we can find a way to be welcoming to contributions once again.
I’m not sure, but doesn’t the move to https://discuss.rubyonrails.org remove the Google account requirement? I logged in with my GitHub account. This wasn’t just for “A May of WTFs”, but also replaced the “rubyonrails-core” mailing list, etc. See the categories dropdown on the top level.
Sam Saffron announced this to rubyonrails-core on March 25:
I know from talking to Core a bit that part of the problem is that Rails is a really popular project, and there’s more PRs flooding in sometimes than they can easily handle. It sounds like they would love to have people chime in more on issues, so that they can grow the maintainer pool a little and bring the PR/approval ratio back to something healthier.
They’re also going to have an easier time with small PRs, and PRs that lay out a likely migration path for things that could cause breaking changes. PRs that do that are a lot easier to understand the impact of and review, so it’s a lot easier for everyone involved to get them shipped.
Would it be possible to have something like the good first issue tag be brought back? I know I have checked that on occasion throughout the years but it seems to have fallen by the wayside.
For things like documentation issues maybe a tag indicating it needs to be checked against a given style guide or something? I have browsed the rails issue list on occasion trying to be helpful but it can be hard to know what’s needed to push a small doc change over the line. Is it waiting for a given maintainer to cast their eyes? Or is it just a matter of getting a handful of people to give it the thumbs up re. grammar and clarity and such? I can’t do the first thing but I could, and happily would, review some suggested doc changes.
What I don’t know (and can’t guess at from where I’m sitting) is if there’s a way to indicate this without actually adding to the review burden.
@tvanderpol The meta thing I’m hearing in your comment: You’d like there to be structures in place that make it easier for people to submit their first PR. You’d also like the review process for different types of PRs to be clearer, and for there to be structures within it that make it easier for non-maintainers to lift the PR review burden a little bit for the maintainers.
I think the maintainers are the best judges of which ideas will add to their review burden and which won’t, but I’ve gotten the impression that they’re very open to ideas that might make their lives easier.
I’d love it if we could brainstorm more in this thread about ways to make contributing to Rails easier and more structured, from a perspective of “lifting maintainer burden by making it easier for the community to participate healthily.”
These kinds of process conversations can get fraught fast, so I’d like to set some ground rules for that brainstorming:
We’re trying to get as many ideas out as possible. Some ideas might be terrible, but that’s totally okay. We just won’t use them.
If you think someone else’s idea is terrible, thoughtful criticism is okay. But presenting contrasting ideas is better. When we get heavily into back-and-forth about one idea, we stop generating lots of ideas.
Assume (just like we do everywhere else in this forum) that everyone participating is doing so because they care about Rails and want it to be a healthy framework with a healthy community.
Assume that if the maintainers were doing something, but aren’t now, it was because there was a reason to stop. That reason might not be present any more, but it existed then. (It’s okay to wonder or ask about what that reason was.)
Remember that the maintainers aren’t being paid to work on Rails, and that no one has infinite time or energy to work on open source!
I think that’s a fair summary. I was primarily responding to the lag in review time / issues going inactive with some admittedly nebulous thoughts on how people like me might be able to help with aspects of reviews.
As for brain storming - the only thing I’ve got to offer in terms of options is what I gestured at in my previous reply; if there were some aspects of review that could be done by folks outside of the overburdened core group then it might be possible to structure that a bit with something like the first issue tag I linked above.
For example - if there is a use to having a few people chime in to say the changes read well and are comprehensible and clear then that’s something I personally feel I could do. If this is a thing that’d actually save time and effort in the review process it might be worth pursuing.
I can’t really speak to how “it used to be” but I’ve contributed a few small changes and had a few different results. My doc contributions have been merged quickly. Years ago I submitted a fix for a bug in fixtures, but that was before some of the automation that exists now and I think I caught the ActiveRecord lead at a bad time —that PR just “staled-out”. I have another in currently that is getting attention, but I don’t want to be a squeaky wheel for something that isn’t that big a deal. My contribution isn’t really going to change anyone’s life, should I really @-mention a core team member every time I update my PR?
And that is the main thing I wanted to point out —I certainly don’t want to be that person that is demanding attention from people who have precious little of it in the first place. I wish there was the kind of framework that @Betsy_Haibel just started spelling out; something to help the core team and the people like me.
I have a couple of ideas to throw out for consideration:
I wish there was a session/workshop at RailsConf (led by a core team member?) that was all about the process of contributing. Attendees would walk away with a good start on how to contribute from PR start to merge. I know this is easier said than done
I recently heard about the idea of a “CommitFest” from the Postgres community. My understanding is that these are regular time blocks in the development schedule. If your contribution gets on the list for the CommitFest then your contribution is reviewed/finalized in that period (your submission gets attention during this time). Now this exact thing might make it harder for small contributions or beginners, but knowing when my contribution has attention is helpful. Mainly I want to know that I could ping core team members without being a nuisance!
