Allow non-ascii keys

[Dreamsorcerer]

Fixes #118.

[Dreamsorcerer]

@webknjaz LGTM checks blocking merging is a little annoying. We have flake8 setup now, so it should rarely trigger any errors anyway.

[webknjaz]

Doesn't it make LGTM even more significant? I mean that it catches things flake8 missed? It's not like WPS linter set is integrated.

[Dreamsorcerer]

Doesn't it make LGTM even more significant? I mean that it catches things flake8 missed? It's not like WPS linter set is integrated.

Problem is that it takes 15+ mins to complete (compared with <1 min for everything else), and will find an issue in probably about 1 in 500 PRs. I'd rather merge smaller PRs without waiting, and in the unlikely chance of it finding an issue, it can be fixed in a followup PR. I think this is how all the other repos are being used as well, including aiohttp.

[webknjaz]

@Dreamsorcerer more complex checks usually need more resources so it's kinda expected. I wouldn't judge the quality/usefulness of a check by this metric. Moreover, staring at the CI log in order to catch it as soon as it turns green, is a waste of time for a human — you shouldn't need to babysit it, it's done when it's done. If the CI is blocking you from performing other unrelated activities, you're likely doing something wrong.

Instead, let automation do the merge if the checks pass, it doesn't really require any attention from you. Use the Auto-merge feature that is enabled in the repository once there's a human approval and then, just walk away. Hopefully, when GH is done alpha-testing Zuul-like merge queues, it'll become way easier to deal with batches of PRs the same way Zuul does this.

FWIW the human's job is to perform a human review and the checks are on the automation (https://mtlynch.io/human-code-reviews-1/#let-computers-do-the-boring-parts) — you look into them only if and after something breaks.