Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] JESP finalization review
I've marked all changes and comments as resolved. I've named the current revision "1.0 Release Candidate 1".

Please have a look at the document. 

IMHO, the manner by which the Steering Committee decides to approve the specification process is a matter for the Steering Committee to decide. As I mentioned in my last note, I believe that the section on voting in the charter covers this (and it would be presumptuous for us to assume that we can dictate how the Steering Committee runs a vote).

I've left in the change that I made that adopting a new version of the JESP requires a super-majority of the strategic members of the working group. My reasoning is that adopting a new version of the JESP should be the highest bar (i.e. it should be at least as significant as designating a profile).

For the purposes of approving this first version of the JESP, I will assert that a first version qualifies as a "revision" and so the voting requirements outlined in the first bullet applies. That is, we require a ballot of seven days to approve.

Getting this out the door is on our critical path to creating specification projects from our existing projects. If you have immediate concerns that this process document does not address, please raise them ASAP. For now, we need to have enough of the process defined to actually engage in the creation of specification projects. We can work on a revision to address new deficiencies as we discover them. We can continue to evolve the operations document.

I will call for a proper ballot to approve this process starting this Wednesday with a goal of approving this on April 3. 

Unless there is some objection, I would like to socialize this ballot with the Steering Committee on this Tuesday's call to queue them up to approve it immediately after the Specification Committee approves it.

For completeness, at this point we are waiting on the JESP, scope statements, and paperwork for committers before we can create specification projects. We require that every committer be covered by an MCCA and WGPA. Once we have the JESP in place, we get get moving on the projects for which we have committers covered by the paperwork (note that we'll have to at least temporarily remove committers who do not have the paperwork in place as we engage in this process). We're only planning to convert projects that are engaged in specification work into specification projects (e.g. the TCK project is not a specification project). 

Once approved, I plan to move the document to the jakartaee GitHub organization (preferably in a separate repository with the specification committee members as a team) in asciidoc format and will work with the Eclipse webdev team to have it published on the jakarta.ee website. From there, we can use GitHub Issues to capture our requirements for additional work.

Thanks,

Wayne


On Thu, Mar 21, 2019 at 9:10 PM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Paul White has reminded me that the Jakarta EE Working Group charter states that the Steering Committee must "review and approve the specification process."

Further, the charter states that the Specification Committee will "define the specification process to be used by all Jakarta EE specifications, and refer to it for approval by the Steering Committee."

The charter has a section on voting. Do we need to provide anything more than that?

Wayne

On Thu, Mar 21, 2019 at 1:48 PM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
To my eye, the whole #4 bullet feels out of place, worded incorrectly (it says 30 days notice, but doesn't actually talk about the duration of an actual ballot), and too tightly coupled with a specific communication channels. 

Independent of that, do we believe that thirty days is required? As was mentioned in a separate thread, we're talking about a ballot of the same people who actually author the document. That seems excessive and unnecessary. One week seems like plenty of time.

Proposal #1: we strike out bullet #4 and add bullet #2f with this text: "JESP Update: 7 calendar days"

Additionally, the Steering Committee has no formal role in either process itself or the adoption of the process. I'm thinking that we can implicate them indirectly in a manner similar to how we do profile designations.

Proposal #2: change bullet #1 to: "Any modification to or revision of this Jakarta EE Specification Process, including the adoption of a new version of the EFSP, must be approved by a Super-majority of the Specification Committee, including a Super-majority of Strategic Members of the Jakarta EE Working Group, in addition to any other ballot requirements set forth in the EFSP.

What do you think?


Thanks,

Wayne

On Wed, Mar 20, 2019 at 4:06 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
In the future, if/when we update the JESP, we require a 30 day review
before the updated version is approved, during which the updated draft
JESP will not change.

Do we expect to do the same for the first version?
_______________________________________________
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.



--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.



--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Back to the top