There are three separate, but related aspects to this process:
The development of the specifications themselves;
The process of ratifying and promoting official specifications; and
Certification of implementations of ratified specifications.
Open Source: The specification process should be based on open source best practices of openness, transparency, and meritocracy.
Standalone: It should be possible for an implementation of each specification to run on its own on top of Java SE, or with as small a list of additional prerequisites as possible. The Jakarta EE Full Profile (a.k.a. the Jakarta EE Platform) is backwards compatible with the Java EE Platform and will continue to include all of the specs provided by Oracle when Jakarta EE launched.
Note: the above is a goal. Obviously it will take resources to accomplish this, and we cannot state at the moment when this could be delivered.
Question: In the future, does it still make sense to require that the Platform include every spec developed under the Jakarta EE brand? I think I can imagine scenarios where we want to add new specs which are *not* included in Platform.
Question: Is the Jakarta EE Platform specifically targeted at on-premise deployments? Can anyone imagine a cloud-based deployment of the entire Platform? If this is true, should the current Java EE Platform be rebranded to the Jakarta EE Server Profile?
Note that the above significantly changes the role of the specifications. Rather than defining a single large platform, we are defining a collection of specifications which are included in a collection of profiles.
If we no longer have a single large server definition as the explicit goal, then perhaps it would be possible to consider having different profiles releasing on different timetables. Does it really make sense to insist that the Microservice Profile and the Server Profile have to release on exactly the same day? What are the implications of that idea?
Profiles: We need to have a well-defined and relatively lightweight process by which new profiles can be defined.
A Profile is simply a collection of specifications which are combined to produce a runtime, and version managed together.
A Profile may have an additional Specification and TCK beyond just those of its constituent parts.
Strawman: A Profile may be created with the support of at least three Jakarta EE Strategic Members. (The reason to tie it to them is that ensures that at least there are some vendors that want to support this profile in their products.)
Ratification/Promotion: Specification development produces some collection of artifacts. What is the process to take that collection of artifacts, ratify them, and promote them to official status?
Compatibility: All stakeholders in Jakarta EE have reiterated their desire to retain a strong notion of compatibility, tied to a logo-based certification process. Given the standalone and profile goals above, it probably makes sense to tie certification to profiles. E.g. a vendor would certify that their independent implementation would be “Jakarta EE Web Profile” certified.
Does the process support any notion of certification of any implementation of any (Jakarta EE) specification?
Does the process only support certification of implementations of profiles? Just some profiles? If only a subset, how is that subset selected?
Java SE Currency: Jakarta EE needs to have a stated position on how current it will stay with Java SE releases.
Release Cadence: Jakarta EE needs to have a stated position on how frequently releases of the specification are done. I think it is perfectly fine to say “we don’t know yet” up until we ship Jakarta EE 9 in (say) Q2 2019.