Re: Find some consensus


If we have a list of who is "subject expert" on which part, it will be natural to request review from that person. If I see a new PR, I will check the list and if the PR affects one of the subjects on the list, I will request that expert to review the PR. And if a "subject expert" would write a write bad review, the rest of us would be very careful about approving a PR there the "subject expert" disagree. I have on a number of PRs either changed the PR or closed the PR when I have got bad review.

A list of experts could simply be a table like:

jmri.loconet.**                Bob Milhaupt    @devel-bobm
jmri.expressnet.**             Paul Bender     @pabender
Infrastructure (Maven, Ant)    Randal Wood     @rhwood

If the table lists Java packages, it will be easy for people to quick find the right expert. And some parts may have several experts listed in the table, and some PRs may affect several parts and therefore need review of several "subject experts".

2020-07-22 03:48 skrev Bob M.:

My personal opinions on "vetoing" a P/R:

The JMRI project is fortunate that it has several active developers who are
experts in certain areas of JMRI functionality.  I think we ought to make
use of that expertise.

 I think that a "subject expert" should _always_ have the authority to veto
a P/R for reasons which directly relate any of his areas of expertise.

And I think that the project owner, and _perhaps_ the "Maintainers" should
have the ability to overrule any veto.  (Having Maintainers as possible
"final judges" would help reduce the administrivia burden which Bob J.

Are there GitHub mechanisms available to suppor this concept?  I have no
idea.  Would we need GitHub mechanisms to implement this methodology?
Perhaps.  Perhaps not.  We've got along thus far on the "gentleman's
agreement" principle.

Bob M.

Join to automatically receive all group messages.