The Metadata Standards subteam supports the ArchivesSpace community by taking a transparent and proactive approach to documenting the metadata standards used by the ArchivesSpace application and monitoring the standards landscape. We facilitate this by:

• Documenting which metadata standards ArchivesSpace adheres to.

• Maintaining ASpace data maps.

• Monitoring the archival metadata landscape for changes. 

  • Create JIRA tickets to update standards-related aspects of the application.

  • Make recommendations to TAC/UAC/ASpace Program team when changes related to metadata standards may require the focus and dedication of a working group to scope out things such as the changes needed, dependencies, timelines, etc.

• Monitoring ASpace user group listserv for standards-related issues and help answer questions, note issues, create JIRA tickets, etc.

• Advising other Council sub-teams on matters concerning metadata standards. For example:

  • Development Prioritization sub-team may send standards-related tickets to the Metadata Standards sub-team for comment.

  • Advise Tech Docs when updates to the technical documentation are needed.

Metadata Standards expects to contribute in a proactive role concerning the implementation or support of external standards in ArchivesSpace, meaning that the subteam should be tagged on any tickets and included in any discussion or final decisions about whether, how, and to what degree to support an external standard in ArchivesSpace, including changing the mapping for either importing or exporting those standards.

The Technical Documentation sub-team (TechDocs) facilitates maintenance and enhancement of all ArchivesSpace technical documentation.

This page is intended to document the internal processes of the Technical Documentation sub-team to facilitate continuity between terms.

Maintain ArchivesSpace technical documentation in tech-docs Github repository

• Collaborate with ArchivesSpace program team to prioritize, assign, and work on issues in the TechDocs Jira board.

• When new versions of ArchivesSpace are released, review release notes, providing edits/suggested changes to developers.

• Identify documentation maintained by other sub-teams, link to it as appropriate, and avoid duplication of effort.

Solicit feedback and contributions from the community

• Encourage ArchivesSpace community to submit issues regarding documentation directly to the tech-docs repository or contact sub-team members via email to suggest improvements.

• Monitor listserv for issues for which further documentation would be helpful and file an issue in the TechDocs Jira board to be prioritized and assigned.

• Review, manage, and promote Awesome ArchivesSpace.

Perform outreach and make ArchivesSpace community aware of TechDocs

• Promote TechDocs work and facilitate broad community knowledge by linking to relevant portions of documentation in listserv responses and other communications.

• Suggest the inclusion of relevant links to TechDocs within documentation maintained by other sub-teams.

TechDocs includes members of the Technical Advisory Council, as well as members of the ArchivesSpace Program Team. Meetings are also open to Lyrasis developers who support ArchivesSpace.

The Vice-Lead is responsible for taking notes during the meeting and covering for the Lead if they are unavailable. The Lead is responsible for orienting new members, facilitating access to the GitHub repository and Slack channel, scheduling meetings, creating agendas, and writing the quarterly reports on sub-team activities. Both the Lead and Vice-Lead write and submit the retrospective at the end of each term. The Vice-Lead assumes the role of Lead after 1 term and Leads themselves serve 1 term - totaling 2 years of leadership in total (1 term as Vice-Lead, 1 term as Lead).

In addition to communicating asynchronously via the TechDocs Jira Board and emails, members of Techdocs and the ArchivesSpace program team can use the Slack channel.

The primary source of technical documentation for ArchivesSpace is the archivesspace/tech-docs Github repository (tech-docs repo). A public, more user-friendly version of the content is available at https://archivesspace.github.io/tech-docs/.

The technical documentation is openly accessible and does not require ArchivesSpace membership, in contrast to the User Manual available through the ArchivesSpace Help Center. The two sets of documentation were created and are maintained in different environments due to this difference in access, as well as their different audiences.

All TechDocs sub-team members should have write permissions to the tech-docs repository and assigned to the archivesspace/tech-docs team. Before the beginning of each term, the sub-team lead should email Christine DiBella with the Github handles of the sub-team members to facilitate access.

