Notifications when works are added to dig queue

[apinkney0696]

I've had a couple of instances when a curator adds works to the dig queue, but doesn't email me to let me know so then I don't see the request until a few days later. Could we set something up where I either get an email notification or there is some sort of visual signifier that there are new items in a queue? Maybe something like the Digitization Queue option text in the back-end menu could get bold when there are unseen changes or something. Open to brainstorming, but it would be helpful!

[eddierubeiz]

That sounds feasible: send off an email alert when a new digitization queue item is created.

While we're discussing it: are there other points in the digitization workflow or R&R workflow, other than the creation of a request, that might warrant an email alert?

[apinkney0696]

That's a great question. I'm the only one that uses the R&R queue so I won't need an email notification for that. It would be useful for my reporting to have some sort of email that would list how many works were created and/or edited in the last week or month and by what user. I can't think of anything else at the moment, but I'll give it some more thought.

[jrochkind]

Who would get the email? Would it depend on which queue it was added to? Do we need some kind of configuration to determine who get what email? Would you want an email per-item?

Would you prefer email or an in-app alert, all things being equal?

Then you're talking about an additional email that goes out weekly or monthly with a summary report of all items? I guess this is really a different thing than the title of this issue "Notifications when works are added to dig queue". "and by what user" --> I don't think we currently track what user created a dig queue item. We could, sure. (Would we want to make users not-deleteable, to avoid that record of who created what being lost if a user is deleted? Right now, users can be deleted).

A collection of lots of new features here could end up turning into quite a bit of work, if we're adding lots of features requiring new architectural underpinnings. It might make sense to break things down into as many small tickets as we can, and also decide about how much time we want to spend on it "for now" (one week? two?), so we can work on issues until we reach that limit, then re-evaluate, or leave the others as tickets for later, etc.

[apinkney0696]

Who would get the email? I would get the email (unless I made the queue item).

Would it depend on which queue it was added to? No, independent of the queue. Do not include the R&R queue.

Do we need some kind of configuration to determine who gets what email? No, unless there is a staffing change. I'm the only one currently communicating with curators when they add things to the queue, so I am the only one that needs the notification.

Would you want an email per item? Ideally it would be the whole group of recently added items once the user is finished adding them, but I could see that being tricky. One per item is fine.

Would you prefer email or an in-app alert, all things being equal? I prefer an email, but an in-app alert is a close second option if the email proves to be difficult.

The weekly report or summary should definitely be another ticket. Let's start with the notification work, and I'll give a little more thought to the potential reporting function.

[jrochkind]

OK, that helps limit the scope, thanks!

It is a bit trickier to "batch" notifications (how do you know when they are done?). Technical detail -- it would be easier once we have a bg queuing system that supports "future scheduled bg job", ours doesn't right now!

So we can start with one per email, and maybe if that ends up being very annoying make another ticket to enhance it with some kind of logic like "wait until one hour after last queue item was entered, but don't want more than X hours to send the batch of recent ones" or something like that.

The notification feature was actually a feature that users originaly asked for before the queue system was even in use @apinkney0696 , but it was more complicated then, as there were more than one person who would hae to receive the notification, depending on queue. At that point we said "let's start using this first, and get a sense of how it's being used, and then we'll have a better idea of exactly how you want the feature to work" -- then started the disruptive pandemic and staffing changes, only to settle down now! Good to come back around!

[jrochkind]

I would get the email (unless I made the queue item).

How important is this, what if you get the email anyway? Will that be very disruptive, do you make lots of items? The system doesn't really track who's making the item right now... although there might be an easy way to implement this anyway.

[apinkney0696]

So we can start with one per email, and maybe if that ends up being very annoying make another ticket to enhance it with some kind of logic like "wait until one hour after last queue item was entered, but don't want more than X hours to send the batch of recent ones" or something like that.

This sounds like a good plan!

I would get the email (unless I made the queue item).

Not a huge deal at all. I don't make too many queue items, so I don't mind getting all of them.

[jrochkind]

@apinkney0696 This should go to your personal email address, or to something like digital@sciencehistory.org, or other?

If we use your personal address, I wonder if it's important that we keep it out of our sourcecode to avoid spammers getting it. Since our sourcecode is available to the public. We can do that if it seems wise, maybe so.

[apinkney0696]

I think it should go to digital@sciencehistory.org so if I win the lottery or get hit by a bus the next Digital Collections Librarian would get it too. Thanks!

[jrochkind]

Great. We can always change it if you win the lottery, but definitely better to have fewer thing that we need to change when that happens, if that works!