HotSpot Style Guide change process

[Kim Barrett]

When the Style Guide was updated for C++11/14 usage and other cleanup
(JDK-8247976), a change process was added to it.  It says

  Proposed changes should be discussed on the
  [HotSpot Developers](mailto:hotspot-dev at openjdk.java.net) mailing
  list, and approved by
  [rough consensus](https://en.wikipedia.org/wiki/Rough_consensus) of
  the [HotSpot Group](https://openjdk.java.net/census#hotspot) Members.
  The Group Lead determines whether consensus has been reached.
  Changes are likely to be cautious and incremental, since HotSpot
  coders have been using these guidelines for years.

Vladimir Kozlov has questioned this process and suggests another:

> I looked again on voting description for Style Guide changes. And it
> references to `rough consensus` which is not in OpenJDK bylaws : 
> https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.html#L69
> 
> I think it is bug (separate from these changes) and should be fixed by
> using our rule http://openjdk.java.net/bylaws#three-vote-consensus 
> With Project Lead final vote we will need at least 2 other members votes
> during 2 weeks review period. I think it is similar to `rough consensus`. 

Use of "rough consensus" with an arbiter has precedent within the OpenJDK,
though it's not used in the bylaws. The current text quoted above was based
on

https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html 
JEP 2.0, draft 2 - see "Planning", 4th bullet

and

https://openjdk.java.net/groups/vulnerability/
OpenJDK Vulnerability Group - see "Making decisions"

So both the JEP Process and the Vulnerability Group use rough consensus,
with the relevant lead as the arbiter.  (The V-Team page links to an IETF
document describing rough consensus.  The HotSpot Style Guide links to
the same Wikipedia article as the JEP 2.0 Process; that Wikipedia article
references the IETF page.)

I called out the new change process specifically in the initial RFR email
for JDK-8247976, but that part didn't generate much (any?) discussion.

If we don't like it we are certainly free to change.  And if Vladimir
doesn't like it then we should change, since as HotSpot Lead he's fairly
central to that process. But I don't think there's a "lack of precedent"
or "not appropriate for OpenJDK" argument for changing.

I chose that process because I didn't want it to be too easy to make changes
to the Style Guide. In particular, I think it should require more effort
than is involved in a typical RFR.

Even if we don't change, and especially if we do, some further refinement of
the mechanics may be needed. I think the current mechanics may have a
problem that the request shows up in one's mailbox looking pretty much like
an ordinary RFR. When I was originally thinking about that text we were in a
world of pure email change requests, and the document was still a wiki page.
With the move of the document to the jdk repository and the move to github
and PRs + Skara support for changes, the mechanics are different. It might
be better if it could be subject tagged differently, as we do with Call for
Vote emails. There are probably things we could do about that, if others
agree that's a problem. Or maybe some of you see other problems?