This workflow index is meant to be comprehensive, covering all teams and aspects of the M2R Project. It was updated significantly in April 2026.

Reasons for not mapping a row/justifications for recording "Delete" should go in "Notes--Uncategorized" column, not in "Justification for Mapping" column.

I.A.1.a. "Not Mapped" status
Like "Delete" status, "Not Mapped" reasons for not mapping a row should go in "Notes--Uncategorized" column, not in "Justification for Mapping" column.

Add transformation notes whenever possible.

Do not comment on spreadsheets in Google Sheets. Comments, discussions, and issues should be located and tracked in GitHub.

I.A.4.a. Condition Layering
I.A.4.a.i. Multiple values for the same MARC subfield condition with OR relationships should be recorded in the same cell, with | as delimiter.
I.A.4.a.ii. Independent conditions get separate rows in the spreadsheet. Layered conditions are in multiple columns of the same row.
I.A.4.a.iii. New sets of MARCTagCondition/ConditionValue columns may be added as needed to create more layered conditions with AND relationships to one another.
I.A.4.b. Punctuation differences in label values for conditions should be ignored/treated as the same. For instance, “Based on (work)” and “Based on work” should be treated as the same string.
I.A.4.c. Updated Instructions to include formatting for MARCTagCondition cells and corresponding value cells.
I.A.4.d. Added table with prescribed syntax operators.

Mapping Spreadsheets that are finished should move rows with final statuses other than "done" to new sheets in the workbook to reduce redundancy and improve readability e.g. move deleted rows to a new “Deleted” sheet within the workbook. See issue.

I.B.1.a. The project will rely on GitHub’s versioning control, and refrain from adding new columns/notes to record different iterations of individual spreadsheets or tables over time.
I.B.1.b. Updated versions of the transformation code suitable for experimental use will be published as GitHub Releases.

Draft versioning will rely on Google, with frequent semi-automated pushes to GitHub for relevant mapping spreadsheets and tables.

II.A.1.a. Current milestone: CSR. See discussion.

II.A.1.b. Old milestones: MVP for Transform, Publication, BSR, Mapping Review.

II.B.1.a. Phase I of the project focused on initial mapping of BSR Milestone on singleton Work-Expression entities (non-aggregates) and simple augmentation aggregates, with aggregates and serials integrated in Phase II.

The project will use a semi-automated script to push changes directly to the Master branch. The project will not be utilizing pull requests. [This is out of date. 2025-11-20]

This project uses issues to identify, track, and briefly discuss discrete pieces of work. See open issues for examples. Broader discussions, decision-making conversations, and other ideas which do not represent specific tasks use the GitHub Discussions functionality instead.

When an issue is closed, if it isn't self-explanatory, a note and link will be included to the related decisions recorded in the decisions index at the time of issue-closing.

III.A.3.a. Project issues begin in the "to-do" category of the GitHub project, and are prioritized using Milestones and Labels.

III.A.3.b. Issues are self-assigned, and moved to "in progress" category at that time.

III.A.3.c. Once a first pass is complete, mappers move issue to "awaiting review".

III.A.3.d. If one or a few open questions are holding up the first pass, a mapper may move the issue to the "almost done" column, adding a note in the issue explaining what needs to be done in order to complete a first pass. The self-assigned mapper will finish the mapping when the open questions are answered, or will find someone else to adopt the issue. Crystal will monitor the "almost done" column to make sure nothing lingers unnecessarily. Once a first pass is complete, these issues move to "awaiting review". If a mapper believes the mapping is too complex for a single person to reasonably complete, and that the mapping would benefit from group review, the mapper will also label the issue "meeting discussion needed".

III.A.3.e. Any project participant except for the person who performed the initial mapping may elect to take on the role of "reviewer" for a section/field of the mapping. Reviewers self-assign issues from "awaiting review" to review mappings. Once review is complete, issues are moved to "ready for transform".

III.A.3.f. Transformers select issues from "ready for transform" and write code for them. Once code is complete, issue is closed and automatically moved to "done".

