2019-05-28 Meeting notes
Date
May 28, 20191-2:30pm EST
Call info:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/619789499
Or iPhone one-tap: US: +16468769923 (619789499#) or +16699006833 (619789499#)
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 6468769923 or +1 6699006833 or +1 4086380968
Meeting ID: 619 789 499
International numbers available: https://zoom.us/zoomconference?m=lfJNhr4XU-I8p7oRrXXwebNlh57Ti7kq
Participants
@Lora Woodford
@Christine Di Bella
@Laney McGlohon (Unlicensed)
Julia McGinnis (absent)
William Modrow (absent)
@Lydia Tang (Unlicensed) (regrets – in Japan and China! )
Goals
Take care of old business tickets
Review Ready for Implementation tickets from the bug kanban board in terms of suitability for Ready for Community Developer status
Links
Kanban boards:
New bug reports: https://archivesspace.atlassian.net/secure/RapidBoard.jspa?rapidView=15
New feature requests: https://archivesspace.atlassian.net/secure/RapidBoard.jspa?rapidView=16
ArchivesSpace sandbox: http://test.archivesspace.org/
Discussion topics
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 Sub-Team |
Survey
|
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. MH notes: Cory’s recent note indicates that this ticket is a duplicate to in-progress agent work. | Christine can link the ticket to the work going on for Agents. Close. | |
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. MH notes: Can add 0 to many external docs to deaccession event. Deaccession sub-record does not allow any external docs to be attached. | Close. | |
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. | Close. Leave a comment that closing the ticket because not enough information. If anyone feels strongly about it, they can re-open the ticket and provide more information. | |
ANW-805: EAD validation errors for dao audience attributeClosed-Complete | 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. | Leave comment asking for a suggestion of what it should look like. Awaiting More Info. If a good answer comes in, then we can pass or close based on that. |
Patrick | 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. | Not addressed in Agent specification. A known issue for users who want to use MARC exports seamlessly. Migration issue makes it a larger effort. Building it in for now going forward would be easy. Could say no migration, and people can clean up their data if it is important to them/they use MARC exports. Or migration could take what it does now – take the first Agent as 1xx. Could use more info about UI expectation and edge cases. More spec’ed out. Tag people (Rachel Searcy, Sue Luftshein, Cory Ninmer) on the listserv and email on the listserv. Linking 784 and 504. Change status 784 to Awaiting More Info. Not ready to be worked on because of other pending issue. | |
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? | Ready for Community Dev approach felt streamlined. Framework worked well. Any tickets moved out of Ready for Implementation is a win. Plus, making it easier for others to participate in coding. June: Keep going through remaining Ready for Implementation tickets from bug kanban board, may start going through Ready for Implementation tickets from feature requests board. |