This are some suggested approaches to leading the Development Prioritization subteam - they definitely can and should be adapted and refined!

Monthly Dev Pri meetings

Scheduling Meetings

• Wiki page explains how to schedule Zoom or conference call meetings using ArchivesSpace community resources: https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/103881479  

  • Send to the calendar invitation to the subteam members and archivesspace.calendar@gmail.com to get it on the centralized calendar

Creating Agendas

Sample Agenda: https://archivesspace.atlassian.net/wiki/spaces/AC/pages/3298721793

1. Make a copy of the prior meeting’s page

2. Rename page with appropriate date

3. Update date in agenda

4. Update participants list if necessary

5. Delete resolved tickets from agenda

6. If all tickets assigned to a person were resolved, move them to the end of the list to make sure we cycle through everyone over time

7. Assign new tickets as necessary so that everyone has 3 tickets to report on

Tip: To tag a person, use the @ symbol and select begin to type their name.

Open

Note: all tagged people will be emailed every single time the page is updated and saved. To avoid this when making minor updates (for example, saving in-progress meeting notes) use the publish without notifying watchers.

Open

Selecting Tickets

Helpful Jira views

• New bug reports: https://archivesspace.atlassian.net/secure/RapidBoard.jspa?rapidView=15

• New feature requests: https://archivesspace.atlassian.net/secure/RapidBoard.jspa?rapidView=16

• The Dashboard shows the latest activity in Jira and also provides a quick overview of tags

• Labels: you can select tickets by themes by clicking on the labels in the Dashboard view. Obviously, this works only as well as tickets are tagged, so keyword searches are also helpful. Pay attention to their status or scope out any completed/closed/in development tickets.

• Old ticket view is a scoped overview of unresolved tickets according to when they were last created. You can scope searches of Jira tickets by navigating from the Dashboard to Filters to “Search Issues” and scope through all of the drop down options.

• If you like, you can “Watch” a ticket by pressing the “eye” icon on a ticket. This way, you are emailed every time there is activity on the ticket. You probably don’t want to do this regularly, since you might get a lot of emails, but it’s just another option if you’re interested.

   

Look completely over both the Bug and Feature Request Kanban boards for tickets that are glaringly urgent. It’s not clear whether tickets are arranged on the boards in any particular order, so it’s important to not only pick from the top or bottom of the lists.

Try to have a variety of tickets at each meeting intersecting along the following areas:

• Bug (slightly more emphasis on Bugs in order to ensure the program is functioning well)

• Feature Requests (keep in mind that actual implementation of new features is demanding on developer capacity.  While it would be nice to shoot for the stars, it’s also important to not pass a ticket that sends the development team down a low-priority rabbit hole)

Notes:

• When tickets are first made, their status is “Newly Added.”  The Program Manager makes the first pass at vetting tickets, mostly making sure that institution-specific support requests don’t end up in our queues.  Dev. Pri. looks at the Awaiting Prioritization and Awaiting more Information queues. Have a mix of both.  

  • Caution: Awaiting more Information queues can become a “purgatory” if the reporter or other people don’t provide more information.

• Look at the priority symbols on the cards, but don’t rely on this too much. Keep in mind that priority is a subjective ranking, which should be reassessed as part of the meeting discussion.

  • Note: Lydia Tang changed the default priority to “minor” in 2019.  Previously, the default was “major.” Take both statuses with a grain of salt.

• Selecting tickets by themes can be fun and also helpful to making sure that tickets compliment and don’t conflict in recommendations

Assigning Tickets

Ask team members to add any strengths/interests to the roster. Members with technical coding expertise and or cataloging expertise are especially important to note.  If expertise in these areas (or others) are not on the team, be sure to prepare a slate of tickets to share on the member list and potentially invite external experts or the original ticket reporter to discuss the tickets at the meetings.  

Ticket “assignments” are suggestions. If a team member doesn’t want to address a ticket, they should be able to swap out that ticket for a different one.

In general, assign 3 tickets to each member each month for an estimated 30-60 minutes of work outside of the 1.5 hour meeting.

Notes:

• Make sure to match tickets to expertise as much as possible.

• Don’t assign more than 2 extremely involved/complicated tickets to a single person during a given month. 

• The ArchivesSpace program team are technically not a part of Dev. Pri. but attend for their expertise and feedback, do not assign them tickets, unless they have agreed to look into a ticket at a prior meeting.

