Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
thinking about dealing with “awaiting more information” queue/old tickets
update meeting structure to try to give time to do individual tasks related to commenting on tickets w/ dev pri decision or updates.
think more about community support; considering new ways to provide support submitting Jira tickets.
thematic ticket approach – will try to assign similar tickets together
communication btwn sub teams
Slack? Testing uses slack for internal communication during testing. Member engagement too: uses for bigger member engagement community; and during matching process to work together
I agree with moving the Instances sub-record, but I’d like to get more feedback from the group and/or community about this one. For my institution, I would be all for moving up the Instance sub-record a few spaces (maybe under Notes).
This would be useful for multi-repository ArchivesSpace users. Recommend passing.
Language of materials is required by DACS, so the collection level info should be reflective of the whole collection. Not sure how this would be scoped to be automatic, though. One option is to have ASpace run a check on all Language subrecords in a collection and create a collection-level one that matches it. This would be great for DACS compliance, but not sure how feasible. Could be nice to have something like the extent calculator to collate all the languages in a collection. Another is to explore the possibility of making some fields always spawn to the collection level when you spawn an AO. This seems like a can of worms. The ask in the comment (to have the language subrecord spawn to the collection instead of the AO) seems overly constraining. There are plenty of reasons to want the language at the AO level instead of just the collection level.
A small change that wouldn’t hinder user experience and lets ASpace be more objective. Recommend passing.
Close as is. Consider new ticket for lang calculator
Confirmed Issue and seems like something that should be easy to fix. This does seem like an issue that would be particularly frustrating for users as the information does show up in the standard PUI, but not in the PDF. Recommend passing.
I wasn’t able to replicate this issue and wonder if the recent updates were able to fix this issue.
Clarifying question - the ASpace test instance is on the most up to date version right? I was able to confirm/test both of these issues in our own test instance that is running 4.1.0