1. Select the menu icon in the upper left-hand corner, and select archivesspace/tech-docs under the “Teams” section:

Open

2. Select the green “Add member” button.

Open

3. Type ahead for the person’s GitHub username. Only people already added to the archivesspace team in GitHub can be added here. Email Christine if anyone is not already a member of that team.

4. Subteam members are encouraged to enable notifications from the repository via the Watch functionality.

Open

5. Subteam members responsible for overall repository maintenance (i.e., subteam Leads and Vice Leads) should be assigned to the “Maintainer” level role. Within the techdocs Team page, select the user(s) with the checkbox, click the “1 member selected” icon, and “Change role.”

Open

Open

In the context of Git repositories, a pull request is an event where a contributor asks the repository’s maintainer to review changes on an independent line of development that they want to merge into the main branch.

• Pull requests to the repository should be reviewed and merged promptly.

• Straightforward pull requests with no conflicts should be merged by the subteam Lead, or delegated to other TAC members if needed.

• Pull requests with branch conflicts or content that warrants review by a developer can be identified by the Lead for a program developer to merge.

• Draft pull requests cannot be merged, and can remain in the repository.

1. Navigate to the techdocs repository.

2. Select “Pull requests.”

Open

3. From the list of requests, select the specific pull request to merge.

Open

4. Merge the commit(s) into the base branch by selecting “Merge pull request” (if this option is not shown, select “Create a merge commit” from the drop down menu)

Open

5. If prompted, type a commit message.

6. Select “Confirm merge.”

Open

User Documentation

Purpose of Subteam: To create and maintain an array of ArchivesSpace Documentation in the ArchivesSpace Help Center that provides instruction to users at member organizations.

Major activities of Subteam:

• Update and maintain ArchivesSpace Help Center pages

• Create Help Center documentation for newly developed ArchivesSpace functionality

Skills:

User Documentation offers team members the opportunity to develop or expand familiarity with ArchivesSpace functionalities while honing their copyediting and technical writing skills.  Working as part of a collaborative team, members analyze and update existing Help Center documentation, ensuring that information is accurate and presented in a clear, well-organized manner for a general archival audience.  Members also create documentation for new ArchivesSpace features in conjunction with system version releases, often working on tight deadlines.

Team members should have familiarity with or a willingness to learn how to use Confluence, the web-based wiki software used to manage the Help Center documentation and much of the team's administrative work. 

Workload:

The User Documentation Sub-team meets once a month for an hour.  Between meetings, members update Help Center documentation and review edits made to pages by other team members.  Work is managed using Confluence, email, and Google drive.  The estimated average total time commitment is approximately 3-4 hours per month.

UAC Members:

• Joanne Archer

• Elizabeth Delmage, lead

• Kelly Francis

• Matthew Gorham

• Amanda Greenwood

• Lindsay Wittwer

The Usability Subteam was created in 2019. The subteam develops functional and practical recommendations for the program that streamline navigation, clarify the visual layout, identify accessibility improvements, and enhance the ease of use of the existing program for both the staff and public interface of the ArchivesSpace software application. 

• In collaboration with the Development Prioritization subteam, investigate and provide supplemental documentation in the form of comments, wireframes, and specifications to existing “usability” Jira tickets in the Bug and Feature Requests boards.

• Solicit community feedback as necessary including listserv posts, community discussions, and surveys.

Guiding documents/resources:

• ArchivesSpace Development Roadmap

•  July 2016 Development prioritization survey and Fall 2019 Survey

The Usability subteam meets as a full group for an hour once a month and conducts business outside of meetings via email. Meetings range from 30-60 minutes.

Average time commitment for members is approximately 3-4 hours per month.

