Will look into those. Unfortunately, somehow notifications either didn't arrive to me or I've missed them. Poking me about it is definitely an ok thing to do.

In T164700#3242560, @Smalyshev wrote:

Will look into those. Unfortunately, somehow notifications either didn't arrive to me or I've missed them. Poking me about it is definitely an ok thing to do.

The problem is not this specific incident - not a biggie. The problem is that we don't have an overall strategy or tooling to deal with these for all github/wikimedia repos, and remind repo owners in a nagging way ;)

The right way would be to have single place - e.g. have these duplicated in Gerrit. Not sure how hard it is to do. Watching two places is not usually going to work well.

manual watching wouldn't work, but auto-creating phab tickets based on pull requests should solve it. We must allow community to contribute the way it feels the most comfortable with. We shouldn't require community members to learn an obscure tool (Gerrit) in order to submit a 2 line patch.

And since we are moving towards phabricator git hosting, I agree that we may simply clone the PR into it. I would stay away from gerrit's magic :)

T136863: Should Wikimedia have standard policies for managing github mirror repos? exists for the general issue. Either this should be specific to Wikidata or it should be resolved duplicate.

In T164700#3245080, @Yurik wrote:

auto-creating phab tickets based on pull requests should solve it

That makes no sense. Pull requests are code. Code Review happens in Gerrit, not in a Phab Maniphest ticket.

@Aklapper I meant that a phab ticket is a much more convenient way to manage reminders and organize/plan/track work. The review of the code should happen in the code itself, which in this case is actually github (it has an excellent review system).

It is still not ideal, because we also want to auto-build it in jenkins - which means that not only should we track it in phab, we might also want to automate gerrit import and reporting mechanism. This is exactly what travis-ci does - it takes PR from github, runs it, and posts back the results of a test run.

I have already pointed to the general task for dealing with this issue.

If you are interested in further discussion of a general sort, please take it over there to centralize.

Note that while I add the patches, I can't close github pulls. This is probably the state of affairs for most other repos too, since most of the devs aren't github owners.