request: explain the issues labelling / review / merge process in CONTRIBUTING.md

[fxck]

Hey, I feel like there's a small issue with communication again. Could you perhaps please update contributing with a rough outline of how the review - merge process works?

Some of the questions I imagine could be addressed there:

• Do you have a certain day in week you review all PRs at once, so it doesn't distract you from your own work? Is this happening once a week? Once a month?
• How do you decide the priority - what to review first? Features, bugs? Internal, external contributors?
• Is there any system of primary / fallback people for different parts/comps of m2, similar to how it works in angular/angular? Could this list be made public, so people can cc relevant people and get their issues / PRs labelled, reviewed?
• Do you have any issue "caretakers" similar to how it works in angular/angular (ie. person that is on issue labelling / triaging duty)?
• Are there any external factors causing PRs labelled merge ready to not to be merged immediately? Ie. you need a green light from all internal google apps using m2?

Since there is no public insight into these processes, it might seem to someone like me that there are some minor project management inefficiencies, which in turn make it a little difficult to guess when some bug fixes / features will be merged, or if it's worth trying to contribute.

Some examples:

• out of 437 open issues, there are 150 unlabelled ones, which is 35%, in angular/angular it is about 10%
• I imagine that quite a few of those open issues are outdated, support requests, without reproduction or do not follow the issue template so they could be closed
• for example, this fix(dialog): leaking MdDialogContainer references #2944 is a pretty small bug fixing PR that was labelled as merge-ready week ago
• there's 37 open PRs from a single team member, some date back to months ago without any visible activity (I imagine you might have had internal discussions over some of them and simply didn't / forgot to write some sort of conclusion to the PR itself though)
• out of currently 65 open PRs and assigned PRs, 32 are assigned to @jelbourn 14 to @kara, isn't this too much for a person to handle (that's why I was asking if there is any primary / fallback system)
• there are some relatively small (in code / changes) feature PRs from the team members that's been sitting there unreviewed for months (feat(select): add md-select-header directive #3211)
• milestones are outdated https://github.com/angular/material2/milestones
• projects seems to be used only by some of the team members and are outdated as well https://github.com/angular/material2/projects

Wouldn't it be worth to defer work on all new features / bug fixes for say a week and get on top of issues and existing PRs? I honestly care about this project, it's essential for my own work, so I'm not writing this to complain, but rather to be able to understand what's going on and how I could possibly help.

@jelbourn @kara @crisbeto @devversion and others

[jelbourn]

Our merge process is the same as angular/angular:

• Every change that affects the source code (but not tooling / tests) needs to succeed on a presubmit run for all Google apps using the library (which is quite a few projects). This, unsurprisingly, takes a long time and is somewhat flaky. Often there are screenshot test failures or issues in downstream tests that need to be fixed.
• There is a weekly rotation ("caretaker") who is responsible for running this presubmit / merge process and tracking down failures. This person is also responsible for the same process on AngularJS Material and flex-layout. It pretty much eats that person's entire week.
  *Google presubmit runs tend to finish in batches, which is why you typically see several PRs merged at once.
• Some PRs end up causing failures inside Google and get put on the backburner in favor of other priorities.

Other stuff:

• We plan on adding the same pull-approve system to the material2 in Q2.
• Lately PR review / merging has been lagging because of the pending ng-conf and work related to Angular 4 coming out.
• Issue triage happens twice a week w/ the current caretaker, though this occasionally gets skipped when there are other pressing concerns.
• Our Q2 is going to be largely focused on getting the bug count down and improving test tooling without a ton of new big developments (except for data-table).

Ultimately, we want to get PRs merged/issues resolved more than anyone, but sometimes competing priorities will mean that some end up sitting for a while.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}