Let's beef up this project!

[rmosolgo]

👋 ! In the Ruby working group, we're trying to improve the support for Ruby at GitHub. Part of that story is sharpening our development tools, and RuboCop seems like a great place to do some sharpening. Here's what I'd like to do:

• Audit the rules in this gem and github/github:
  • Do we want to preserve all these rules? (And should we "upstream" some from github/github?)
  • Are there rules we want to add?
• Assess the autocorrectability and feedback of the rules we decide to keep.
  • RuboCop should be a development aid, not a blocker
  • When it does get in a developer's way, it's important to empower the developer with clear, actionable, and informative feedback
  • Then, it's great if RuboCop could get itself out of the way, with autocorrect support whenever possible. Maybe that means backfilling autocorrect support for rules we keep.

I think there are a few other ways we could leverage RuboCop better, but refreshing this project a bit would be a solid start!

What do you think, are there other ways we can improve this project or get more value from it?

If you want to start on the goals described above, feel free to open an issue or PR with a proposed change.

[gjtorikian]

cc @github/linting for reach

[rmosolgo]

Woahh we have a @github/linting team, cool!

For some background, the Ruby working group is trying to improve the development and deployment experience for new and existing Ruby apps at GitHub. This includes a lot of interesting, important work on things like Ruby version management, dockerization, automatic CI support etc, but I don't have experience there so I'm not very helpful with it 🙈

So, I'm trying to move our development tools forward a bit. It seems like this library would be a good place to start, bringing good conventions to new and existing Ruby apps.

Do any of y'all have more thoughts about this goal? Does working on this library seem like a good place to start? Do you have any specific guidance about the cop-by-cop assessments described above? Also, if there's more to read about linting at GitHub, I'd appreciate a link to it!

[technicalpickles]

I used rubocop-github semi-recently on a new project, and we found that some of the included rules were fairly specific to github/github. Or, maybe I don't understand what their motivation was and they were contrary to common practices outside that repo?

Here's what we excluded:

GitHub/RailsControllerRenderLiteral:
  Exclude:
    - app/**/*
GitHub/RailsViewRenderLiteral:
  Exclude:
    - app/**/*
    - spec/controllers/*

It has a been awhile so I don't recall specifically the kind of code those guard against, but it should be possible to clone down the repo and run with those lines commented out to see what happens.

Also worth noting are these lines, which I'd expect apply to many projects:

Style/FileName:
  Exclude:
    - Gemfile
    - Rakefile
    - Brewfile

That one seems a good candidate to move upstream to rubocop-github, if not rubocop proper.

[rmosolgo]

Thanks for sharing your experience! I'll dig in there soon.

[rmosolgo]

I don't actually have capacity to do this 😢