Clarity on governance and getting things included

Over the last few months, I’ve noticed at least two examples of contributions being delayed by lack of feedback from the core team.

One is a question I had about adding Typescript types to Rails directly. The other is a now 10 day delay in addressing one of the bigger topics noticed in May, which is explaining concerns. There’s a number of other feature requests in rubyonrails-core which haven’t been responded to in over a week.

I don’t bring this up to criticize the core team. I love Rails, I love the work being done and I’m thankful it exists. I am concerned though that new volunteers, the thing that can make this community and project thrive as it nears it’s third decade, seem to be falling through the cracks.

I think this brings up an interesting issue in Rails. The governance model is kind of vague and pretty limited. There’s a core team with DHH at the top and then there’s… nothing official as far as I can tell. Is there a team there to triage feature requests and PRs? I don’t know. Is there a documentation team? I don’t know. It’s not even really clear how to get on the core team. I’m wondering whether the lack of clear governance is causing some of these issues.

What I would propose is that the community consider whether there should be layers to the governance model to focus on different topics, like documentation, triage, marketing and clear lines of communications between different groups along with clear authority and responsibilities for each group. I view this as having two major benefits to the core team:

  • first, it just takes a lot of things off their plate. If we had someone to triage feature requests, pull requests and issues, then core team members could focus on more complex features and topics where their expertise is most effective.
  • second, it creates a feeder system for the core team for potential new community leaders.

Does folks feel this is an area that should be explored? Any thoughts on this?

3 Likes

We do have a governance structure like this, but I don’t think it is clear to the general public. This is a nice opportunity to make it public.

We have the Rails Core Team and The Rails Committers team. They are both responsible for triaging feature request, pull request and issues.The responsibilities and the composition of those teams are documented in the website Our large, friendly community | Ruby on Rails.

We also have other two official teams that are not documented.

The issues team - They are responsible for triaging issues and documentation changes. We have 12 members in that team.

The documentation team - This is legacy team and exists for the time where the docrails project were public writable to merge documentation contributions back to the main repository. This team is now only one person and most of the documentation PRs are now reviewed and merged by all the other three teams.

We have a path to grow contributors into and up all those teams and recently we are having a influx of people going through those paths like @jonathanhefner @petrik and a few more. I don’t think we even made those paths public, maybe we will in the future but it is something the Core Team is responsible for and we are very intentional of this.

One key characteristics for anyone waiting to join any of those teams is starting action like members of it. I confess this is a little bit hard to do if there is no clear expectation of what we want. So if for example you want to become a commit you need to start action like one already. Review PRs, give constructive feedback on feature requests, triage issues, help the community to grow. If you start to do that I’m sure a member of the core team will see an recognize inviting you to join our private contributors chat.

I hope this clarify the governance of the project and serve as documentation to people wanting to become regular contributors.

16 Likes

Thank you for the clarity. It was not clear that these groups existed.

Sorry for the delay here. I just wanted to say thank you as well because I haven’t heard about these teams so I’m glad to see the teams described here. I think it would be really helpful to know what exactly the rules are around tagging members of these teams, how often we can do it, how long can we expect to wait for our pull requests and comments to be addressed. I had a documentation PR waiting for feedback from someone who could give a definitive answer - for five years, even though multiple other people commented on the usefulness of the PR. I was also wary of doing so since I got the impression that tags were not welcome.

I’ve always really wanted to contribute to Rails, but the fact that I’ve had this much difficulty in getting my first PR across the line makes it very demotivating to try. I’m sure we’re all doing our best, but having documentation on specifics around how to contact the relevant team members for their feedback would be awesome. :slight_smile:

5 Likes