...
Item | Who | Notes | Decision | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Announcements and discussion | Maggie | How to publicize new Ready for Community Developer status?
Please also fill out strengths in the Dev. Pri. roster! This helps us identify areas of specialization need: Development Prioritization subteam | |||||||||
Old business tickets | |||||||||||
| Maggie (for Lydia) | Selfishly, I would like this to PASS | |||||||||
| Maggie (for Lydia) | This ticket is super old, vague, and probably very difficult to manage. LT proposes to CLOSE this ticket. | |||||||||
| Maggie (for Lydia) | This ticket is super old, vague, I don’t know that we even do deaccession records (besides an event). LT proposes to CLOSE this ticket. | |||||||||
| Patrick | Need more contextual information about what would "look better". Also need clarity on on the "add into the Edit Basic Information the Resource or Accession number and links back to the component". Do they just want links back to the linked resource/accession? No current update from Kari. | |||||||||
| Patrick | Ideally pass. Not exactly sure what's causing this, but can confirm that this bug appears. From what I can tell by researching <dao> structure standards, xlink attributes are technically not allowed. Would need to speak to development team about the best way to correct this. | |||||||||
| PatrickWould support closing this ticket. Additionally, do not fully know what the purpose for this work would be | From Mark Custer: I think the primary use case for this is MaRC exports. Right now, there is no way for ASpace to create a MARC record that does not have a 1xx field but does have at least one 7xx field. Such a record is certainly valid in MARC, though. So, to illustrate the issue, if you import a MaRC record into ASpace that has no 1xx field and one 7xx field, you wind up with one agent linked to the record as a creator. Once you export that record, then you wind up with a MaRC record with that agent in the 1xx field. Of course, if such a feature were added to ASpace (and that depends on how closely aligned ASpace wants to be with MARC), then I suspect that all of the creators already attached in the first position would need to be updated during a database migration to include the "primary creator" data attribute. Would like someone from DevPri team to give thoughts on whether this is a good value-add for work. | |||||||||
Reviewing Ready for Development tickets: Bug kanban board (58 tickets total) | Each person has been assigned 8 tickets from the bug kanban board that currently have the Ready for Implementation status. Please review the tickets assigned to you and make recommendations on:
We’ll discuss candidates for Ready for Community Developer as a group, and can also address any secondary concerns that arise during the ticket reviews. | ||||||||||
Patrick |
| ||||||||||
Terra | |||||||||||
Alicia | |||||||||||
William | |||||||||||
Julia | |||||||||||
Edgar | |||||||||||
Maggie | |||||||||||
Next meeting | All | Did this method work well? Should we do anything differently for June meeting? |
...