Closed jilladams closed 11 months ago
Requirements we've heard from Dave:
Requirements: Top pages menu (https://prod.cms.va.gov/admin/structure/menu/manage/popular-on-va-gov), should be periodically refreshed.
(If emails):
Menus: DaveC removed from Q4 scope.
From planning: there is some risk in S95 that this ticket will begin and not end, tbd outcomes on #15641. DaveC has signed off.
@dsasser @chri5tia Jill and I edited the ticket for clarity. Will you please review and let us know if you have any questions? cc @jilladams
@FranECross @dsasser @chri5tia I'm realizing now that this comment: https://github.com/department-of-veterans-affairs/va.gov-cms/issues/15533#issuecomment-1745885554, contains additional notes that weren't integrated in the ticket body before.
This discovery is specific to the Notifications framework. Fran, when we talked earlier, I mentioned that there are some other specific things Dave is interested in re: enforcing governance (auto expiring nodes, not allowing Full width banners to be re-published, etc.) I don't know if those should or shouldn't be included in this discovery.
Daniel and Christia plan to co-work on this ticket tomorrow, and we have BE refinement at 3:30 tomorrow. I propose we kick off BE refinement by talking about this ticket, and clean up any danglers as needed.
@jilladams Thanks for this additional information! I'm onboard with your proposal to chat about this ticket during BE refinement. Thank you! cc @dsasser @chri5tia
@jilladams @FranECross thank you both for clarifying the scope and details of this discovery.
Some questions:
When content is auto-archived
How long after creation should the FWB be archived? If it is archived the same day it expires, we would be sending 2 emails on the same day for a given FWB.
Who should be receiving the email notifications? The current framework doesn't use the author of the content, but the owner of the Section.
Does editing a FWB cause the 7 day window to reset automatically?
provide a date picker Editors can use to set a different sooner date
Does this mean that the user is unable to set a future date greater than 7 days?
Regarding expiring FWB: do we want to do any FE work to ensure the banner is not displayed after the specified expiration date.
@dsasser Thanks so much for the excellent questions! We'll be discussing this story in BE refinement today (10/31), and I may need to take some questions back to Dave for clarification to ensure we're following what he'd envisioned. cc @jilladams
Questions:
- Are emails the right mechanism? Should we instead consider automating this section to be a widget that displays most-visited pages? (Instead of a Drupal menu.) We've discussed this possibility before, no backlog ticket that I can find).
It doesn't feel like an email notification is the right system. Users/section owners are getting emails for outdated nodes once a month which is supposed to take them to a view of outdated content (nodes). An outdated block would get overlooked or mixed up with outdated nodes that the view is on. There are so few nodes that there might be an easier way or if we do this we would need to build a new view and a new custom module. I am still thinking of alternative ideas.
- If emails:
- How frequently should this menu be updated / should emails send?
- For menus: unclear, without Editorial Workflow, but I believe a Public Websites team member created this menu and would receive these emails until another Editor modifies it.
I need to look into this further and need more understanding about the the menu piece.
This discovery is specific to the Notifications framework. Fran, when we talked earlier, I mentioned that there are some other specific things Dave is interested in re: enforcing governance (auto expiring nodes, not allowing Full width banners to be re-published, etc.) I don't know if those should or shouldn't be included in this discovery.
@chri5tia re your comment:
I need to look into this further and need more understanding about the the menu piece.
There is no menu requirement. This requirement was removed a few days ago. The active ticket description defines the current state of the ask.
a new custom module would be needed
That is speculative. We could add any additional work to the existing va_gov_notifications module.
I wonder how our existing system compares with this experimental module, which we don't seem to be using: https://www.drupal.org/project/outdated_content
This module works only with nodes, so it is a non-starter for our needs.
for auto-archiving, we can look at this D7 module for ideas: https://www.drupal.org/project/autoarch
I've discussed with the team if auto-archiving is currently in place, and it is not. However, the Scheduler module, along with the Scheduler content moderation integration modules are probably the best place to start, since they have widely used D8 versions, and Swirt and myself have used them in the past for this purpose.
@jilladams @FranECross
Per these questions:
If included: we need to update ticket body again to be explicit about that, based on the notes in the comment I linked above. If excluded: we need a separate ticket to cover those pieces.
And considering Christia's note above, we have identified these as future discovery and implementation tasks which should be carved into separate tickets.
@dsasser Thanks for clarifying about the menu. Scheduler module is a nice suggestion.
That is speculative. We could add any additional work to the existing va_gov_notifications module.
I meant "new module" as in new custom module functionality that doesn't use the existing module functionality. Whether it's there or somewhere else is out the scope of what I intended to communicate.
Draft plan: I updated to add 2 things: https://docs.google.com/document/d/1h7oCFheAVZ8rhlmyE37GZYfGpE5rKS15lNIBIFgn5P4/edit?pli=1
@dsasser can you review those sections and just make sure I didn't misstate anything, or if some of the questions have been answered, move them as needed?
@FranECross we could use a new discovery ticket to cover research around the auto-archiving concepts here. If we can get that up and pre-fined, we could pull it into next sprint.
I think we need to have a big conversation with Dave around this. Not certain if that should start with Product only, or include Daniel. @FranECross would be interested in your thoughts based on our conversations thus far / Daniel's doc.
VACMS-15533_ Discovery notifications framework.pdf
@jilladams I think chatting with Dave sounds great. I think having Daniel present to provide intel on why things are a heavy-lift if Dave wants details during the meeting. Here's a first draft of AC for a new story around Notifications & Auto-archiving for both banners and blocks of info, split out into two separate sections. Feedback is always welcome.
Auto archiving and notifications for banners_blocks.pdf
cc @dsasser
From scrum this morning: @FranECross will go ahead and cut the new Discovery tickets with the proposed ACs from comment above.
@dsasser FYI that we discussed findings a little with Dave today. From that conversation:
Next steps here:
For this ticket's purposes, we can close, but: will leave that to @FranECross in case we need to further discuss anything here first.
User story: Full Width Banners
AS AN Editor I WANT to select the initial period for display of my full-width banner, up to 7 days SO THAT site visitors always get a relevant experience.
AS A VA owner I WANT aging banners to expire SO THAT site visitors always get a relevant experience.
User story: Homepage blocks
AS A Home Page Editor I WANT to be notified when my content is old SO THAT site visitors always get a relevant experience.
Q4 intentions
Create notifications for:
Full width banners (content type): Dave has requested that we set an expiration date for these nodes, default to 7 days from creation, but provide a date picker Editors can use to set a different sooner date. And, that the CMS sends emails relative to the date an Editor sets as the end date, on the following timing:
Homepage promo blocks. (Blocks are not a content type): We don't know what constitutes old, but at some frequency (monthly?)
~Top Pages Menu (does not currently use Editorial workflow)~
The current mechanism for Notifications is default monthly send. The full width banners requirements suggest one-off emails on a specified timeframe, rather than monthly. This is potentially the biggest leap in the framework that will need to be made.
CMS team created a Notifications framework that is currently being used to send notices to VAMC and Vet Center editors. We need to understand how it works today, in order to understand what work may be needed to use it for our Q4 intentions.
Previous implementations / SMEs
VAMC notifications: Edmund created the framework and managed first usage for VAMCs.
Facilities: Vet Center notifications: Steve Wirt made the email template responsive, and managed use for Vet Centers.
ACs
8 points timebox to check in re: more time needed.