III.A.3.g. If changes are needed after an issue has been moved to "done", the issue is re-opened and re-assigned, and moved to the appropriate column. Notes should be made in the issue to indicate to mappers that transformation code needs to be adjusted/checked against any changes.

III.A.3.h. If a reviewer makes changes to the mapping and the mapping has a tag indicating a transformer is writing code for that mapping, ("coding-ar", "coded-ar", "coding-rip", "coded-rip", "coding-rft", or "coded-rft"), the reviewer should add the "code re-check" label to the issue to indicate that transformers need to update the code.

III.A.3.i. Once Transformers have re-checked issues with the "code re-check" label and made any needed updates to the code, remove the re-check label when done.

III.A.4.a. Transformation Review issues begin in the "Transformation Review To-Do" category of the GitHub project and are assigned an appropriate milestone, along with labels "Transformation Review To-Do" and "Input Data Needed". Other labels can be assigned as appropriate for sorting. Each issue includes links to the corresponding initial mapping and transformation issue, mapping spreadsheet, and input and output from the field-by-field testing done at the time of transformation by the coders.

III.A.4.b. Project team members: Crystal, Adam, or Deborah supply input test data to review issues either together or in groups.
III.A.4.b.i. Test data in the form of approximately ten records in MARC XML format goes into the MARCDatasets folder in the GitHub repository.
III.A.4.b.ii. Once a test dataset has been supplied, it is linked to in a comment in the Transformation Review issue(s) and a corresponding review discussion is created. Review discussions are also linked from the Transformation Review issues as comments. One discussion per review dataset may be used, to combine discussions on several tags at once.
III.A.4.b.iii. The label "input data needed" is replaced with "output data needed" and "needs coder attention".

III.A.4.c. Coders self-assign issues with the labels "input data needed" and "needs coder attention". Input data from the MARCDatasets folder is run through the current version of the transformation to produce outputs in the output data for review folder. At this point, the labels "need coder attention" and "output data needed" are replaced with "ready for transformation review"

