When considering the work for the term, especially in the lead up to drafting the term workplan, it is helpful to understand that term activities tend to be made up of routine work (that work which repeats and is considered the core of the work) and new projects and initiatives (or discrete projects taken on during term). Balancing these two types of work is the goal of the workplan and the challenge of subteam leadership.

To define routine work, start with the subteam charter or description, which is recorded on the parent page for each team: https://archivesspace.atlassian.net/wiki/spaces/AC/pages/2889678883

To define project work, start with the prior term’s retrospective.

Start of Term and Monthly Activities

Ensure Access and Permissions on Jira

Metadata Standards Subteam-related tickets are tracked on a Jira board. This board brings together all tickets with the metadata_standards_subteam label and lays them out visually, employing three Subteam-specific labels about the status of a metadata-related ticket to show where they are in a workflow: 

• Under Review (the label is metadata_under_review): Tickets being reviewed by the Metadata Standards Subteam in this month's meeting

• Reviewed (metadata_reviewed): Tickets which have been reviewed by the Metadata Standards Subteam (comments should indicate the decision that was made or further clarifications needed)

• Documentation Needed (metadata_documentation_needed): Tickets that (once implemented) will require updates to metadata documentation or mappings

The board is based on a filter that includes any ticket tagged with metadata-subteam related labels (including completed tickets). There is also a filter that shows only those tickets which require some kind of documentation updates (using the metadata_documentation_needed label).

Subteam leads should have access to edit the board, the filter that it is based on, and the two related filters. They should also have the ability to update Jira tickets: change labels and ticket statuses. If subteam leads do not have this access, they should reach out to program team staff to have these permissions added to their Jira accounts.

Standard Ticket Review Workflow

The subteam leads should reference the board and the previous month’s agenda/notes at least two weeks before every monthly meeting to determine what new tickets need attention from the subteam or which continuing tickets remain to be resolved. Add the label metadata_under_review to any tickets to be reviewed in that month’s meeting, and add them to the agenda/notes page for that month’s meeting (template). Assign tickets to subteam members (one subteam member per ticket, ideally being conscious of various subteam member strengths as well as how many tickets they have been asked to review in the term), send the agenda out to the subteam, and ask the assigned members to review and add brief notes about the ticket to the agenda before the meeting. All subteam members should also review the discussion topics (and related documentation) and briefly review the tickets before the meeting).

During the meeting’s allotted time for ticket review, subteam members who reviewed tickets will lead discussion of the ticket. A designated note-taker will add notes on decisions made by the subteam to the monthly meeting agenda/notes. 

After the meeting concludes and the notes have been updated, subteam leads should add comments synthesizing subteam discussion to the Jira tickets, and for tickets which have been reviewed update the labels and status: remove the metadata_under_review label, add the metadata_reviewed label, and update the status as appropriate to Awaiting More Information (contact the appropriate person who can share more information), Awaiting Prioritization (to send it to DevPri for their review), or Ready for Implementation (to send it to the queue for developers). 

As appropriate, add the metadata_documentation_needed label at this point or later in the process to flag any tickets for eventual documentation/mappings updates once work is completed. 

Labels are located on the right side of the ticket under Details; click on the Labels area to add or edit:

Open

Prompt Dev Pri about using the Metadata Tag

Development Prioritization should  tag metadata-related tickets with the metadata_standards_subteam label to ensure that they appear in Metadata Standards board (occasionally program team staff may get to newly-created tickets first and add this label). This inter-team dependence must be maintained from term-to-term and there is a risk that changing leadership may lose sight of this task. This is therefore a prompt for friendly outreach at the beginning of term. You can find the current lead of the Dev Pri group by navigating to the term-specific roster here:Development Prioritization Sub-Teamhttps://archivesspace.atlassian.net/wiki/spaces/AC/pages/38502430

Sample text, edit at will:

I am writing today on behalf of TAC-Metadata Standards to make a request to our few Council members regarding the use of the metadata_standards_subteam label. Since it is the beginning of a new term, TAC-MD is sending a friendly reminder to Dev Pri to use this tag for Jira tickets that involve the either the ASpace data importers or exporters so that Metadata can be aware when changes, minor or major, are anticipated. Thank you so much for continuing to help us monitor the standards landscape in ASpace!

Subscribe to Github File Watcher

Please navigate here for information on how to set up GitHub File Watcher, which is a service that will email you anytime changes are made to specific files inside any public GitHub repository that you configure. This allows any member of the Metadata Standard Subteam to be alerted to changes and then assess whether those changes need follow-up action from the team. It is suggested that the Lead set up this tool for themselves any files relevant to the team and to encourage any other member that is interested to do the same.

Some paths relevant to the TAC-MD as of this writing:

backend/app/converters/ead_converter.rb

backend/app/converters/lib/marcxml_bib_base_map.rb

Define Routine Work

Draft section:

Defining “Monitoring the archival metadata landscape for changes.“

Pretend a freshly minted post-grad has joined TAC-MD. How would you suggest someone “Monitor the archival metadata landscape for changes?“ Some basic advice here would be welcome, including listservs to subscribe to.

SAA section listservs for TS-EAS, Description, and Metadata and Digital Objects sections (SAA members only)

In the Loop newsletter (SAA members only)

SAA standards portal: https://www2.archivists.org/standards

MARC news and announcements: https://www.loc.gov/marc/marcginf.html#naa

Maintaining ASpace data maps.

Wise to link to these?