thanks them for the PR & says there will probably be a wait before a review is done

I don't like that one. It's very impersonal and something like this shouldn't be automated in a community where we welcome and appreciate contributions etc. IMO we should always thank contributors manually and ideally we should also work on the response time so they won't have to wait too long. At least a first feedback can be usually given quickly.

Also not sure re the others "must do this, must mention that". I reckon it always depends on the PR and the issue. If we consider ourselves too good for giving them such feedback when needed we should maybe ask users not to issue pull requests? The community was recently removed from our mission statement in #8518 but I think it should be still important to really appreciate and value contributions coming from the community.

I know it's meant in a good way and exaggerate maybe a little but personally I think it's very important to not have something like this automated. Are there other good community projects that automate these things? I wouldn't want to contribute to a project and having to deal with responses from a "computer" and even if it's only a first response.

Also I think we should add such PRs rather to the current milestone instead of short term milestone.

I don't like that one. It's very impersonal and something like this shouldn't be automated in a community where we welcome and appreciate contributions etc. IMO we should always thank contributors manually and ideally we should also work on the response time so they won't have to wait too long.

What's the difference between an automated "Thanks, you may have to wait" and a manual "Thanks, you may have to wait"?

There will always be other priorities, and most of the PRs I've seen need a lot of work and guidance. And regardless of the potential value, if no one's paying for something, my priorities will likely be conducted elsewhere.

Currently, these PRs are greeted with silence. I assumed a message would be better. And unless you are willing to use your personal time to take care of all PRs from start to merge, while still finishing what's required of you in other areas, I don't believe these PRs will get attention w/o some sort of automation.

If we consider ourselves too good for giving them such feedback when needed we should maybe ask users not to issue pull requests?

What does it mean to be "too good for giving them such feedback"? You seem to be taking an awful lot of offence at the notion of an automated message.

Also I think we should add such PRs rather to the current milestone instead of short term milestone.

Matt mentioned during the meetup he triages short-term issues. I assumed he would get to those if they were there. They should be put wherever they will be triaged.

I said I'm exaggerating but think there's a huge difference when there's a personal message with a thumbs up (or thx) compared to a thx from a bot.

I think it would be rather something for guidelines for contributing which is also linked to when creating a new issue etc.

I usually always try to give some feedback within a few days but doesn't always work. If this is a problem I can check more on it to give an initial feedback and maybe others can do too. At least to give a first rough feedback shouldn't take too long. We can provide a checklist which maybe also helps for developers and reviewers in the guidelines for contributions.

I'd personally have rather no attention to a PR vs an automated message and nobody has a look afterwards either. PR's from users are highly valuable in such a community project that claims to have/be a community so maybe we can find ways and talk about some way to process these kinda reviews faster and more "process controlled". Instead of automating a "please wait" response I'd appreciate tools that help us manage these PRs. Eg showing which PRs from 3rd party haven't gotten any feedback within 5 days etc. Maybe there are existing tools for this or maybe we can build something for this?

I don't have a problem having a look at them and I can fit it into my daily work. When I start working I always check my emails (follow up on existing issues etc), new issues, whether there are PR reviews to be made, then work on my own PRs that require change because of reviews and then for the rest of the day ignore everything and work on my actual issues.

short-term is usually a milestone were more and more issues are put into but we don't work on them. It's unrealistic to say these issues will be worked on in the next months. Especially now that we focus bit more on other work. When working on the open source project we will work on Piwik 3.0 and probably no short-term issue will be touched in like next 6 months (just a rough guess). Meaning we would not give any feedback to PRs in months. Would be good to have them in the current spring so it will also make sure we actually work on getting them merged. If a developer doesn't get feedback after a while we can still move it into short-term until a developer worked on it again.

In general I think we should rather focus on finding ways to get PRs merged faster etc (we had this discussion for PRs from core developers but not really for 3rd party developers). Eg it may help to assign a PR to a core developer and to move it into current sprint. This would at least help me in having an overview of the work I need to do and where I need to follow up.

I don't have a problem having a look at them and I can fit it into my daily work.

As you will then.

