Re: [jakarta.ee-spec.committee] Customizing the EFSP to createtheJESP

["Kevin Sutter" <sutter@xxxxxxxxxx>]

Doh!  I was looking at releases and
didn't find anything...  I figured Master would be the updates for
the 1.1 release.  Didn't even think of a separate branch for the work
in progress...  Thanks for pointing that out.

---------------------------------------------------
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



From:      
 Ivar Grimstad <ivar.grimstad@xxxxxxxxx>
To:      
 Jakarta specification
committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:      
 02/21/2019 11:11 AM
Subject:    
   Re: [jakarta.ee-spec.committee]
Customizing the EFSP to create        theJESP
Sent by:    
   jakarta.ee-spec.committee-bounces@xxxxxxxxxxx

---

Correct me if I am wrong, but I think the diff was between
the version_1_1 branch and master?

https://github.com/EclipseFdn/EFSP/compare/version_1_1 

Ivar

On Thu, Feb 21, 2019 at 6:07 PM Kevin Sutter <sutter@xxxxxxxxxx>
wrote:
Wayne,
I'm confused...  during yesterday's call, you were showing some proposed
changes to the EFSP via the github diff comparison tool.  But, when
I look at your repo, nothing has been changed for three months, except
for the faq.  And, there are no PRs to look at.  So, where are
your proposed changes that you walked us through yesterday?  Or, when
will you have an updated code base based on our discussions yesterday? 
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



From:        Wayne
Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
To:        Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:        02/21/2019
11:00 AM
Subject:        Re:
[jakarta.ee-spec.committee] Customizing the EFSP to create the    
   JESP
Sent by:        jakarta.ee-spec.committee-bounces@xxxxxxxxxxx

---

As discussed on today's call, I've opened up GitHub issues on the EFSP
repository. I've moved the issues that I'd captured
in Bugzilla into GitHub issues.

I've taken another pass through the "specialization" document
and have created a small number of issues to address concerns raised there.
I'll take another pass before our next call.

As I stated on last week's call, I don't believe that it is possible to
provide 100% coverage of "all of the possible customizations".
As we discussed, document starts by presenting what cannot be changed (and
what must be preserved); the bulk of the content that follows is a collection
of examples of things that you may consider changing. The list is in no
way intended to be complete.

If there are specific deficiencies in the process that we need to address
for the JESP, please highlight it and we'll work through it.

How to run Specification Committee Votes;

Yesterday's call gave me some numbers that I'll use here.
 
Default: specification committee approval votes connected to progress and
release reviews run for a minimum of 14 days; other votes run for a minimum
of 7 days. All votes and related discussion run in a public forum. A customization
may opt to increase the minimum period.

Open question: can a customization opt to allow votes to occur in a private
forum and only publish final results?

The specification process should not attempt to describe a specific implementation
of a voting system.

As a general rule a customization should avoid specific implementation
details or references to specific technology (GitHub).
 
How a Participant appoints a Participant Representative;

Default: send a note to emo@xxxxxxxxxxx
 
What to do when a vote fails or approval is not otherwise granted;

Default: resolve the issues that caused the failure and re-engage.

The rule is that you need approval, or have to successfully complete a
review. If you don't do that, you can try again. A customization could
put a time limit on resolution (i.e. get back to us in 15 days). As we
discussed yesterday, a vote might be reset or extended to give a specification
team time to resolve an issue before the vote concludes.
 
How mechanically a Specification Version becomes a Final Specification;
and

Default: content is relicensed and moved to the distribution channel.

The specification process should not attempt to describe a specific implementation.
I might remove the word "mechanically" to avoid the temptation.
 
Requirements/guidelines to pass a Progress Review, along with timing of
the review itself.

From the EDP/EFSP:

1. The Project Team will complete all required due diligence under the Eclipse IP Policy prior to initiating the Review.
2. A Project representative (Project Lead or Committer) assembles Review documentation.
3. A Project representative presents the Review documentation to the Project’s PMC along with a request to proceed with the Review and for approval of the corresponding documentation.
4. Upon receiving approval from the PMC, a Project representative makes a request to the EMO to schedule the Review.
5. The EMO announces the Review schedule and makes the documentation available to the Membership at Large.
6. Approval by a Super-majority vote of the Specification Committee is required to successfully complete a Review. 
7. The EMO approves or fails the Review based on the feedback, the Scope of the Project, and the purposes of the Eclipse Foundation as defined in the bylaws.

Regarding timing...
reviews conclude on the first and third Wednesday of the month (the actual
board resolution was that we should hold no more than two review periods
per month); a specification process cannot override this. A specification
committee might, however, decide that we should batch reviews into a single review
period each month (thereby batching their engagement with the respective
legal departments).

HTH,

Wayne



On Wed, Feb 20, 2019 at 4:34 PM Bill Shannon <bill.shannon@xxxxxxxxxx>
wrote:
I added this comment to the draft Jakarta EE Specification Process document
several weeks ago, but have gotten no feedback, so let me repeat it here:
The "Specializing the EFSP" document describes a large number
of things that can be customized, but this Jakarta EE specialization only
customizes a few of them. I'm unclear on which of the possible customizations
have a default, and which remain "unspecified". Seems like we
should discuss all of the possible customizations and determine what the
effective value is for the Jakarta EE Specification Process. Perhaps there
are additional customizations that should be added here.

Perhaps someone could go through the "Specializing the EFSP"
document and annotate it with the answers for the JESP?

For example, here are somethings we could choose to customize:

• How to run Specification Committee Votes;
• How a Participant appoints a Participant Representative;
• What to do when a vote fails or approval is not otherwise granted;
• How mechanically a Specification Version becomes a Final Specification; and
• Requirements/guidelines to pass a Progress Review, along with timing of the review itself.

How
exactly are we customizing these things for the JESP?  Or, if we are
not customizing them, what is the effective default for each of these?

_______________________________________________
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://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee


-- 
Wayne Beaton
Director of Open Source Projects | Eclipse
Foundation, Inc._______________________________________________
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://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee



_______________________________________________
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://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee_______________________________________________
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://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee