2024-03-21 TAC meeting notes

5 min

Attendance ice breaker

@Rachel Searcy

Icebreaker: What is a unusual term for an everyday object or slang expression from your region? (e.g., soda vs. pop, names for sandwiches)

New York Times dialect quiz

5 minutes

Program Update

@Christine Di Bella

3.5.0 release came out last week! The team would like to hear feedback as people install and use it.

Deadline to apply for Diversity Partnership is on 4/12. If you work with community archives or know anyone who does, encourage them to apply.

15 min

Sub-team Updates

Development Prioritization:
@Matt Strauss

Integrations:
@Elizabeth Dunham

Metadata Standards:
@Kevin Clair

Technical Documentation:
@Jenna Silver

Testing:
@Austin Munsell

• Development Prioritization:

  • 27 tickets reviewed in Feb/March

  • Created https://archivesspace.atlassian.net/wiki/spaces/AC/pages/3618701385 page

  • Working with Thimios on feature/bug submission guidance

• Integrations: Inventoried Google Drive contents and made recommendations for migration. Will migrate content mid-April at the latest in order to give Paige a chance to give her input.

• Metadata Standards: Finalizing survey on desired metadata use cases and integrations. We plan to circulate it among the ArchivesSpace community in April.

• Technical Documentation: Continuing conversations on a regular links audit.

• Testing:

  • No Testing updates since TAC/UAC meeting.

  • 3.5.0 is available for download. Thanks to all the members of the Testing team on testing this release!

5 minutes

TAC Business

@Rachel Searcy

• Thanks to Bri, Elizabeth Russey Roke, and Michelle for responses to the user listserv!

• Nomination season is April and May:

  • Looking to appoint up to 6 new members

  • Nomination deadline: April 26

• TAC Vice Chair needed for 2024-2025 term:

  • Term can be extended by a year for leadership roles

25 minutes

Conversation with ArchivesSpace Developers

@Thimios Dimopulos

@Brian Zelip

@Donald smith

We will be joined by the ArchivesSpace developers to hear about their backgrounds and their perspectives on the ArchivesSpace application and community.

Brian Zelip: Frontend Developer. Although, since the team is small everyone wears a lot of hats. Has an MLIS from Illinois. Having a librarian background is useful because it helps him to conduct "reference interviews" with users to write up bug reports and feature requests.
Don Smith: Started at LYRASIS in July 2022. Prior to that he worked at Cornell where he first started working with/on ArchivesSpace. Set up the application and did integration work. Background as a software developer.
Thimios Dimopulos: Computer science background. Started a PhD and worked at Technical University of Berlin for about a year. Moved into industry from there. Has been on ArchivesSpace team as the Technical Lead for about three months, working on all aspects of the project/application. Not as much experience with libraries and archives as Brian or Don, but is very excited to be working with this community.

Brian, did you come to your MLIS from software development work or did you do the MLIS first? He was a developer in the 1990s (working on website development) and went on to get his MLIS in the early 2000s.

How do you go about working on Jira tickets? First layer is reproducibility. Do we understand the ticket enough to replicate it in our environment? Gather as many details as we can to ensure that's the case. Recent discussion about ANW-1782 ("Read more" on the PUI). It's a good ticket because it links the visual information (screenshots) with the text describing the issue very well. All of those pieces of information are very helpful for reproducing tickets, determining how the issues happen, and what the best path to addressing them will be.

Lots of people involved in Jira tickets -- the reporters, the developers translating the requests into code, and the testers who try to replicate the issue or confirm that a fix for it performs the necessary actions. All of these people have different backgrounds, technical capabilities (workflows, coding, writing specifications, etc.)

Important to know that the time between a ticket being opened and the work being undertaken to fix it can sometimes take months or years, depending on how it is prioritized and how much effort goes into developing the ticket (writing the use case and desired behaviors, etc.) Would like to work on speeding this up but having well-written tickets helps.

Would like to also consider templates for behavior scenarios to use when developing Jira tickets. That idea isn't ready for discussion yet though, not sure what the best approach is.

Curious if there are bug reports or tickets that seem simple to archivists but that are actually complex from a developer perspective? It depends. One example of this was the new Collection Organization page that is released in v3.5.0. The old one had all sorts of funky infinite scrolling behavior. The new one looks more or less the same but works completely differently under the hood; changing resource tree behavior was a very complex and intricate process.

was cited as a very good example of a ticket from a testing perspective.

What's one thing about the ArchivesSpace code base that the developers want people to know? That ArchivesSpace is an older, larger application and there is a lot of institutional memory wrapped up in it. The data model and metadata standards on which it is built has very specific needs and is built on a very particular way of thinking about resource description -- people not in libraries/archives may not understand that. ArchivesSpace was written at a time when JavaScript was a clunkier, uglier language than it is now -- for example, the Collection Organization feature that was recently rewritten, and the Rapid Data Entry in the staff interface. So there are a lot of cobwebs that need to be dusted off in the application, but also it's kind of a miracle that we were able to make ASpace do what it does with the development patterns that existed back then.

Easy to think ArchivesSpace is a little thing because it's so easy to set it up and run it, but it's really four applications in one when you sit down and look at it. It's much bigger and more complex than it first appears when you install it for the first time.

3 min

Open Mic

2 minutes

Closing Notes

@Rachel Searcy

Virtual Member Forum: March 26 and 27

April TAC meeting: Thursday, April 18th at 1pm EST / 10 am PST