Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Responsibilities

  • Create agendas

  • Assign tickets

  • Lead the meetings

  • Update the ticket statuses after meetings

  • Write quarterly updates for Council Reports to the the ArchivesSpace Governance Board

  • Preparing updates for the TAC and UAC meetings

 Dev. Pri. leaders 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. 

Creating Agendas

Sample Agenda: 2019-12-18 Meeting notes

  1. Sign to create the agenda under the appropriate year header (the year must be selected in order for the agenda to be created nested within it)

  2. Select “meeting notes” for the page style

  3. Set the calendar view to the proper date (it autofills the current day)

  4. Copy over the zoom call info from previous agenda (make sure to the ArchivesSpace zoom calendar is up to date.)

  5. Copy over the participants from the roster

  6. Add the follow links: Kanban boards:

    Link to ArchivesSpace sandbox: http://test.archivesspace.org/

  7. Suggested column names:

  • Item/Who [the reason to combine them is to not get the board too wide]

  • Tickets

  • Recommendations

  • Decisions

8. Meetings typically have the following elements:

  • Roll call

  • Announcements/Discussion

  • Tickets

Selecting Tickets

Look completely over both the Bug and Feature Request Kanban boards for tickets that are glaringly urgent.

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 will make 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.  It may be worth doing a scoped search to devote a few meetings to the Awaiting More Info tickets to close unresponsive tickets.

  • Look at the priority symbols on the cards, but don’t 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.  

Note: Ticket “assignments” should be 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-5 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. 

  • Laney and Lora are technically not a part of Dev. Pri. but are there for their expertise and feedback.  Assign up to 2 tickets (1 each) to them only if their particular expertise is required.  

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.

A week before the upcoming Dev. Pri. meeting, send a reminder including:

  • The link to meeting agenda with ticket assignments

  • Ask that the team members add their notes before the meeting

    • Encourage team members to comment on the tickets ahead of the meeting if they have any questions, this way the ticker reporter or someone else can provide more information.

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.  Consider having a 5 minute limit for each ticket.  

If the meeting is running over, people may need to only present one or two of their tickets in order for everyone to speak at least once during the meeting.  Unaddressed tickets can be carried forward to the next meeting.

The leader/facilitating person should try to summarize the opinions that others share and suggest (or echo the person presenting the ticket’s) recommendation.  The leader 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.

If the leader has prepared a “quick list” of tickets to possibly close, they still need the support of the rest of the subteam before closing those tickets.  This approval can be conducted via email or at the meeting, but never unilaterally by the leader without others’ input.

Notes:

  • It may be worth considering alternating people when presenting tickets, as opposed to having a single person present all of their tickets at a time. Often, the team member would need to follow up on the ticket with a note, and it may be best to skip temporarily to someone else’s tickets while that team member leaves the follow-up text on their ticket.

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

The leader/co-leaders move the tickets on the board a few days after the Dev. Pri. meeting.  This gives the subteam members time to comment and follow up on their tickets.  

Update ticket statuses either by dragging tickets on Kanban board into appropriate columns or by updating the status on the individual tickets.

  • When closing tickets, leave a comment on the rational and end the message “on behalf of Dev. Pri.” so that ticket reporters have a rationale and know who is making this decision.

  • 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 (VERY IMPORTANT).

QUARTERLY REPORTS

  • Collected by TAC and UAC chairs 4 times a year

  • Includes total number of tickets addressed. This number is collected by going through the Dev Pri meeting agendas and counting the “final decisions” column

  • Sample report (see below)


November 2018-March 2019 

Development Prioritization (Cross-Council UAC/TAC Subteam)

 

Charge: The Development Prioritization Subteam prioritizes feature requests and bug reports for developers working on future releases of the ArchivesSpace program.

 

Roster Changes:

Maggie Hughes is now co-lead as of January 2019.

 

Major Activities:

Dev. Pri. met four times from November-March and addressed 82 tickets with the goal of resolving older tickets and addressing reported bugs.

 

Future Work Plan:

We look forward to continuing to meet on a monthly basis to continue to review and prioritize bug reports and feature requests


Monthly updates in TAC/UAC meetings

“Part of the challenge this group has had is demonstrating the work they do.  By simply listing the Kanban stats, it sounds like nothing gets done, but it also demonstrates the continual nature of the group’s mission.  For UAC/TAC meetings, it may be nice to list a handful of tickets that need community input, so hope that someone gets fired up to help with them.”


Sample from Lydia and 3/22/19 UAC meeting:

Dev. Pri. met once since the joint TAC/UAC meeting in January and addressed 18 tickets at the meeting. 

Kanban stats:

  • Feature Requests:

  • Awaiting prioritization: 107

  • Awaiting More Info: 58

  • Ready for Implementation: 72

Bug Reports: 

  • Awaiting prioritization: 13

  • Awaiting More info: 11

  • Ready for Implementation: 56

 

The following tickets require more specification, ideally if a group would like to crowdsource info and mappings for these controlled vocabulary plug ins:

ANW-478

  • As a repository manager, I would like a plugin to the RBMS Thesauri

AWAITING MORE INFORMATION ANW-479

  • As a repository manager, I would like a plugin to the AAT

AWAITING PRIORITIZATION ANW-481

  • As a repository manager, I would like a plugin to ULAN

AWAITING PRIORITIZATION

  • No labels