[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jakarta.ee-spec.committee] Plan vs. Progress ballot?
|
Moving this over to the Committee list --
Refreshing myself about the EFSP
state diagram -- shouldn't we be requesting "Progress
Reviews" from Specification Project teams that have not held
a ballot within the past twelve months (or possibly if they have
revised some previously agreed milestone schedule)? (I'd suggest
Config might be in the twelve months since last ballot category.
I'm not certain RPC is, but we can certainly ask for a Progress
review if we like)
If we are going to adopt a process that inserts a Plan Review, we
probably should work out and codify that process. Currently,
neither ESFP 1.2 or 1.3 show such a sequence.
I'd be perfectly happy codifying this any way we think is
appropriate. We could
- Codify that the Proposal must include a proposed Plan before
the Creation Review will be taken up for Ballot -- OR,
- we could create a new state diagram that routes new project
proposals to include Plan/Plan-Review ballots explicitly.
Probably there are other approaches as well.
I think the goal should be, clarity about what and also when.
Perhaps we want to include other things. The more detail we can
provide, the easier it should be for community members to create
new successful proposals.
-- Ed
On 7/20/2022 9:40 AM, Ivar Grimstad
wrote:
Thanks, David!
Yes, I agree. The RPC description is what we should strive
for.
Regarding Config, I have twice brought it up in their
weekly calls that they should prepare materials and request a
plan review. But so far, I haven't gotten anywhere. It would
be great is other specification committee members also nudged
them a little. They have decided to pause the calls until
September due to summer vacations, but then we should
definitely get a plan from the project.
For RPC, I don't think there has been any activity at all
on the mailing list. So that is more a PMC issue to reach out
and see if they are planning on getting something going. I
will do that, and let's see what the response is.
Ivar
+1 (Tomitribe) with the explicit note we will vote -1
on any release reviews if we skip a plan review and we
think the project description should have more detail.
Note, we have not filed a plan review for Config (14
months old) or RPC (6 months old).
Here is example of a very good project description /
creation review:
It would be ideal if we continued that level of
quality.
-David
Hi David,
Note that this is the creation review for a
specification project. They will be
required to file a plan review for a specification
(version) later.
Stating the Java version on the main page of a
spec project doesn't make sense, since there will
be different versions for different versions of
the specifications.
The items you suggest should be provided for a
spec version page, e.g /data/1.0
For now, I think we should let the project
gather, discuss, and then decide how to proceed. A
scope statement is enough at this stage.
Ivar
Since
there typically is no plan review for new
projects, can we get more than two sentences
for the description?
Shoot
for 2 paragraphs. Some ideas that could
provide more detail:
- what specifications you intend to build
upon/leverage,
- anticipated java version
- what goals might you approach early and
what you think might be out of scope for now
or forever
- who would be ideal implementors (give your
best sales pitch)
There's
been good discussion, so it should be easy.
--
David
Blevins
Greetings Jakarta EE
Specification Committee.
I need your vote to approve and ratify
the creation of the Jakarta Data
project.
The JESP/EFSP requires a successful
ballot of the Specification Committee in
order to finalize the project creation
(as defined in the EFSP).
The relevant materials are available
here:
Per the process, this will be a
seven-day
ballot, ending on
July 26, 2022,
that requires a Super-majority positive
vote of the Specification Committee
members (note that there is no veto).
Community input is welcome, but only
votes cast by Specification Committee
Representatives will be counted.
The Specification Committee is composed
of representatives of the Jakarta EE
Working Group Member Companies (Fujitsu,
IBM, Oracle, Payara, Tomitribe,
Primeton, and Shandong Cvicse Middleware
Co.), along with individuals who
represent the EE4J PMC, Participant
Members, and Committer Members.
Specification Committee representatives,
your vote is hereby requested. Please
respond with +1 (positive), 0 (abstain),
or -1 (reject). Any feedback that you
can provide to support your vote will be
appreciated.
--
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
--
Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation
Eclipse
Foundation - Community. Code. Collaboration.
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
--
Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation
Eclipse
Foundation - Community. Code. Collaboration.
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec__;!!ACWV5N9M2RV99hQ!MZGdJmqiS7jtG0txgtLZANCaR7JxQnjeZrlrIUIXdnn5HkOh4J2_MTadWUKhQ531musN-EMSrubaAlPONr21gnQeCBmAHFa0ng$