III.A.4.d. Review
III.A.4.d.i. Once it is decided to review an issue, the "ready for transformation review" label is removed and "transformation review in progress" is added. Issues may be reviewed either asynchronously or during a meeting or both. "Asynchronous discussion needed" and "Meeting discussion needed" labels should be added to both issues and discussions as appropriate at this stage.
III.A.4.d.ii. If no problems are found with the code, reviewers should state this in the discussion and change the issue from "transformation review in progress" to "done" in the workflow.
III.A.4.d.iii. If problems are found in the code, discussions should be used for all feedback until a clear comment can be left in the issue directing coders on how to fix the problem. After a clear comment has been made, the labels "code re-check" and "needs coder attention" should be added to the issue. Once issues are resolved, the issue can be moved to "Transformation review complete" and closed.
III.A.4.d.iv. Issues with code may be found outside of this regular transformation review process. If that happens (say, for example, an issue with a field that isn't being reviewed yet is found during review for another field), create a new issue typed "Bug" with the labels "Transform" and "needs coder attention". Add the prefix [BUG] to the title. If possible, link to the area in the code that needs work. At least, link to the mapping spreadsheet and initial mapping and transformation issue related to the problem if they are relevant. Assign bugs to the to-do column of the project. Coders self-assign bugs by moving them into the "in progress" step in the workflow and assigning themselves to the issue. Once the bug is fixed, move the issue to "done".

III.A.5.a.i. When the transformation is not functioning as intended, a bug report issue should be submitted using the "BUG report" issue template. The template should be filled out as completely as possible, with a concise description of the bug, relevant MARC21 tags and/or RDA elements, XSL stylesheet(s) where the bug is located, steps to reproduce the bug, expected behavior, screenshots illustrating the bug, information about the hardware and software being used when the bug appears, and any additional context deemed useful. If information is not known the corresponding portion of the template may be left blank.
III.A.5.a.ii. Bugs will automatically be assigned to project managers. Do not remove them from the assignees section, as the routing and resolution of the bug depends on the emails they will receive once the issue is submitted.
III.A.5.a.iii. Project managers will assign a project, a milestone, and additional labels as needed. Then, they will route the bug to relevant team member(s) or add a "ready for coder self-assignment" label. The bug will be placed in the "To do" project status until it is assigned, and then it will move to "In progress". Once the bug is resolved, the issue will be closed.

III.A.5.b.i. Before submitting a new community feedback issue, click here to view current open community feedback issues to avoid duplication.
III.A.5.b.ii. Feedback from persons outside the MARC2RDA project should be routed through the Community Feedback issue template. If feedback is received via email or some other means, team members should fill out this form on behalf of the person(s) who gave feedback to them, or direct feedback-givers to the template. In this way, the project will ensure that all feedback received is tracked and acted upon as appropriate.
III.A.5.b.iii. Feedback issues should include the relevant MARC21 Bibliographic tag(s) and RDA elements, a description of the feedback, and the desired outcome if known. Issues will be automatically assigned the label "Community Feedback" and assigned to Crystal Yragui. Do not remove the assignee or label, as the project's response to feedback depends on them. Crystal will route the feedback to the appropriate person(s) and add other labels as appropriate, and place the feedback issue into the relevant workflow stage. Once the feedback has been fully reviewed, and either incorporated or taken as a consideration, the issue will be closed.

Select field using the main project board and assign yourself to the issue on GitHub. Do not code fields in "To Do" or "In Progress." It is OK to code fields in "Awaiting Review" or "Review in Progress" if the procedure below (III.B.3) is followed. It is best to select fields from "Ready for Transform"; follow the procedure below in (III.B.4).

A field can be moved into "Done" on the main project board if two conditions are met: (1) the coding is done;
(2) mappers have moved the field into "Ready for Transform."

III.B.3.a. Manually edit the issue by adding the appropriate label indicating the field's status on the main project board at the time of the coding. Either use "coding-ar" (for a field being coded while "Awaiting Review") or "coding-rip" (for a field being coded while "Review in Progress").

III.B.3.b. Add/Commit the code for the single field; include a commit message that includes the following: -m "Code for field XXX [awaitingReview OR reviewInProgress] #[issueNumber]." Example: "Code for field 100 awaitingReview #102."

III.B.3.c. When coding is complete, manually edit the issue by removing the "coding-ar" or "coding-rip" label and replacing it with the "coded-ar" or "coded-rip" label as appropriate.

III.B.4.a. Manually edit the issue by adding the label "coding-rft" (III.e. "We are coding this field in the main project board's category 'Ready for Transform").

III.B.4.b. Add/Commit the code for the single field; include a commit message that includes the following: -m "Code for field XXX #[issueNumber]." Example: "Code for field 100 #102."

III.B.4.c. When coding is complete, remove the "coding-rft" label and replace it with the "coded-rft" label.

III.B.5.a. Change the transformation-related tags from the appropriate "coding" tag to the matching "coded" tag. If the field was in "Ready for Transform", close the issue for the field.

Discussions are used by this project for sharing ideas, giving feedback, asking questions, and generally discussing aspects of project work which are not discrete pieces of work which need to be assigned, tracked, and completed (these are recorded as GitHub issues]. Discussions may be linked from issues or notes in spreadsheets, and may also be converted into issues when appropriate. Discussions which no longer need participation should be closed. Labels may be used to help sort discussions.

Notes in spreadsheets and project documentation outside of discussions and issues should be brief, and are meant to convey specific pieces of information. Questions, discussions, and pieces of work should instead utilize GitHub discussions and issues. Notes should be initialed and dated using EDTF format, and separated using " ; ".

Project team members will talk and listen in turns, using hand-raising functionality in Zoom interface to order discussions.

Agendas, set by Crystal and edited by anyone, will include time limits for items. Unused time can be rolled over to the next item.

Timekeeper and note-taker will be assigned at the start of each meeting (as separate duties). Note-taking should rotate between UW members. Notes may be amended by anyone after each meeting.

Off-topic but important items will be noted in a "Backburner" section of the notes/agenda in an effort to keep conversations focused.