I'm not sure if we should close it as I think we can automate other things as mentioned in the previous comment. Eg we could automise to which PRs we need to pay attention. Eg we could have a "dashboard" listing all new PRs, PRs that were changed in any way by the developer or other non-core developers (new commits, comments, ...) and PRs that were not changed in the last 7 days. Maybe bit like a Kanban dashboard.

Quickly googled for "GitHub reviews" and there came up eg https://reviewable.io/ which seems to "only" make it easier to review code, http://gerrithub.io/ where it says you can define a workflow and it seems to help manage external contributors etc, there's https://www.codereviewhub.com/ which adds tasks for each code comment in the review. I'm sure by finding a way to merge and handle 3rd party PRs better we also improve the workflow for our own PRs. Possibly it's also possible to find PRs that need attention with Github just by using the right queries.

Also we could discuss how to make sure we follow up on these issues. As said for me personally it would help to have them in current milestone and assigned to a person so I can check which work is left to be done.

IMO we should always thank contributors manually and ideally we should also work on the response time so they won't have to wait too long. At least a first feedback can be usually given quickly.

👍

we need someone in the team who will be responsible and taking care of this, maybe @tsteur you'd like to try over next few months?

Possibly it's also possible to find PRs that need attention with Github just by using the right queries.

as a start here is a Github issue search that will list all Pull requests that are opened and not yet assigned a milestone.

EDIT: one can also add datetime selectors like updated:>=2013-02-01

this should point to the most important PR that are waiting review / decision on what to do next.

Also we could discuss how to make sure we follow up on these issues. As said for me personally it would help to have them in current milestone and assigned to a person so I can check which work is left to be done.

From my point of view, suggestions:

• we need someone in the team who will be responsible to check PR across repositories and will follow up with 3rd party contributors
• ideally we reply to all PRs within 1-3 days
• provide a useful review and decision such as either "Please change this & that so we can merge" or "Unfortunately we cannot merge this because XYZ"

What do you think?

I can do that. 3rd party PRs are usually not big and are quick to review and doesn't take too long to get feedback. My only problem is to know which ones need my attention as mentioned. Even for our own reviews it's problematic. Eg we assign "Needs review", then I review, another developer works on it and afterwards it gets problematic for me. For example one doesn't get notified when there's a new commit for a PR etc (at least I think so). Also I'm never really sure if the other developer is done with all the changes etc. Sometimes one leaves another comment "another review needed" but sometimes not. The only problem for me is really to know to which ones I need to pay attention and follow up. Eg when there was no commit / change for 7 days, when there was a change but developer did not comment etc.

It's good to do that effort and give developers feedback. Of course we often point out things that are easy for us but if they issue another PR they will know it the next time and learn from time to time if they issue more than 1 PR. If we do a good job here it's more likely someone issues another PR.

1. Can we maybe have a page or something with useful links?
2. I'm still not sure how to manage it and how to exactly know to which ones I need to pay attention as described. I will try to find out over time if I can do it with Github and maybe we have to develop a tool that helps (or probably there are good tools for this already, we're not the only project on Github that gets PRs :) )

I can do that. 3rd party PRs are usually not big and are quick to review and doesn't take too long to get feedback.

This would be awesome 👍

Can we maybe have a page or something with useful links?

Nice idea, maybe you could create in our Wiki or directly in the Developer guide "Core team workflow" which seems appropriate: http://developer.piwik.org/guides/core-team-workflow

The only problem for me is really to know to which ones I need to pay attention and follow up. Eg when there was no commit / change for 7 days, when there was a change but developer did not comment etc.

I think there is a solution for this, by using updated:>=2015-10-01 as search operator one can restrict all issues that had some comments/ commits, since given date, eg. All PR not yet groomed that were updated in October in this github issue search

What do you think?

@tsteur could you create next step issue(s), or close this issue as appropriate? I understand that from now on you will kindly follow up with community members and other colleagues who contribute to core which is a very positive change to our workflow!

I reckon we can close it. I'll have a look especially at PRs from non-core developers. I think it would be still nice to have some kinda tools for that as mentioned but we can do it later