Greetings folks. Here's my agenda for today. Sorry, I'm very late with this.
Unfortunately, I haven't been able to apply the changes that we discussed yesterday yet.
Here is a
link to the document.
Today, I would like to talk about:
Votes. What sorts of things do we expect a project team to vote on and what, specifically, do we need to say about the voting process?
Note that approvals are already covered in the document: e.g. the Specification Committee must approve new project proposals, scope changes, release plans, and reviews by super majority.
Project Team. Does the Member Company's ability to appoint a representative Committer trump the Project Leadership Chain's ability to add or remove committers under extreme circumstances? (this is something that we might just leave to the grievance handling process)
Is the Specification Committee in the Project Leadership Chain (Project Lead, PMC, EMO, EMO(ED)). The EDP grants the project leadership chain the ability to compel a project to engage in a (Release) Review, add or remove committers in an "exceptional situation", and participation in grievance handling.
Do Project Leads have any special roles or responsibilities beyond what's outlined in the EDP? For example, the Project Lead is typically the main liaison between the project and the EMO, but there is no strict requirement. Do we need a requirement?
Profiles. Bill made the suggestion that we should restrict Profiles from defining any APIs of their own. This feels natural to me. However, I'm not sure that I want to bake it into the process. Do we want to make this a formal restriction, or is this something that the Specification Committee can handle via the approvals process?
I wrote that "only Compatible Implementations of Profiles that are certified by the Specification Committee may leverage the associated Brand". Bill suggested that this should not be a part of the process. We have discussed the focus of the process in the past, and I believe that it was decided that the EFSP stops at the point when the Specification Committee adopts a Specification Version. Do we have general agreement?
If yes, then should we remove the "Branding and Certification" section and the various references to "Brand"?
Reviews. Can the Specification Committee also define the minimum and maximum time periods between reviews? If a project fails to make progress at a reasonable rate, can the Specification Committee declare it to be "stalled"?
What does "stalled" mean? How long can a Specification Project be stalled? What happens next. Specification Committee can decide to cancel the current release cycle iteration and kick the project back to planning, or some other form of remediation. In the extreme case, the Specification Committee can get the Project Leadership Chain to replace the project team.
Other topics...
While I agree that these are valuable topics, I don't believe that these belong in the specification process document.
Jakarta Namespace. Restrictions on the use of the Jakarta Namespace.
From Mike:
As far as I know 'jakarta' will be used for new specs, while existing specs will continue to use the 'javax' namespace.
From Kevin:
The recent JAX-RS 2.1.1 update. If that would have been released this week, should it have used "jakarta" in it's group and artifact ids? Or, should we wait until after we declare that Java EE has successfully transitioned to Eclipse?
Jakarta NoSQL. We should discuss how comfortable we are in allowing the Jakarta NoSQL Specification Project to get started sooner than later. There are definitely pros and cons.
--
Wayne Beaton
Director of Open Source Projects
The Eclipse Foundation
