Pull request reviews

Hola :wave:,

I’m bringing up something I’ve been thinking about to get your thoughts on it :upside_down_face:.

When users decide to use Tuist they are building trust with the project that they might lose if they feel they questions and issues are not tackled in a reasonable amount of time. I think we have been very responsive on Slack (kudos to Kas and his especial ability to jump quickly to help people in our Slack channel and GitHub issues). However, the issues are piling up on the GitHub repository. That might lead users to workaround features, or even worse, decide not to use Tuist.

This is a tricky situation to be in because we all have our full-time jobs and we are devoting only our free time to the project. That means we can’t provide the same support, or tackle the issues at the same pace as if we were all working on this project full-time.

In that context, I was wondering if we can do something to prevent issues from getting stale in our backlog and shorten the time it takes to merge a PR. I’ve been cowboying a bit lately merging PRs that had no approvals because I was blocked by it and I didn’t want to end up opening multiple branches referencing one another. I don’t like to be doing that because we might be missing bugs and regressions that can land in master, but having open PRs waiting for a long time to get a review is detrimental for the user’s trust in the project too.

So I was wondering if there’s anything we can do to change that. I set up GitHub scheduled notifications but that doesn’t seem to work. Any ideas? Should we allow cowboy merges if the PR meets some requirements?