| To simply this, it might be helpful for me to get a better understanding of what goals are trying to achieve with the star. Hopefully I can be more helpful in suggesting other solutions.
Thanks again to everyone for the responses -- they are appreciated.
-- David Blevins 310-633-3852
Agreed our current rules do make one implementation special as it does have to implement all optional parts. We have it on our 2021 plan to address that because it isn't fair; particularly to the one implementation that has to implement all the optional parts.
If the star meant "implements all optional parts", then that could be fair as anyone could get the star if they put in the work, even if they did it slowly and came later. It might even motivate them to implement all optional parts to earn the ability to stand out despite being lower in the list. I'd still probably prefer to handle that in the public test results page because everyone's optional statuses are likely nuanced, but an all or nothing approach is at least consistent and I could accept it as fair.
Understood that the list is ordered by the dates everyone is certified. I'm ok with that. If we did alphabetical that'd pretty much put Apache Foo projects at the top of every list, which I also don't think is fair.
If the star meant "we used these for the ballot", then my comments would be having stars on the first entries in addition to them being ordered by date (who has more resources) really makes that much tougher on those of us at the bottom of the list. It's already an advantage being first to market and a disadvantage not even being listed for months (or years in our case). If we can avoid bringing stars in as well it would make a positive impact on our morale and be greatly appreciated.
Very happy to discuss any aspect of this and greatly appreciate everyone's time. Very open to discussion and willing to make compromises.
-- David Blevins 310-633-3852
David,Unfortunately,
the compatible implementation(s) used to ratify or certify the Specification
version is special. The compatible implementations have to contain
and test all of the required *and* optional aspects of the Specification.
Compatible implementations that come after the certification may
or may not have the optional aspects of the Specification. So, to
pretend that all compatible implementations are neutral is not fair. And,
tbh, the ordering of the compatible implementations implies some form of
"superiority" or, at least, non-neutrality. How do we get
around these shortcomings? We discussed this at length, and the approach
proposed with the asterisk (*) seemed like a good compromise.FWIW, I didn't
even want to list any additional CIs on these Specification pages. I
thought (and a few others on the call agreed) that the Compatible Implementation
listed on these Specifications pages were the ones used to certify with.
Period. Any other listing of additional Compatible Implementations
would be listed on the respective github pages or wiki of the Specification
Project. But, others on the call thought this was confusing to look
in multiple locations for the compatible implementations. So, we
compromised on the above approach.
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)From:
David
Blevins <dblevins@xxxxxxxxxxxxx>To:
Jakarta
specification discussions <jakarta.ee-spec@xxxxxxxxxxx>Date:
02/10/2021
13:12Subject:
[EXTERNAL]
[jakarta.ee-spec] Ratified Implementations and special designation in the
eyes of usersSent
by: "jakarta.ee-spec"
<jakarta.ee-spec-bounces@xxxxxxxxxxx>
I appreciate there was consensus on today's
spec committee call to mark the implementation used for certification with
a star. We also commented that if we would alternate the time of
the meeting, we should do more over email, so hopefully my feedback is
welcome despite missing the meeting.Can we find another way to document the
implementations used for the vote?I have many concerns about the concept
of RIs. A big one is the years of difficult experience competing
against an implementation the public sees as special or more official than
yours. The fundamental tenant of Advance Implementation Neutrality
is to make sure we're not doing that.If we want to document the implementations
used for the Release Review, can we simply include a link to the relevant
CCRs in the "Release Review" section of the page? It could
be right under the vote totals after the text "The ballot was run
in the jakarta.ee-spec mailing list. The CCRs used for the ballot
were: [link1] [link2]"This would have it documented, but the
list of implementations would look neutral and one would not stand out
over the other.Thoughts?-- David Blevinshttp://twitter.com/dblevins
http://www.tomitribe.com310-633-3852_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
_______________________________________________ jakarta.ee-spec mailing list jakarta.ee-spec@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
|
