I assumed the required interim spec reviews would be defined in the
Jakarta EE customization of the Eclipse Foundation Specification
Process. I assume we would require at least one interim review,
e.g., Public Review.
That just reduces the window in which a bad actor can act, but
doesn't eliminate it. But in all cases a bad actor can't get past
the final release review without approval by the Spec Committee.
It seems like there's two bad actor scenarios to consider...
A bad actor Spec Project Lead submits a final release review to the
Spec Committee without support from other Spec Project
Participants. In this case the dissenting Spec Project
Participant(s) can notify the Spec Committee of the issue. The Spec
Committee can decide that it will not approve the project release
unless the Spec Project holds a vote that passes with a
supermajority. Do we need to require that the Spec Committee act in
this way, or detail exactly what options it has for resolving the
issue? I don't think so.
A bad actor Spec Project Lead submits a final release review to the
Spec Committee. A Working Group member who is not a Participant in
the Spec Project and not a member of the Spec Committee objects to
the release. As above, the Working Group member can notify the Spec
Committee of the issue, and the Spec Committee can take the
appropriate action.
If you don't trust the Spec Committee to take the appropriate action
in these cases, you have the Grievance
Handling process to fall back on.
I think we want a process that's lighter weight than the JCP,
optimized for good actors, with a small number of checks and
balances. Adding more required votes seems to be a step in the
wrong direction.
Kevin Sutter wrote on 09/12/18 01:15
PM:
Hi,
We had a good discussion on
today's
Spec Committee call about whether formal Spec Project
votes will
be required as part of the Spec process. I believe it was David
who
proposed it (or advocated for it) and Bill had a dissenting
viewpoint.
We decided to table the discussion and come back to it on
tomorrow's
(Thursday) call.
Well... I just had a discussion
with Dan and it's not clear on what we are trying to decide
tomorrow. If
Dan and I are not on the same understanding of the problem, then
I would
guess that others might have the same confusion. Or, maybe it's
just
us... :-)
Dan and I discussed the "bad
actor"
scenario... How do we prevent a "bad actor" or a "malicious
participant" from pushing through the Spec process with their
own
agenda? Dan's argument is that by having these Spec Project
votes,
then this type of activity could be detected earlier in the
process. But,
that only works if every Working Group participant
(organization) is also
participating in every Spec Project. There will be cases where
some
Working Group participant (ie. IBM, Oracle, Payara, ...) may not
have an
interest in directly participating in a Spec Project. That
happens
today with JSRs, it will happen with Spec Projects.
But, that doesn't meant that IBM
(as
an example) is not interested in knowing what this Spec Project
is producing.
Thus, some type of interim reviews need to be surfaced to the
Spec
Committee to allow the Working Group participants access
to the
results of the Spec Projects. Just having the initial Spec
Project
creation and the final Spec Project review is not sufficient (or
the modification
of the Spec Project scope). We need to define some type of
formal
interim spec review process that allows the Spec Committee to
review and
vote on the progress of the Project.
I know that Wayne was trying to
avoid
the definition of these interim reviews in the Spec Process
document, but
we think it's needed. Having Spec Project votes without all of
the
Working Group participants participating and voting doesn't
accomplish
this. So, our take is that the formal Spec Project votes are
not
required. But, having interim Spec reviews and votes by the
Spec
Committee are required.
I think this is more consistent
with
with Bill was arguing for as well. But, maybe I'm just off
base.
Let's just make sure that we're all on the same page with what
we're
trying to decide tomorrow. Thanks.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
