Service-catalog: Possible change to LGTM process

[duglin]

Opening an issue so people can comment and think about this off-line and we don't need to use up the calls/f2f for this...

I've recently heard two different proposals for tweaking our LGTM process:
1 - (from Morgan) instead of LGTM1, LGTM2,... labels, have LGTM-RH, LGTM-IBM, LGTM-Goog, LGTM-Dies,... type of labels (one for each company that can approve PRs). Then we not only can see how many LGTMs are on each PRs but which ones each of us should look at (or can skip) as needed. While this may make us look like a company-specific project, given our PR process specifically talks about only one LGTM per company, this would be consistent.

2 - (from Paul) Rather than company names in the label, put the mantainer's name/initials. So we get similar benefits of the first option but we don't look company focused. This might require more overhead than the first option since the list of maintainers may change more often than companies, but its not like it happens on a daily basis, but it could also be viewed as a badge of honor to see your name in lights :-)

Not sure how easy it is, in both cases, to write a query to show all PRs that have exactly 2 LGTM though. If that matters.

Personally, I'm ok with either and would prefer either over our current approach, but I'm not in the best position since I don't do any queries over these labels anyway. But I can imagine being able to see an IBM/Doug label on each PR when I show all open PRs could be useful.

Thoughts?

[krancour]

I second @MHBauer's proposal / the first option.

The second option still requires some additional cognitive overhead in knowing that certain maintainers' labels are mutually exclusive because those maintainers represent the interests of a single company. The first option doesn't have that problem.

As to the perceived problem that the first option may make our project look too much like it's driven by our respective companies... well... it is. Why go to any lengths to hide that? We can re-evaluate this approach if/when we have a contributor who's not representing any interest other than his/her own _and_ is promoted to maintainer status.

[MHBauer]

On a variant of 2, how much control do we have over the label colors? If we encode the 'company colors' into each lgtm-initial, then the cognitive load is lowered. IBM committers can be blue (because duh), redhats can be red(also duh), deis can be green (their logo has rgb in it and r&b is already taken), and google can be either yellow (logo has rgby and rgb is taken) or some strange rainbow of colors representing an alphabet.

We are of course interested in outside help, and more people participating and contributing, but the rules right now are really focused on having a combination of companies. I agree with @krancour on the 'why hide it' aspect.

[krancour]

We have total control over label colors. I am ok with labels for each maintainer's LGTM, provided we use color coding as @MHBauer suggests. My only minor reservation would have to do with whether any maintainer who may be color blind might not be satisfied by this. If anyone objects, please do so...

[pmorie]

I'm moving this to Later since I don't think we have time to handle this at this point. I have some alternate ideas I'd like to talk through after Kubecon.

[duglin]

yea, let's brainstorm at kubecon over a few drinks :-)

[pmorie]

I'm taking this as a tacit agreement to let us pump you full of beers, @duglin

[duglin]

LOL notice I used the word "drinks" - that could mean just about anything!

[arschles]

I am purposefully leaving this out of a milestone. Please do not assign it for now

[arschles]

I have added this to the 0.0.3 milestone and added the needs-docs label, as the decisions made from this issue must be documented in the repo.

[arschles]

Moving this out of a milestone until we discuss further.

[duglin]

Closing since I think we should move from company based LGTMs to individuals.