#2 just requires adding a comment with the check list items, which can be copied from the existing spec committee comment. I believe that is what Alasdair had done.
The problem with
#2 is that then we have to somehow get each Spec Project to add the checklist...
If you think about this Jakarta EE 8 process we're just completing,
how would we have gotten each Spec Project to update their PR with the
appropriate checklist? Sounds like a frustrating process...For that reason,
I vote to just do what we have been doing (#1). It's a little cumbersome,
but it works -- especially for the Spec Committee members.Option #3 would
also work if we had yet-another-template for creating another issue. I
don't think Github has the idea of a child issue, does it? Getting
the newly created issue automatically linked with the original Spec PR
would be a nice benefit.
--------------------------------------------------- Kevin Sutter STSM, MicroProfile and Jakarta EE architect e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter phone: tl-553-3620 (office), 507-253-3620 (office) LinkedIn: https://www.linkedin.com/in/kevinwsutterFrom:
Scott
Stark <sstark@xxxxxxxxxx>To:
Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>Date:
09/05/2019
09:31 PMSubject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] "on ballot close" checklist problemSent
by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx 2 seems easiest.
> On Sep 5, 2019, at 2:17 PM, Bill Shannon <bill.shannon@xxxxxxxxxx>
wrote: > > It turns out that specification project team members can not check
off their > items in the checklist we add because they're not committers on the > jakartaee/specifications project. This is going to make it harder
to > track completion of these activities. I see three ways to fix
this: > > 1. The specification project team member just adds a comment with
the items > to be checked off and the specification committee member updates
the > original checklist. > > 2. The specification project team member is responsible for adding
the > checklist as a comment, which should give them permission to
update > the checklist. Specification committee members should
also be able > to update the checklist because we're committers on the project. > > 3. We put the checklist somewhere else that both specification project > team members and specification committee members will have
permission > to update, perhaps as an issue filed against the specification
project > that would then be closed when the checklist is complete. > > #1 seems to be the default. > > #3 would have the advantage of being able to create a project board
to > track completion. > > Obviously we would not change this for this release. > > Comments? > _______________________________________________ > jakarta.ee-spec.committee mailing list > jakarta.ee-spec.committee@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe
from this list, visit > https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________ jakarta.ee-spec.committee mailing list jakarta.ee-spec.committee@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________ jakarta.ee-spec.committee mailing list jakarta.ee-spec.committee@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|