Greetings PMC.
As we discussed on our last call, the specification process requires that all specifications have a scope statement. Likewise, the Eclipse Development Process requires that all projects have a scope statement. As we move forward with the implementation of a specification process, we need to convert the placeholder scope statements that we have in place now.
Note that, strictly speaking, the Eclipse Development Process and Eclipse Foundation Specification Process both demand that any change in scope be preceded by a successful restructuring review. It would be reasonable to argue that we're not actually change the scope of any of the projects, we're just putting our existing understanding into words (so a review may not actually necessary). That notwithstanding, I believe that we better serve the community by wrapping this update with a renaming effort into a formal review that concludes this open and transparent process.
So... the process will be (1) gather information; (2) engage in the review; and (3) change the name and scope in the project metadata.
Ivar and I are working out some examples before we bring this to the project teams and community. I'd like to take a minute to discuss the criteria. Once we have consensus, I'll present this to the Jakarta EE Specification Committee to ensure that they're on board.
First, the scope statement is for both the specification project and the technology area. I had originally though of separating them, but figure that is too complicated.
e.g.
"Jakarta Persistence provides a specification document, API, and TCK that describes the management of persistence and object/relational mapping in Java(R) environments."
So... "specification document, API, and TCK" describes the scope of the project (in that the production of these artifacts is in scope, and "management of persistence and object/relational mapping in Java(R) environments" is about the specification itself. My sense is that this is far more natural than trying to separate the two.
Note that I am not asserting that the example is a perfect statement of scope for Jakarta Persistence. I fully expect to improve on this as we engage the project team and otherwise move through the process.
There will, of course, be corner cases. It will, for example, probably make sense for the the "Stable APIs" project to have multiple separate statements.
The scope statement should be aspirational, rather than a reflection of the state at any point in time. In that regard, I expect that most of the scope statements will include "specification document, API, and TCK" independent of where the TCK currently lives. That management of the TCK is something that the project eventually intends to assume, means that it is in scope.
Similarly, projects like Jakarta Mail which is, as I understand it, tightly coupled with a compatible implementation likely have an aspirational scope statement that excludes that implementation. That, of course, assumes that separating the compatible implementation is desirable and possible in some not-too-distant future. If we're prepared to just leave it as it is forever, then we should include it in the scope.
Comments welcome.
Wayne
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
