Description of the Metadata Standards Subteam

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.

Description of the Integrations Subteam

The Integrations subteam supports the ArchivesSpace community by taking a transparent approach to documenting the integration of systems with the ArchivesSpace application. We facilitate this by:

• tracking current integrations and communicating their progress;

• creating resources that assist members of the ArchivesSpace community with their integration work; 

• liaising between those developing integrations, the ArchivesSpace Program Team and the ArchivesSpace community;

• for specific integrations, determining scope, writing specifications and testing implementations; and 

• actively engaging with ArchivesSpace community members by answering questions and leading discussions on emails, listservs, and other forms of communication

Description of the Technical Documentation Sub-team

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. It is currently under construction and will be filled out throughout the remainder of the 2022-2023 term.

Roles and Responsibilities for TechDocs Members

Maintain ArchivesSpace technical documentation in tech-docs Github repository

• 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.

• Review community-submitted issues and pull requests to the repository.

• Perform yearly surveys of old documentation to provide edits/updates.

• Review and manage AwesomeArchviesSpace.

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 create the appropriate documentation, or at least a stub for future documentation, in a timely fashion.

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 Github Repository

About the Repository

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.

Access and Permissions

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.

Adding subteam members to Repository:

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

2. Select the green “Add member” button.

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.

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.”

Pull Requests

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.

About Pull Requests 

• 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.

To merge a pull request:

1. Navigate to the techdocs repository.

2. Select “Pull requests.”

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

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)

5. If prompted, type a commit message.

6. Select “Confirm merge.”

Issues

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:

• Rebecca Baugnon, lead
  
• Regina Carra
• Kelly Francis
• Matthew Gorham
• Margaret Turman Kidd

The Usability Subteam was created in 2019. The subteam develops functional and practical recommendations to 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. 

Major Activities of Subteam:

• 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.

Workflow:

Guiding documents/resources:

• ArchivesSpace Development Roadmap
•  July 2016 Development prioritization survey and Fall 2019 Survey

Workload: 

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 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, facilitate the meetings, routes the tickets on the kanban boards, and prepare quarterly reports to the UAC chair as requested.

2023-2024 Roster

Purpose of Subteam: To provide outreach and community support for the ArchivesSpace member community by exploring new avenues for engagement, collaborating with the Community Engagement Coordinator to grow current engagement initiatives, and liaising with national and regional archives organization and other relevant professional groups.

Major Activities of Subteam:

Provide outreach and community support for the ArchivesSpace membership, in collaboration with the Community Engagement Coordinator. Manage the administration and activities of the ArchivesSpace Member Match Program

Identify ways to liase with national and regional archives organizations including the SAA, ALA, AAM, AASLH, and other relevant professional groups.

Skills:

• Community outreach and engagement

• Collaboration and teamwork

• Program management

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

Average Workload: The Member Engagement sub-team will meet once a month for an hour. Business outside of meetings will primarily be conducted via email, Slack, and Google drive. Subteam members may also meet in smaller groups for working meetings when needed. The estimated average total time commitment is approximately 3-4 hours per month.

Members:

• Mary Pedraza, lead

• Regina Carra, vice lead

• Will Clements

• Jaime Margalotti

• Jessica Crouch, ArchivesSpace Community Engagement Coordinator

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.

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

Process

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.

JIRA Testing

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:

Full Suite Testing

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.

Testing Worksheets (Google Sheets/Docs)

• 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

Skills

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

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.