The title of the RFC was wrong (referring to LDM-503). Now it is correct.

For the convenience of anybody else looking at this, I'll point out that you can see the full set of changes relative to the currently baselined version at https://github.com/lsst/LDM-294/compare/docushare-v9...master

Per my comments on DM-16947, I still don't understand the apparent change to the remit of the DM-CCB here — we go from “scope restricted to the DM subsystem” to “focused on the DM subsystem”. This seems to imply the DM-CCB might sometimes do things that aren't relevant to DM... is that the intention?

Again per DM-16947, most T/CAMs don't have deputies, so suggesting that they delegate to them seems unfortunate.

And again per DM-16947, as of today LDM-564 doesn't describe a meaningful release plan. I think it would be appropriate (and in keeping with its title!) to convert LDM-564 into a release plan, but that work hasn't happened. Until it does, I don't think we should baseline a version of LDM-294 which asserts that LDM-564 describes a release plan.

(Why do I say LDM-564 isn't a release plan? Because e.g. the following don't correspond to releases:

• Science Platform with WISE data in PDAC
• HSC reprocessing
• Alert generation validation
• AuxTel DAQ integration functionality test
• Aux Tel DAQ interface Integration Verification and Spectrograph Operations Rehearsal
• Alert distribution validation

It might be ok to approve this document as is, if a ticket were filed and cited in the document to describe the work of converting LDM-564 into a release plan.)

It wasn't clear to me from the wording of this RFC, but according to the DMLT of 2019-01-14 “Improved makeProductTree.py” indicates there are substantive changes to the contents of the product tree, not just the mechanisms used to generate it. We should also review those in the context of this document.

John Swinbank, if a T/CAM has not deputy, and he/she will not be able to participate, the CCB will go on without his/her contribution.

Regarding making LDM-564 consistent with LDM-294, there is already an issue opened, DM-17001. I will mention it in LDM-294.

Comments from DMCCB1 has been added to the RFC-561 ticket branch.

The outstanding discrepancy between the product tree in LDM-294 and LDM-148 is now documented in DM-17448.

I suggest to consider this RFC adopted.

I discussed this with Gabriele Comoretto [X] today. I understand that the intention is that this RFC provides only an incidental update to the product tree. DM-17439 will provide the fully updated product tree which is consistent with other DM documentation (or, where that's not possible, the documents delivered by DM-17439 will point out discrepancies and explain why they exist).

On that basis, I have no objection to adopting this RFC.

The proposed changes give the CCB the responsibility to "Review and approve all RFCs prior to 'Adoption'." Appendix C of this document and https://developer.lsst.io/communications/rfc.html should be updated accordingly, and this change communicated to all of DM via a community post or similar.

I don't think that's what we mean. I thought that DM-CCB are saying that they will look at every RFC and see whether the DM-CCB need to be involved. If so the RFC will be flagged. There is no requirement that every RFC be approved by the DM-CCB (that won't stop the CCB saying "looks okay to us").

I'd suggest rephrasing that point, then, given my naive reading of "and approve." Maybe "Review all RFCs prior to 'Adoption' and escalate those within DM-CCB scope" ? or similar?

That would agree with my reading of the situation but I'd like Wil O'Mullane to comment before Gabriele Comoretto [X] makes the change.

Eric Bellm, I have re-read the text in the document (thanks Gabriele Comoretto [X]) and it says:

Review all RFCs and approves flagged RFCs prior to ’Adoption’.

which is not quite what you mention above. This is consistent with what I thought we were saying.

Tim Jenness I apologize, I was looking at the docushare-v9 diff and didn't realize it had changed in the most recent version--I agree that the current wording is fine.

Lets get the new version out and close this.