CDR Tickets

This is the translated text  -   

Actualizaciones más recientes a este resumen del PDQ

I have just edited the translation.

I have revised the new wording for English per guidance from Robin. I have asked Linda to revise the Spanish translation as well.

So we're keeping "PDQ" in the Spanish title but dropping it from the English title?

This is the text for the Spanish translation:

Actualizaciones más recientes a este resumen

As I stated in my previous comment, I asked Linda to revise the Spanish translation.

Is it safe to assume that I can use the SectionType attribute value to determine which sections need to be modified?

As usual, it will be good to group the global results by ...

I'm not sure what you mean by "usual." In all the years of global change jobs, I can only think of two cases where we split the global into separate runs, and in one of those cases the two separate runs were each run for a different ticket.

As usual, the best way to get approval for non-trivial increases in the level of effort for tasks is to present the business case to the client and request that approval explicitly.

I believe so. From what ~volker  said, that is what he is using in the filters to identify the section.

I meant what we did in the last two cases. Let me know if you want me to open a separate ticket for the Spanish global.

We run the global change jobs in test mode on multiple tiers. Frequently that happens more than once on individual tiers for a given global change request, as problems are uncovered in the implementation and/or the requirements. It would not be unreasonable to request that we double the number of jobs in order to separate out English and Spanish, though it would be disingenuous to say that this practice was "usual." Exploding the number of jobs I'd need to create by a factor of 4 (to get all the combinations of language and audience) is something that to my knowledge we've never done (so "usual" would be even more of a stretch), and would cross the boundary into territory where it would be reasonable to expect that the client should be involved in the decision as to whether the additional level of effort is justified for a given global change request, based on the arguments presented in your business case. And a business case would have to be very compelling to justify multiplying the number of test runs by dozens (as would be required if we need to have a separate run for each combination of language, audience, and summary type).

It would be possible to modify the global change harness to build in support for splitting out separate runs based on summary criteria. This would require several days of development and testing, and again, you would need to present justification explaining why this work (and the additional complexity that would need to be maintained in the software) would be cost-effective. It would even be possible to extend this enhancement to make the criteria on which the runs would be split out able to cover other variables than summary type, language, and audience, and possibly other document types.

I'm perfectly happy to do any of these things. I believe I would be able to accomplish even the most extensive enhancements to the global change harness described above in under a couple of weeks' of work. All I'm asking is that you get explicit approval from the client. 😃

I think we should proceed with running the global change the best way possible at the moment even if it means combining all the documents in one link (result) like we did in the past. It is tedious to review the XML that way but that is OK. It will only take a longer time to review them. Also, this is just one step in the process of reviewing the documents so I don't think we should proceed with making further changes to the software. I think we have gotten used to it by now 🙂. 

When we run in live mode, it is easier to identify the different groups/types of summaries to review. 

By the way, we've discussed this issue in the past when I asked you to change the global change software (results interface) to separate the results by Language, Audience, and Summary Type and you mentioned that it will be too expensive and that it will be better to run multiple globals and that was what we did in the last two global changes, I believe (even though I believe the results were not separated by summary type). Maybe we can discuss this issue again for future global changes but at this time, I think it is OK to proceed with the global the best and less expensive approach.

https://cdr-dev.cancer.gov/cgi-bin/cdr/ShowGlobalChangeTestResults.py?dir=2023-09-11_14-17-30

Thanks! It looks like the dates are not being preserved. Please preserve the dates (they are in parentheses) but don't do another test run yet until I have reviewed the error and fixed the major ones.

OK. I got the impression from the original ticket that we were to replace the titles with the new strings. Would have been good to have had this twist spelled out in at least one of the tickets. I'll hold off on another run as requested until you've finished your review.

You're right. I should have at least mentioned that as part of the requirements. Sorry about that.

Could you please capitalize the first letter of "this" so it reads - "Latest Updates to This Summary". It looks like while revising it to remove PDQ from it, I accidentally left out the capitalization. Please continue to hold off on a second test run.

Please do another test run on DEV which should now include the corrections.  Thanks!

https://cdr-dev.cancer.gov/cgi-bin/cdr/ShowGlobalChangeTestResults.py?dir=2023-09-13_14-12-36 (I hope I typed that in correctly—JIRA isn't working on the VPN, and I have to be on the VPN to do the CDR work, so I'm working on two separate laptops.) 🙁

Thanks!

This summary CDR0000258001 had both deletion and insertion markups in the dates, and this is the effect after the global:

-Changes to This Summary (

+ Latest Updates to This Summary (09/02/202202/23/2023)

This is another example with markup: Summary CDR0000257995, and the effect of the global is

-Changes to This Summary

+ Latest Updates to This Summary (10/06/2022)(04/06/2023)

I recommend that you fix those by hand. It would be virtually impossible to anticipate all the possible combinations of nested revision markup.

If you know for sure what the exact original text is that you want me to replace, it's possible I may be able to come up with a solution which will work around the problems introduced by the revision markup (as long as that text itself isn't inside revision markup).

Sure. I think we can fix these manually since we will have to go into the records and remove the markup at some point. Would it be possible to get an ad hoc query that identifies all summaries with markup in the Changes Section?

The query_term table doesn't support such a query. You'll need a separate ticket for a one-off report which will parse all of the summary documents to find which summaries have revision markup in the changes section.

Sure. I will create a new ticket for the one-off report.  Is it possible for the global to skip summaries that have markup in the Changes Section so that users will update it themselves when accepting/rejecting the markup?

We can run the one-off report and then feed the results into the global change script so it can skip the summaries identified by the report.

https://cdr-dev.cancer.gov/cgi-bin/cdr/ShowGlobalChangeTestResults.py?dir=2023-09-18_09-49-30

Looks good. Please run in live mode on DEV. Thanks!

The live run on CDR DEV has completed.

Looks good on DEV. Please run in test mode on QA. Thanks!

(They've just upgraded JIRA, so I'm going to give threading another try to see if it's been fixed.)

https://cdr-qa.cancer.gov/cgi-bin/cdr/ShowGlobalChangeTestResults.py?dir=2023-09-22_13-20-54

Please run in live mode on QA.

Done.

Please run in test mode on PROD. Thanks!

https://cdr-dev.cancer.gov/cgi-bin/cdr/ShowGlobalChangeTestResults.py?dir=2023-09-27_08-45-41

I'm holding off on the live-mode production run until instructed to proceed.

Please proceed to run the global.

I think we can close this ticket, but I am going to leave it open until after tomorrow's meeting just in case Robin and or Victoria have any feedback.

I assume you're referring to Thursday's status meeting, not tomorrow's PDQ standup (at which neither Robin nor Victoria would be present).

We agreed in today's CDR meeting to close this ticket. Thank you!