Sign inJoin
2
2 Comments

GitHub app feedback (for developers)

by hatkyinc

Is it clear what this is/does? (for developers)
Does it sound somewhat attractive to you?

https://github.com/apps/rubocop-auto-fixer-ruby-ror

Roast it as hard as you want ^^.

hatkyinc's avatarhatkyinc
on October 15, 2020
Say something nice to hatkyinc…
Post Comment
  1. 2

    Hey,

    • I love the idea of something that does the work for me :) And I love the idea of upholding standards in the code base. This is just a linter, right?
    • Is there any way to bring this earlier in the workflow? Can this run against PR instead? Ideally, all team members would run a linter on their own machine before sharing their code, and bad code would never make it into master.
    • Building up on the above bullet, I could see this being useful as a first pass in PR reviews, saving humans time looking for trivial mistakes. I.e.: 1. dev opens PR, 2. bot reviews PR for style, 3. dev corrects mistakes and updates PR, 4. team members review the PR.
    • One concern about the drip flow: I like that it would open one PR at a time and not bombard us with PRs, which would crash morale and overload CI. However, it feels like it wouldn't be super efficient if it opened PR after PR for a similar error (say spacing is consistently off). Batching similar errors together could be better.
    • Looking at the screenshot, I feel overwhelmed. Is that a standard PR description that the bot outputs? If so, I would: 1. remove anything that's not useful (being fun and friendly is cool, but not if it dilutes the messages and wastes devs' time) 2. Add some structure; a bolded title with either content under, or content next to it after a colon. 3. Order the content in order of importance: most important first, and decreasing.
    • Grammar police: second line of benefits: "reduce it's complexity" => "reduce its complexity"

    Cheers,
    Ben

    IndieHacker32232's avatar IndieHacker32232
    ·
    6 years ago
    ·
    Reply
    1. 1

      Can this run against PR instead?

      Yes it will run against PRs.
      My thinking was, first cleanup the base code, only after that's clean, uphold new PRs to the same standards.
      I could do it by change type.

      I guess the best flow this could have is you push a PR, you forget/miss something related to standards like indention, spacing, condition positive/negative.. The bot fixes your PR and that's it.
      I was kinda thinking about trust and new things so allow people to onboard slowly, getting the PRs and reviewing them manually... even if it's against your own PR branch.

      It should be a git pre commit/push hook is the most common comment about this, but I think that's a tiny bit harder as it's per computer setup not per repository, it's kinda non interactive, like if there are issue and you need to hack around it, it sucks a bit? IDK, maybe I'm just making excuses.
      I was thinking this way is smoother/easier..

      Yea I do think of batching fixes by types like all spacing, indentations, new lines and such should be one batch
      while condition changes should still be separate
      sorting lists should be it's own
      things like that

      The PR description I know I need to reduce to the basic, IDK why I got creative with some silliness... Honestly I know I don't commonly read them, just skip to the changes, if anything yea just the parts that change and a section for commands,

      Thanks for the review

      hatkyinc's avatar hatkyinc
      ·
      6 years ago
      ·
      Reply