<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;
        font-weight:normal;
        font-style:normal;
        text-decoration:none none;}
span.box
        {mso-style-name:box;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Dear ArchivesSpace community:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal">Apologies for the length of this. I’ll try to address a lot of comments, but not all!  Please let me know if (as they may well do) my elaborations only elicit more questions!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In general, most of these proposals are derived from facing problems of scale. Harvard has 30 repositories and over 200 users of ArchivesSpace. Others have to do with managing “medium rare” materials’ locations and containers in ArchivesSpace. 
 (Medium-rare is a tongue-in-cheek term used to cover materials that might exist in multiple manifestations but that have archival or rare characteristics or treatment. Examples include entire libraries ingested into an archives, author’s own copies of their
 books, annotated books, or the record copy of serials or reports kept by institutional archives.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span class="box"> • Multi-field top container indicators<o:p></o:p></span></p>
<p class="MsoNormal"><span class="box">     Some commenters wondered if the multiple fields were to accommodate child containers. To clarify, the suggestion was to facilitate parsing top container identifiers.  As a few commenters have surmised, this is to
 cope with legacy numbers.  These are especially common on medium-rare materials.<o:p></o:p></span></p>
<p class="MsoNormal"><span class="box">     One suggestion was to use a sort algorithm that would obviate the need for separated fields for data. However, because there would be is more than one algorithm necessary over the installation, such a solution would
 require an added field to identify the algorithm and probably a third field retain a value derived by the algorithm to be sorted alphanumerically. Thus, the direct 3-field solution seems simpler. (A 4-field suggestion was mooted in the committee as potentially
 more useful communally.) It does occur to me that there just might not be enough really old, really big repositories with lots of legacy identifiers in the ArchivesSpace community for the parsing of legacy numbers to be a common problem. I appreciate the recognition
 that a plug-in might be needed instead, but it would be worth hearing from any repositories with similar issues.<o:p></o:p></span></p>
<p class="MsoNormal"><span class="box"><o:p> </o:p></span></p>
<p class="MsoNormal"><span class="box"> • Container and location profiles by repository<o:p></o:p></span></p>
<p class="MsoNormal"><span class="box">       We were envisioning a one-to-one profile-to-repository scenario. Due to the ArchivesSpace staff user interface requirement that one identify only a single repository at login, i</span>t is extremely easy for users
 to forget the impact they might have beyond their repository if they change or delete a shared record. 
<span class="box">We have already experienced mistaken mergers and deletions of agents due to the design of AS staff user interface that does not allow one to see where the record may be linked beyond their repository.  For this reason, it is wise to be able
 to limit changes and deletions of location profiles and container profiles impact to the same chosen repository.<o:p></o:p></span></p>
<p class="MsoNormal"><span class="box"><o:p> </o:p></span></p>
<p class="MsoNormal"><span class="box"> • Inactive<o:p></o:p></span></p>
<p class="MsoNormal"><span class="box">     As Maureen wisely intuited, inactive locations are necessary to recording a complete location history.  However, there are additional use cases. When a repository is renovating, for example (as is happening now at
 the Schlesinger Library) the shelves in a location may be inactive for a time and become active again when the building re-opens.  Other scenarios include water intrusion or other occasions when a smaller sub-set of shelves may have to become inactive until
 repairs are completed and tested before the shelving can again come into use. Because inactive locations are to be eliminated by default from search results, we can prevent them from overwhelming staff members’ search results or sending staff to unusable locations.</span><o:p></o:p></p>
<p class="MsoNormal"><span class="box"><o:p> </o:p></span></p>
<p class="MsoNormal"><span class="box"> • Notes in containers and locations<o:p></o:p></span></p>
<p class="MsoNormal"><span class="box">     Notes are for dedicated shelving or rehousing issues.  Notes on containers may contain things like “Label falling off” “Acidic-needs replacing” “Acid box replaced with acid-free box 2017-06-08” “Not on shelf 2015-10-10”. 
 Notes on locations may contain things like “only use as last resort—overhead drip pan makes retrieval difficult” “reserved for outgoing transfers until 2019-01-01”.  In locations especially, we would expect the reason for a location becoming inactive might
 be noted.  “Made inactive because next to heating duct—do not reactivate”.<o:p></o:p></span></p>
<p class="MsoNormal"><span class="box"><o:p> </o:p></span></p>
<p class="MsoNormal"><span class="box"> • Bibliographic record IDs in containers<o:p></o:p></span></p>
<p class="MsoNormal"><span class="box">     This data would allow for more sustainable interoperability between systems and more flexibility in workflows.<o:p></o:p></span></p>
<p class="MsoNormal"><span class="box">     Especially with medium-rare materials, the physical item’s location might need to be recorded before description is finalized, and if the description is to be created in foreign system and ingested to ArchivesSpace,
 hooking up the container and location will be problematic.  In this scenario, a resource with initial description in a bibliographic system could be placed on an archives’ shelf, and the description, once completed in the ILS, could be ingested via MARC XML
 ingest for example.  After the resource is ingested, the ILS bibliographic record number could be searched in the containers to link the container to the resource.<o:p></o:p></span></p>
<p class="MsoNormal"><span class="box">     When an ILS system migrates, it is unlikely that the migration would maintain obsolte holding or item system numbers, but it is common to migrate with obsolete bibliographic system record numbers embedded into the
 new system.  Should there be a need to re-migrate holdings or items from ArchivesSpace to a new ILS, bibliographic record numbers would ensure continuity.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks for reading!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Kate<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b>From:</b> archivesspace_users_group-bounces@lyralists.lyrasis.org <archivesspace_users_group-bounces@lyralists.lyrasis.org>
<b>On Behalf Of </b>Maureen Callahan<br>
<b>Sent:</b> Monday, December 17, 2018 2:09 PM<br>
<b>To:</b> Archivesspace Users Group <archivesspace_users_group@lyralists.lyrasis.org><br>
<b>Subject:</b> Re: [Archivesspace_Users_Group] REMINDER: Proposal for Container Management Enhancements - Call for Community Input<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">A million thanks to folks from Harvard for showing leadership and investing to improve the experience of the software for all of us. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">I was having pleasant flashbacks to my days at Yale working through the original specifications for the container management functionality -- what it all
<i>means, </i>what it should <i>do, </i>how this will improve the experience for archivists and patrons, and how to abstract all of this work to more general archival and data management principles. It's such fun, hard work!<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">Generally speaking, it would be really helpful if user stories gave a better sense of what you want to <i>accomplish</i> instead of what you want to see on the screen. For some of this,
 I had a hard time understanding where you were coming from and I think it's possible that there are different ways of accomplishing what you've laid out. "As an W, I want to have X feature, so that Y behavior happens in Z way and lets me do my work in ABC
 fashion." I think that many of the goals behind this proposal are sound, but that perhaps there's too narrow an approach to solutions to meet these goals. Developers might find better ways to address the problems you've identified.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">1. Hell YES there need to be easier ways to browse/sort/find locations!!!!<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">2. I agree that it would be useful to have the
<i>option</i> to filter locations/container profiles by the repository they tend to belong to and that this should also be extensible so that it's easy to change this information after a move or administrative change. I sort of remember that folks at NYU talked
 about this as a possible outcome in the beginning of their location profile work, so it may be worth talking with them about the best way to think about it and any reasons they might have opted to not associate a repository with a location profile.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">3. Lora did some nice work with search to make it possible to see the entire breadcrumb trail of where a search result comes from (the hierarchies of AOs within a resource). I'm thinking
 that perhaps you just want the same thing to happen when you look at the associated archival objects / accessions in a top container, rather than adding another column (resource) to the search result.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">4. As someone who has had to do a lot of systems migrations that involved moving heterogenous data into more structured places, I get really nervous about a notes field for either the location
 or the top container. If there are common types of information that end up in this field, it may be worth considering adding more structured fields to either the location or the location profile or container or container profile so that it can be better managed,
 queried, and kept tidy & up-to-date. What's the scenario by which someone would actually look at this notes field? What do you want to go in there?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">5. Soooooo tell me more about this inactive location idea. AFAIR, ArchivesSpace doesn't keep an audit trail of previous locations. What's the value of knowing that inactive locations exist
 when there aren't containers living in those locations and there's no way to see that those locations perviously held containers?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">6. This may be implicit in your proposal, but it sounds like you want "repository" to be a multi-valued field in your location profiles and your container profiles. Paige boxes, for instance,
 will probably end up being associated with every repository.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">7. I was initially a bit perplexed by the request to add additional fields for container indicators, but reading between the lines, my guess is that you want to be able to sort them properly
 in various circumstances. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">If, for instance, you have boxes 2, 2a, and 3, you want to be able to make sure that when you sort by indicator, they appear in this order. That's a great goal! But I think that you might
 want to state this goal instead of stating one possible outcome. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">I definitely DO NOT want a three-part container indicator because who knows what kind of crap people will put in those fields and they could potentially be a nightmare to clean up. Plus,
 it would have to account for every possible heterodox way that people design their container indicators -- or just default to Harvard's scheme, which... I mean, this is software for the whole community.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">Instead, I would suggest making the requirement that you want for alphanumeric characters to sort properly and clever developers can come up with the best way to do this. That seems like
 a more elegant solution than changing the data model.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">8. YES BIBIDs!!!! But my read is that a BIBID is a control number for intellectual description, not for holdings. I know that folks are currently putting BIBIDs in user-defined fields in
 the resource record, and it would be great for those to have a canonical spot to help with systems integrations. I would much rather see the addition of a BIBID to the resource record, which can then be displayed with the top container by the system if desired
 (although why?). There's already a field for the ILS holdings ID to go with the top container.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">Thanks all,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif">Maureen<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif">-- </span><span style="font-family:"Times New Roman",serif"><o:p></o:p></span></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Times New Roman",serif">Maureen Callahan<br>
Sophia Smith Collection Archivist<br>
Smith College Special Collections<br>
Northampton, Massachusetts 01063<br>
413 585 2981<br>
</span><a href="mailto:mcallahan@smith.edu" target="_blank"><span style="font-size:10.0pt;font-family:"Times New Roman",serif">mcallahan@smith.edu</span></a><span style="font-family:"Arial",sans-serif"><o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Times New Roman",serif">Pronouns: she/her/hers</span><span style="font-family:"Arial",sans-serif"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Times New Roman",serif;color:black">Smith College Special Collections is now housed at
</span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.smith.edu_libraries_about_new-2Dneilson_wheres-2Dmy-2Dlibrary&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=bbRMI526TLbYRRGdpIJjhaQSNXcp3-xidB745mYa688&s=6_5o894RumU3UiMWDspYsi9hvlxzwybbDZhwqxoqzUk&e=" target="_blank"><span style="font-size:10.0pt;font-family:"Times New Roman",serif">Young
 Library</span></a><span style="font-size:10.0pt;font-family:"Times New Roman",serif;color:black">. Learn more about renovations to Neilson Library
</span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.smith.edu_libraries_about_new-2Dneilson&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=bbRMI526TLbYRRGdpIJjhaQSNXcp3-xidB745mYa688&s=D7vktPydut0KZQpgPuTDeMfGLme5d9GNsfXHoWV7CRk&e=" target="_blank"><span style="font-size:10.0pt;font-family:"Times New Roman",serif">here</span></a><span style="font-size:10.0pt;font-family:"Times New Roman",serif;color:black">.
</span><span style="font-family:"Arial",sans-serif"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Dec 17, 2018 at 12:42 PM Rackley, Marilyn <<a href="mailto:marilyn_rackley@harvard.edu">marilyn_rackley@harvard.edu</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Dear all,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Please remember to review the Harvard Library proposal for container management enhancements and submit feedback by
<b>Wednesday, December 19, 2018. </b>See the email below for more information.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">In case people are not able to access the attachment, the proposal can also be accessed through this link:
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_open-3Fid-3D14-2D6CFEAATfwYc1JZoAmCSD3CQVW7p3b3&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=bbRMI526TLbYRRGdpIJjhaQSNXcp3-xidB745mYa688&s=1GjU8ktQ9bncQdhvdE2zi0a2fHSWL8NDj17jV9byJn8&e=" target="_blank">
https://drive.google.com/open?id=14-6CFEAATfwYc1JZoAmCSD3CQVW7p3b3</a>.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">We really appreciate all the comments provided so far.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Best,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Marilyn<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> Rackley, Marilyn
<br>
<b>Sent:</b> Monday, December 3, 2018 9:36 AM<br>
<b>To:</b> <a href="mailto:archivesspace_users_group@lyralists.lyrasis.org" target="_blank">
archivesspace_users_group@lyralists.lyrasis.org</a><br>
<b>Subject:</b> Proposal for Container Management Enhancements - Call for Community Input<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Dear ArchivesSpace Community,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The Harvard Library has been reviewing container and location management functionality in ArchivesSpace and we are proposing to make enhancements to this functionality that we would
 like to contribute to the core code.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">With these enhancements, we hope to make finding, viewing, and updating information related to containers and locations in the staff interface more efficient and effective.
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">We have completed the draft proposal attached to this email and we are now asking for community review and feedback. The proposal includes the rationale for the changes, a list
 of database fields to be added, user stories describing the specific changes we are proposing, and mockups of the related updates to the staff interface. Please note that in the proposal, certain changes are designated as being a lower priority; it is possible
 that we may not be able to complete all the proposed changes at this time.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">If you have questions or feedback, please email me at
<a href="mailto:marilyn_rackley@harvard.edu" target="_blank">marilyn_rackley@harvard.edu</a> and/or Robin Wendler at
<a href="mailto:robin_wendler@harvard.edu" target="_blank">robin_wendler@harvard.edu</a>.
<b>We will be accepting comments through Wednesday, December 19, 2018.</b><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">We look forward to receiving community input.
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Best,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Marilyn<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><i>Marilyn Rackley</i><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><i>Aeon Project Manager and Digital Librarian</i><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><i>Harvard Library | 617.496.4043</i><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a href="mailto:marilyn_rackley@harvard.edu" target="_blank"><i>marilyn_rackley@harvard.edu</i></a><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Archivesspace_Users_Group mailing list<br>
<a href="mailto:Archivesspace_Users_Group@lyralists.lyrasis.org" target="_blank">Archivesspace_Users_Group@lyralists.lyrasis.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=bbRMI526TLbYRRGdpIJjhaQSNXcp3-xidB745mYa688&s=Ia_oQ7YT5R2fLTqMbss7oSChwO-HRtiNxwPbTe1RCRM&e=" target="_blank">http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>