Mindaugas Mozūras

@tleish could you expand on what kind of behavior you expect? A single comment under a pull request with all problems? Even if `consolidate_comments` is not what you're looking for,...

> @mmozuras I would personally be hesitant to rename a configuration option that's been released for the better part of a year "just because". 👍 > @tleish / @mmozuras maybe...

@doomspork that would be great 👍 > Going back over this I'm wondering if we couldn't solve this by whitelist/blacklist-ing certain "events" Could you expand on what you mean?

@dorner there is no way to do it currently. In your example, it would not be enough to implement passing of parameters. We would need to do additional work to...

@mknapik there is no recommended approach, we have to figure that out 😄. You can look at how @dorner did it: https://github.com/prontolabs/pronto-rubocop/pulls/dorner. What do you think about this kind of...

@doomspork not sure if I follow, so let's try again 😄. @dorner added additional configuration for rubocop specifically to `.pronto.yml`. See [here](https://github.com/prontolabs/pronto-rubocop/pull/30/files). It seems to me that @mknapik could do...

> It's very useful for me to be able to run pronto without checking out a branch first. @orangethunder we don't want to bloat Pronto too much. So before considering...

@joaquinrulin I'd love to have it in the README! It's not obvious to me of the best place to mention it. We have a list of gems, but that's meant...

@kevinjalbert I love the article, but I want to keep this issue open. As creation of new runners is very important, I think that we need even more documentation 🙂

@doomspork yes, I'd like it to be more extensively documented. I think that documentation should reside in this or https://github.com/prontolabs/welcome repo.