Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] [External] : Jakarta Data project, the project creation process, and using the project name during the proposal period

I like what is described below -- there is clear notification to the relevant committee(s) when a new proposal is created and I appreciate this is clarified.

On the actual proposal page for Jakarta Data, since Jakarta EE has yet to ratify this proposal as a proposed Jakarta EE specification, I think it might help avoid any potential pickup for confusion if the proposal page indicated that the proposal is still pending an creation ballot. If someone looked at the Jakarta Data proposal page, they might think this has been accepted already. Perhaps a simple notation: "Pending Creation Review" would suffice.

The issue, I think, is that most projects take what is on the project proposal page and then it's accepted and becomes a working project directly. In the case of specifications, there is an additional and different approval body/process that also needs to weigh in on the proposal before it can become a provisioned and operating project (or Specification Project).

-- Ed

On 5/30/2022 9:24 PM, Wayne Beaton wrote:
Greetings Jakarta EE Specification Committee

I understand that there is some confusion around a new proposal that is tentatively titled "Jakarta Data".

At this point in time, the proposal is a draft. This means that it is not publicly accessible and it will remain in this state until we're asked to open it by the team behind the proposal. While it is in this draft state, the EMO will not talk publicly about the proposal and only those individuals who are named on the proposal as project leads, committers, or mentors can access the link.

I've asked my team to reach out to the proposal team early this week to make sure that the proposal enters and progresses through the process.

Our process is basically this:
  • The proposal team assembles the proposal;
  • The proposal team asks the EMO to open the proposal for community review;
  • The EMO works with the proposal team to ensure that the proposal meets our definition of a minimally viable proposal;
  • The EMO requests approval from the EMO(ED) to post for community review;
  • The EMO posts the proposal for community review;
  • The EMO informs the specification committee of  the proposal;
  • The EMO requests approval from the PMC;
  • The EMO initiates a trademark review of the proposed name;
  • Community review (specification committee works with the proposal team to get the proposal into a state where they are ready to lock it down and start an approval ballot);
  • The specification committee and proposal team decide that the proposal is ready for approval ballot;
  • The proposal team requests that the EMO initiate a creation review;
  • The EMO initiates the creation review (this locks down the proposal; no further changes);
  • The EMO requests that the specification committee initiate their ballot;
  • The specification committee initiates the creation approval ballot;
  • The EMO completes their review;
  • The specification committee completes their ballot and informs the EMO of the result;
  • The EMO declares success on the creation review;
  • The EMO creates the project and initiates the provisioning of project resources, committers, etc.
I've attempted to capture this pictorially on EFSP Issue #68 (Graphviz requires some coercing, it's just a rough diagram at this time).

The EMO will not create a specification project (or provide any resources to the team) without having first had the specification committee approve the creation by super majority ballot.

The minimum time required for a creation review (per the EDP) and for a creation review ballot (per the JESP) is one week. In the event that the ballot takes longer than the week, the EMO will hold off approving the creation review until after the results of the ballot are available.

Managing the name of a project proposal leading up to and during the community review period is oftentimes a challenge.

It is our practice to use the planned name while the project proposal is still in the community review period. It is during the community review period that we review the trademark (this is mostly true: if something is obviously wrong, we'll work that out before community review). There is some chance that we will need to compel the proposal team to change the name during the community review period. So far, we've not needed to do this for Jakarta EE Specification Projects because the names are generally descriptive and always start with "Jakarta". We try to get the name trademark sorted out as quickly as possible after starting the community review; this is all recorded as part of the issue that the EMO creates to track the project proposal/creation process (that is, you know that the name has been approved when we tick the corresponding box in the checklist).

Note that no tracking issue for Jakarta Data currently exists (because we haven't actually coordinated with the proposal team to enter the proposal into the process).

In the event that the specification committee and the proposal team cannot come to agreement on the proposal during the community review period and does not initiate a creation ballot (or a creation ballot fails), the project cannot be created as a specification project. If the project team were to, say, retool the project and try to make a go of it as a regular open source (software) project or as a specification project under the purview of a different working group, they couldn't use the name "Jakarta" (i.e., they'd have to change the name).

Theoretically, we can stop folks from using the "Jakarta" trademark to refer to a Jakarta EE specification project that does not yet exist (has not been approved by the specification committee and created/provisioned by the EMO) by friendly request (with escalation as necessary), as using the name outside of the context of an Eclipse Foundation specification project operating under the purview of the Jakarta EE Working Group's specification committee is a violation of our trademark usage guidelines. If the Jakarta EE specification committee wants us to do that, we will.

I will review our documentation to see where we can make improvements. I'm capturing some thoughts on the aforementioned issue #68.

Wayne
--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation

My working day may not be your working day! Please don’t feel obliged to read or reply to this e-mail outside of your normal working hours.


_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee__;!!ACWV5N9M2RV99hQ!LNr5hMEPGemd5WKk5ihnoyN99HNnIT_dFx7cjV70MH1Y8dSElmPXAX3nHPch0WCUR4b5_y0QLdNc9VtTt5_zknWYfitaM-0N$

Back to the top