The average time commitment for chairs is approximately 4 hours per month (including the monthly meeting time).  The chair selects and assigns the tickets, facilitates the meetings, routes the tickets on the kanban boards, and prepares quarterly reports to the UAC chair as requested.

Purpose of Subteam:

To provide outreach and community support for the ArchivesSpace member community, in collaboration with the Community Engagement Lead.

Major Activities of Subteam:

These outreach and support efforts are primarily achieved through managing the administration and activities of the ArchivesSpace Member Match Program, begun in 2021.  Sub-team members rotate through hosting duties for regular online events, which are limited to Member Match participants and considered a benefit of participation.  Sub-team members are also particularly encouraged to join short-term initiatives that support member needs and interests, such as the Virtual Member Forum, Annual Member Forum,  and ad hoc task forces.

Skills:

• Community outreach and engagement

• Collaboration and teamwork

• Program management

• Exposure to the following tools -- Confluence, Google Docs, Zoom, Airtable, Slack 

Average Workload:

The Member Engagement Sub-Team will generally meet once a month for an hour. Business outside of meetings will primarily be conducted via email, Confluence, and Google Drive. Sub-team members may also meet in smaller groups for working meetings, when needed. Sub-team members rotate through hosting duties for regular online events, which are limited to Member Match participants and considered a benefit of participation;  other sub-team members are encouraged, but not required, to attend all such events.  The estimated average total time commitment is approximately 3-4 hours per month.

Members 2025-2026:

• Christine Liebson, Lead

• Karen Trop

• Jaime Margalotti

• Kolbe Resnick, Vice Lead

• Jessica Crouch, ArchivesSpace Community Engagement Lead

The Development Prioritization subteam is comprised of members from both the ArchivesSpace User Advisory and Technical Advisory Councils. This subteam was created in January 2016 following a decision to split the former Features Prioritization and Testing team into two separate groups.  In collaboration with the ArchivesSpace Program Team, the subteam prioritizes feature requests and bug reports for developers working on future releases of the ArchivesSpace program and occasionally may make recommendations on creating Task Forces to holistically address specific areas of the program for improvement.

The prioritization process:

The lead reviews Bug and Feature Request Jira tickets and assign tickets to subteam members to investigate and discuss at the subteam meetings.  Each meeting tries to address a mixture of Bug and Feature requests, from both the “Awaiting Prioritization” and “Awaiting More Information” queues. In preparation for the meeting, subteam members:

• Verify whether the issue still relevant and whether it should be addressed locally or within the actual program

• Comment on the ticket/share it with the ArchivesSpace member listserv to gather additional clarification/community input when needed

• Confirm or reevaluate the priority ranking of the ticket (in order from least to greatest - these descriptions are suggestions for applying more consistency with the priority rankings):
  
  

  • Trivial: a really small improvement for a specialized area of the program with limited impact and little time-constraint

  • Minor: an improvement for an area of the program with little time-constraint

  • Major: a large improvement for the program with some time constraint

  • Critical: the program currently is not working and impacts users in regular use 

  • Blocker: the program currently not working, dramatically impacts users in all use, and must be addressed immediately.

• Confirm or suggest tags for the tickets (this helps with grouping related tickets for development projects)

• Document their routing recommendation (“Awaiting More Information,” “Ready for Implementation,” "Ready for Community Developer," or “Closed” if the ticket is declined) in the monthly meeting agenda

During the Dev. Pri. meetings, the subteam discusses the tickets and their recommendations and route them to their next status. The subteam member assigned to the ticket will follow up on the ticket with explanatory comments on the decision and the subteam lead updates the ticket status.

During the course of investigating a ticket, the subteam may determine that the original text of the ticket should be revised to better reflect the committee’s decision about how to move the issue forward in a way that facilitates development. In such cases, the assigned subteam member should edit the ticket accordingly. A brief indication of the changes should be included in the ticket comment.

Factors influencing the prioritization include