• This approach of the Lead assigning tickets is only one way to do it. Another possible approach could have subteam members sign up to assign tickets for a given month. This actually might be a more equitable way to distribute the task and would succeed in involving the team more. This initial approach was done primarily to save the time of subteam members from trying to figure out how to select their own tickets each time. Regularly ask the subteam members for feedback on the approach and if they have other ideas.

Before the Meeting

A new agenda with ticket assignments should be sent out to the team shortly after a given meeting. This allows the team members a nearly full month to investigate their tickets.

One week before the meeting, share the agenda with the TAC and UAC listservs to allow those who may be interested in particular tickets to join. This also serves as a reminder to Dev/Pri members.

During the Meeting

Keep the meeting focused - Dev. Pri. needs to cover a lot of tickets.  If discussion of a particular ticket is getting too bogged down, perhaps the ticket needs to be moved to “Awaiting More Info” and/or added to the next month’s meeting. 

The Lead/facilitating person should try to summarize the opinions that others share and suggest (or echo the person presenting the ticket’s) recommendation.  The Lead should never unilaterally decide on a ticket against the opinions of the rest of the subteam. If it’s a hotly contested ticket, the ticket should be shared on the member list for additional commentary and possibly a formal vote.

Notes:

• Reassess the priority ranking and labels on tickets. Adding/clarifying labels on tickets can help the program team identify related tickets during a development sprint.

After the Meeting

The Lead changes the tickets' status a few days after the Dev. Pri. meeting. This gives the subteam members time to comment and follow up on their tickets.  

Dev. Pri. Lead need permissions granted by the Program Manager to move the cards on the board.  This can be a tricky process, so be in touch with Christine if there are any technological hiccups. 

Screenshot of changing the status in the ticket view:

After updating ticket status, refresh the agenda and to make sure that all statuses have been updated and are correct according the to “Decision” column in the meeting notes.

Note: Sometimes it’s not possible for a ticket to move form one column to another. If that’s an issue, move the ticket first back to “Awaiting Prioritization” and try it again from that status.

Metadata Standards and Usability subteam workflow integrations

Some tickets will need input and expertise from the other subteams. The kanban boards currently have “swimlanes” for both Metadata Standards and Usability.

To assign a ticket to Metadata Standards or Usability, add the label “metadata_standards_subteam” or “usability_subteam.”

The Metadata Standards subteam can work fairly autonomously. They may move any tickets assigned to them to the “Ready for Implementation” status without sending them back to Dev/Pri.

The Usability subteam, because of the interconnectedness and complexity of updating the program, has historically functioned as a vetting group. Once Usability tickets have been discussed and have recommendations from the subteam, those tickets should be added to the next Dev. Pri. meeting. It is helpful to have a representative from Usability and, to a lesser extent, Metadata Standards on the roster for Dev. Pri. With the institution of open invites to the TAC/UAC membership during the 2022-2023 term, this is less critical.

Reporting out

Progress updates in TAC and UAC meetings

Sample Council update:

Provide a statement on how many times Dev. Pri. met since the last update and how many tickets the team addressed (count on the Decisions column of each meeting agenda)

Example:

“Dev. Pri. met once since the joint TAC/UAC meeting in January and addressed 13 tickets at the meeting (6 ready for implementation, 5 awaiting more information, 2 closed).”

Use this opportunity at the council meeting to bring attention to tickets needing more information or discussion.

Example:

“The following tickets require more specification. Please feel free to comment on these tickets!”

[list tickets needing larger group input]

Quarterly Board Reports

The Technical and User Advisory Council chairs will ask the Dev. Pri. Lead for reports to add to the council reports four times a year.

The reports basically can be a cumulative summary of work accomplished since the last quarterly report.

The format essentially can be similar to the UAC/TAC updates.

Sample Quarterly Board Report:

Generating Jira Reports

From one of the kanban board views, expand out of the side menus and click on “reports”

There are many, many different types of reports, but Dev/Pri has made limited use of them to date.

Special Projects

Dev. Pri. may want to consider special projects that align with its mission including creating surveys, calls for feedback on selected tickets, or recommending Task Forces to address areas of need to Council leadership and the Program Manager.

Leads and Vice-Leads

As with the rest of the advisory councils' subteams, Dev/Pri switched to a Lead/Vice-Lead model during the 2021-2022 term. The division of responsibilities between the two people can be handled in many different ways, but as of the 2022-2023 term, 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 the rest of the work outlined in this document.

Having the Vice-Lead take responsibility for one of the last meetings of the term is helpful for making sure they are confident in managing the process after the leadership transition.

It is ideal if one of the two is from TAC and the other from UAC. If that is not possible due to a lack of volunteers, some arrangement for reporting to the other advisory council during their meetings must be made.