• Demonstrated community interest in the issue by supporting votes and comments on the tickets and/or discussion on the member listserv and Google Group

• Sufficient specification (see the How to Request a new Feature/How to Report a Bug documentation)

• Developer capacity and expertise

• Priorities outlined in the Development Roadmap

Average Workload:

The ensure that Dev. Pri. discusses enough tickets and has time for discussion, the monthly meetings are 1.5 hours long.  

The average time commitment for subteam members is approximately 2.5 hours per month (including the monthly meeting time).  Each person is usually assigned 3 tickets to investigate for each meeting.

The average time commitment for the subteam lead is approximately 3.5 hours per month (including the monthly meeting time).  The lead selects and assigns the tickets, facilitates the meetings, routes the tickets on the kanban boards, and prepares quarterly reports to the UAC or TAC chair as requested.

This is a cross-council subteam that includes members of the ArchivesSpace User Advisory and Technical Advisory Councils. The Testing subteam was created in January 2016 following a decision to split the former Features Prioritization and Testing team into two separate groups. The subteam coordinates work via email and only holds meetings when necessary. The preference for cross council teams is to have the lead and vice-lead be from different councils

Testing occurs on an ad-hoc basis as JIRA issues become ready for testing or prior to any release. JIRA testing is targeted and tests only the specific issue(s) selected for testing. Full suite testing prior to a release involves testing the standard operations and workflows in ArchivesSpace.

Each issue is assigned randomly to two members of the testing team. The testers then review the issue to understand the feature request, change or fix and then test - typically in the sandbox at test.archivesspace.org. If the test is successful, then each tester will add a comment to the issue stating that the testing was successful. If the test is not successful, each tester will comment on the issue with details about how the test failed. They should include screenshots if applicable and as much information as needed so that the developers have a clear picture of the problem.

Lifecycle of a JIRA ticket:

Open

Prior to a new release, each main section of the application is tested to ensure that any changes to ArchivesSpace do not break existing workflows. These main sections typically represent the top level areas of the application - Resources, Accessions, Archival Objects, Reports, User Management, etc. Again, each section is randomly assigned to two testers. A worksheet is provided to each tester so that they can track the results of their testing. Each tester completes the portions of the worksheet assigned to them and indicates whether the tests were successful or not. If a specific test is not successful, the tester should provide details (including screenshots if applicable) detailing how the test failed.

These worksheets can be useful for internal testing by an institution - either as a complete guide to testing or as a base for your own customized workflows.

• v4.0.0

• v3.2.0

• v3.1.0

• v3.0.0

• v3.0.0 Agents Module Update Information

• v3.0.0 Agents Module Lite Mode Testing

• v2.8.1

• v2.8.1 JIRA & GitHub Testing

• v2.8.0

• v2.7.0

• v2.6.0

Testing offers team members the opportunity to become very familiar with all sections of ArchivesSpace - even those that may not be part of the standard workflow at their home institution. This familiarity is essential for the full suite testing which tests the all sections of the application. JIRA testing offers a similar opportunity, though the JIRA issues are much more focused.

The ability to follow specific sequential steps and workflows is key to testing. Since not everyone is as technically minded and may require another team members assistance in working through the specifics of a complicated JIRA issue, communication skills are also important.

Some familiarity with GitHub may be useful for more complex JIRA testing. For the more technically minded, the ability to run and test ArchivesSpace locally may be useful in certain, rare situations.

Workload varies and is typically concentrated in bursts throughout the year. The full suite testing for each release is the most time consuming and will typically take at least several hours to complete for each round. There are usually 2-4 releases per year, though this varies. The full suite testing requires the tester be familiar with all sections of ArchivesSpace. JIRA testing for sprints is less time consuming, but may also require the tester to become more familiar with a specific section or workflow.

The team lead has additional duties which include assigning the testing, attending UAC meetings, noting quarterly accomplishments, and writing up an end of year report. These duties are shared with the team vice lead.