Timestamp,Why do you write your own documentation for ArchivesSpace? Select all that apply.,What aspects of ArchivesSpace do you document locally?,"When writing your local documentation, were you aware of the official ArchivesSpace documentation?","When writing your local documentation, did you consult the official ArchivesSpace documentation?",Do you use the official documentation at https://docs.archivesspace.org?,Why or why not?,Who is responsible for maintaining your local ArchivesSpace documentation?,How much time would you estimate is spent on writing and maintaining your local ArchivesSpace documentation?,Would you be willing to share your documentation with the ArchivesSpace community?,Why or why not?
5/21/2019 23:58:21,"I wish to document local practices, I only want to document the features we use, It’s lacking.","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), Integrations with other systems",Yes,No,No,It’s not specific enough ,University Archivist ,It was worked on overtime as we instituted AS.,Yes,It’s a public Libguide
5/22/2019 0:07:49,"I wish to document local practices, I only want to document the features we use, Some of my users need much more detail / step-by-step how-tos than are in the official docs.","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), The next documentation update--which I'm currently writing, will include Plugins & Reports; the one after that will include OAI/Primo integration.",Yes,No,No,Only some of the people I'm writing for feel comfortable enough with AS to look up its official documentation.,I am.,LOTS!,No,It needs tons of work.  
5/22/2019 0:10:59,"I wish to document local practices, Institutional pressure to have localized docs","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), Integrations with other systems, Plugins, Reports",Yes,Yes,No,"Examples provided by peer institutions were very close to what we needed, so we followed those.","Head of Archives Processing (me), but both the wiki and google docs are editable by local users.","A few hours to write, and not much (not enoguh!) maintenance",Yes,
5/22/2019 11:29:59,I wish to document local practices,"Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules)",Yes,No,Yes,We use the docs.archivesspace.org info for systems guidance and local for how best use the system in conjunction with local practices.,Internal Steering Group,Five hours per month,Yes,Feedback and sharing would be beneficial.
5/22/2019 12:00:50,"I wish to document local practices, I only want to document the features we use","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), Integrations with other systems, Reports",Yes,Yes,Yes,"The official documentation is good for understanding the features of the software, but we have to have local practices for how we implement ArchivesSpace. For example, repositories can record processing status in multiple places in the application. We have to have a single way we record this information so that we can effectively run reports.",Director of Special Collections approves final changes.,More when we were first building our documentation. Maybe an hour or so a week to maintain.,Yes,I don't know how helpful our documentation would be. It our local MAP and management guidelines.
5/22/2019 12:54:08,"I wish to document local practices, I only want to document the features we use","Local practices (cataloging rules, subject and agent rules), Integrations with other systems, Plugins",Yes,Yes,Yes,,,,No,
5/22/2019 12:56:46,"I wish to document local practices, I only want to document the features we use, I want to document our usage as it relates to our individual workflows--not only how we use the software but where each step comes in for a given role, and which roles do which pieces of management","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), Integrations with other systems, Plugins",Yes,Yes,Yes,,Head of Collection Management,"Because our documentation integrates with documentation on processing, accessioning, and maintaining locations, a large amount of time is dedicated to writing, revising, etc.",Yes,"What we have, we would be happy to share. We are currently in the middle of re-writing processing workflows using the software, so we are not quite ready to share that, but accessioning workflows with integrated directions for ArchivesSpace we would be happy to share. "
5/22/2019 13:03:02,"I wish to document local practices, I only want to document the features we use, I find the existing documentation difficult to navigate","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), Integrations with other systems, Plugins, Reports",Yes,Yes,Yes,"I use it sometimes, but my many other staff users don't or find it confusing / out of date. Have you thought about setting up major release versions of the Docs rather than try to indicate "" (as of version 1.5.0)"" in the headings of sections? 
 Clear, plain language would help.  The docs as-is are often written for a technical audience, but I'd suggest writing for a more general audience: as in drop prose like ""it provides a mechanism for linking "" in favor of active voice, direct instructions, and clearer plain language. 

""Version 1.5.0 of ArchivesSpace introduces the ability to assign top containers to instances, and container profiles to top containers. The primary benefits of this capability are two-fold: 1) it provides a mechanism for linking many archival objects to the same container, thereby increasing efficiency and providing the ability to perform bulk operations on containers; and 2) it provides the ability to generate extent calculations for containers of specified types. For example, if you move Box 1 in a collection to a new location, using top containers enables you to update that location once, rather than for each archival object in the box as in past versions of ArchivesSpace.""

vs
""Beginning in AS version 1.5, user can assign top containers to instances.  Users can also assign profiles to top containers. 

Top containers are linked records, much like Agent or Subject records.  Like other linked records, users can attach a top container to as many archival objects or resources as needed. As a linked record, a top container provides efficient options to edit details about Box, Volume or other ""containers"".  Users can edit a single Top Container record, rather than editing text strings within many individual archival objects. This makes editing and management of your containers much more efficient. Relabeling boxes can be a handful of changes to Top Containers, rather than hundreds of changes to archival objects. 

Top containers can also support extent calculations.  Each container can be assigned a profile with specific dimensions. If repositories assign container profile details, repositories can then also use ""Calculate Extent"" to learn more about the total extent within specific collections, series, etc.   ""Calculate Extent"" will report linear feet, for example, by looking up each linked container and evaluating the container's dimension settings.

Examples: ...""
",Admin user,Many hours.  Probably should do more though ... it's hard to keep up to date with things that change,,"Maybe?  It has a lot of local specifics.  In practice and in principle, I'd rather see is better and *open* official documentation --- with clear docs per AS release.  Then my local docs could focus on workflow only, rather than restating all the software stuff AND workflow.  SO much work. I'm frankly behind on it. 

I actually think the proliferation of local docs is confusing. I have users who find all kinds of things online that don't apply to us or to our installed version. Better, more accessible, official documentation for the application would be a boon for all.  By better I mean, the writing should be written in clear, plain language.  I realize it's hard to keep up with, but the doc information is at times outdated. The jargon is at times too dense for newer users. AS should simplify and clarify. Use simple direct, plain language. And drop the paywall. 

I would rather put effort into the greater good, vs more local docs. I would be happy and willing to help work on the central AS docs. If they were better and more accessible,  I would encourage users to access them more.  But users balk at needing yet another AS login to access the docs, and even then, the docs can end up confusing anyway, so not worth it. 

I want to see AS open up access to the docs. I don't think it wise or good to withhold that for ""members only"".  We are members and even we would benefit from opening that up.  I would rather pay more for my membership to help support the community (I realize not all repos can do that, but think our management would support more -- esp if we were getting more out of it.  And if AS needs to think about it as 'getting more' or value added: frankly, open documentation IS 'getting more': it creates a more informed community and saves me the time of having to maintain local docs in parallel. 

Open documentation is a good call, both as a practical matter and in principle. It would be a better service if ALL users -- even a short term intern -- could easily access and learn about the system through the docs. It helps no one to be so secretive. 

Does ASpace really need to hold the docs so close? does anyone really require that the docs are secret as a condition of paying to join?  If you need to hold something aside 'special' for members: offer workshops, training, webinars ... but open up the docs. "
5/22/2019 13:08:35,"I wish to document local practices, I only want to document the features we use","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), Integrations with other systems",Yes,No,Yes,,"Head of manuscripts processing, head of technology",~10 hours on a one-time basis,No,"Documentation is directed at our own manuscripts processors, the specifics of which do not inform AS use as a whole (except where there are flaws in AS, which can be brought to the AS community in other ways)."
5/22/2019 13:15:40,"I wish to document local practices, We utilize a lot of students to do the processing and 1) don't want to give them access to the help website & 2) prefer to have control of when documentation gets revised based on the version of ASpace we are using","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), Plugins",Yes,Yes,Yes,"I use it to research features that we haven't used yet to see if they're worth implementing, e.g. Assessments, Rights",Department and Unit Heads.,"Usually updated when we move to a new version of ASpace, maybe 8 hours annually at most",Yes,"Happy to help.  As a former member of the documentation committee and a current member of the Training Corp, our local documentation (except for local practices) pretty much mirrors the Workbook and Help documentation that ASpace uses (or vice versa). I do have ""bonus"" documentation on things like importing MARCXML into OCLC, how to eliminate extraneous columns in the file you get when you Download CSV, etc."
5/22/2019 13:53:50,"I wish to document local practices, I only want to document the features we use","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules)",Yes,Yes,Yes,"I want to know how ""Aspace"" expects us to use certain fields. To make sure we are using the tool as expected or when we deviate why that makes sense for us and does not lead to problems later.","All staff have some responsibility, but primarily it is the Collections Coordinator.",2 hours per month,Yes,"Yes, with the caveat that we are planning a deed dive into our processes and procedures in the coming year and we would want to wait for that to be completed."
5/22/2019 14:30:40,"I wish to document local practices, I only want to document the features we use","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules)",Yes,Yes,Yes,"I find the official documention useful for understanding the system's capabilities or limitations, and understanding how to use ASpace. I try not to repeat that in our local usage manual, but focus on our application of the system. So, for example, our usage manual is silent on ASpace's component re-order process because it's just a core capability we use all the time, but there is nothing unique about our use of it. On the other hand, our usage manual goes on about notes: which ones we want to typically use, which ones we don't want to use, standard wording for certain notes. Our means of publishing finding aids and integrating those with the Reading Room call process requires certain field uses so the usage manual identifies those. All in all, while there is a degree of overlap, I see a role for both the official system user manual and a local practice guide.",Head of Archival Processing (me),"Several days initially, though I cribbed off NYU's base manual, and several hours to update periodically.",Yes,"I would be willing to share it, but given that it only documents local practice and its idiosyncrasies for a narrow range of ASpace functionality, its broader use is doubtful to me."
5/22/2019 14:52:24,"I wish to document local practices, The official documentation is sometimes a bit out-of-date.","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), Local practice, for example which fields to fill in, how, where to get the data values. BTW: I'm not sure why you think local practices are ""rules"" or what that word choice means to you.",Yes,Yes,Yes,"1) Comparison to see where we may differ or what is lacking, 2) making sure we are consistent with it or include statement on why we are doing something differently 3) and finally in hopes it has what we need so I don't have to write it. ",Responsibility it distributed. ,Less than 35 hours per year.,Yes,
5/22/2019 14:55:16,"I wish to document local practices, I only want to document the features we use, I find the existing documentation difficult to navigate, I find the existing documentation difficult to access, limited in providing guidance, and often out-of-date.","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), Plugins, Reports, Our local documentation includes examples of how to use certain records, sub-records, and fields.",Yes,Yes,Yes,"Administrators occasionally use the official documentation to check/verify features and functionality; otherwise most users use our local documentation because it is easier to access, navigate, and provide guidance on how we want them to use the system.",ArchivesSpace Admins group composed of collection management archivists and policy makers.,"Initial time spent: 1 month of intense effort; ongoing: minimal effort, primarily to address any changes in functionality or usage with new releases.",Yes,"We are happy to share our documentation in the hopes that it is useful to others. We benefited from other institutions' documentation that was available when we implemented, and want to make our resources available so that others can use them."
5/22/2019 15:16:06,I wish to document local practices,"Local practices (cataloging rules, subject and agent rules), Plugins",Yes,Yes,Yes,"I tried not to duplicate the information contained in the official documentation (https://docs.archivesspace.org), what I considered loosely to be ""application-specific how-tos"" (e.g. how to spawn a record, how to search, how to create a subject record), because it made more sense to keep ASpace docs as the offical location for that information and just refer to it via links. That way if functionality changed, we wouldn't have to update our documentation, but ASpace would update it. Our documentation was created to focus on local practices, both in terms of which fields and sub-records we ""required"" for accessions records, completed finding aids, etc, as well as examples of how we used those fields and sub-records.","The above answer is for work I did at a previous institution, and is probably how I will approach our documentation at my new institution -- so I'm responsible.","A significant amount of time upfront, but then maintaining is less time (as long as you update changes in practice when they happen)",No,"I don't have any to share from my new institution, yet!"
5/22/2019 15:39:12,I wish to document local practices,"Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules)",Yes,Yes,Yes,"It's extremely useful in understanding how to use ArchivesSpace. It's the first place I look when I have questions, and I refer to it regularly as I write our local guides. ",Archivist,Not sure yet. We are currently drafting our accession and resource records guides. ,Yes,"Maybe, once they are finalized. I am relying heavily on other institutions' documentation (as well as the official manual) in developing ours. It's valuable to see how other institutions are implementing ArchivesSpace, and I hope ours could be useful to someone, too. "
5/22/2019 15:48:25,"I wish to document local practices, I find the existing documentation difficult to navigate, I'm very new at archivesspace and the archivesspace docs assume that you know what you're doing.  Its difficult to piece it all together.",Plugins,Yes,Yes,Yes,I'll use anything I can find.,"Application Documentation is maintained by the Archivists, I maintain system documentation.","Not much yet, I'm just scratching the surface.",Yes,"The user group has been very helpful to me, I'd like to return the favor once I'm smart enough.  If I can make somebody else's life easier... great.  I only keep good fishing spots a secret.  "
5/22/2019 16:10:22,"I wish to document local practices, I find the existing documentation difficult to navigate, ArchivesSpace documentation was not thorough enough.","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), Plugins",Yes,Yes,No,The ArchivesSpace is occasionally consulted by those who have access to it and who write our local documentation. Not everyone at our institution who uses ArchivesSpace has access to the official documentation. ,There are four point people who have the ability to update the manual. We all update based on the section of the manual being updated. We all consult together on any addition or change to the manual. I am a Technical Services Librarian and I am the point person for all updates since I wrote the majority of the manual when we first starting drafting it in 2014.,Roughly ten hours per year. The initial draft to start the manual took about 80-100 hours. ,No,Our manual is very localized and in an ever evolving draft mode. :) We may be willing to share in a year or two. 
5/22/2019 16:49:52,"I wish to document local practices, I only want to document the features we use","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules)",Yes,Yes,Yes,I use the official documentation to learn how to use AS features and the intentional purpose of each feature. ,"Althea Topek 
Special Collections Library Associate 
Tulane University, Howard-Tilton Memorial Library
Jones Hall 202, New Orleans, LA 70118
504-247-1363 | atopek@tulane.edu ",,Yes,A significant chunk of our local manual is abstracted from the official AS documentation (https://docs.archivesspace.org) and the NYU local usage manual (https://docs.google.com/document/d/11kWxbFTazB6q5fDNBWDHJxMf3wdVsp8cd7HzjEhE-ao/edit)
5/22/2019 17:40:36,"I wish to document local practices, Documentation was created to facilitate staff training","Local practices (cataloging rules, subject and agent rules), Integrations with other systems, Reports, Workflows",Yes,Yes,Yes,Why reinvent the wheel?,It's a wiki that all staff maintain,"average 1 hour week, but we're in a time of rapid change",Yes,It's already public (github)
5/22/2019 17:45:16,I wish to document local practices,"Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules)",Yes,Yes,Yes,,,,,
5/22/2019 21:17:26,I wish to document local practices,"Local practices (cataloging rules, subject and agent rules)",Yes,No,Yes,"The official documentation is terrific, but often not very prescriptive. I don't think much consistency would result from using it alone.","Me, Peter Collopy, University Archivist, Caltech","Probably a few work days of drafting, and several meetings to get feedback. The initial process is not yet complete, so it hasn't reached the maintenance phase yet.",Yes,
5/22/2019 21:22:07,"I wish to document local practices, I only want to document the features we use","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules)",Yes,No,No,Forgot about it,Team effort,not sure,No,It's too local specific since the target audience is  someone who has never seen Archivesspace
5/23/2019 7:57:40,"I wish to document local practices, I only want to document the features we use, I find the existing documentation difficult to navigate","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), Integrations with other systems",Yes,Yes,Yes,"I do and don't... Once I understand the workflow, I don't need to consult it again, but new ArchivesSpace users often are really overwhelmed by it, thus don't even read it. I have to rely on in-person training and the local manual, because I know they won't read it.",Me,"It's a little out of date and do want to transition people to using the documentation, but there's still a need for a quick guide/local use manual. The manual was started before I arrived because, around in 2015, there wasn't an official manual. Things have improved a lot, so I recognise that I don't have to reinvent the wheel... But I just have to get others who aren't as committed to ArchivesSpace to log in... My personal opinion is that we volunteer our time to help ArchivesSpace as an open source program that the manual should be freely available. It's against the open source spirit, and the extra barrier of logging in discourages students, volunteers, and partial appointment staff from bothering to use it.",No,"Umm, I'm worried about it being not terribly polished for external viewers"
5/23/2019 11:50:44,"I wish to document local practices, I only want to document the features we use","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules)",Yes,Yes,Yes,It's a good starting place but it doesn't cover every field and why we may elect to use it or not,Digital Archivist currently; in consultation with the manuscript archivists,5-6 hours/year,Yes,It's a work in progress at the moment since we're new to AS and we maintain different documentation for different audiences using the system on our campus (so some documentation is a bit more beginners and some is more advanced)
5/23/2019 13:00:01,"I wish to document local practices, I only want to document the features we use, I find the existing documentation difficult to navigate","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules)",Yes,Yes,Yes,"I use the official documentation MYSELF. But I have a shorter version that is both simplified and tailored to our local practices, that I give to our student workers",Me,"We started with local documentation developed by a different repository using our same ASpace instance, so probably only about 4 hours tailoring it further for our very specific local use",No,"It's very specific to us. It says which notes to use and which to skip, and even includes boilerplate options for some of the notes (e.g. userestrict and accessrestrict)"
5/23/2019 13:05:31,"I wish to document local practices, When we started using ASpace the documentation was really minimal, so we had to create our own. We've just carried it forward as a way to document local practices","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules)",Yes,Yes,Yes,"I check in with it periodically to see if there is anything we might want to draw on for our local documentation. When I'm training a new staff person, though, I refer them to our local documentation since it's all-encompassing",me (director of archives) in consultation with colleagues,"now that it's written, maintenance is minimal. Maybe a few hours a year. I check it when we move to a new version. ",Yes,"I'm a little reluctant, because I think there are a lot of other examples out there and I don't think we necessarily do it better, or differently. There are clear leaders in the community who are sharing info; I don't think anyone would really look at our documentation if they had options from ""big name"" institutions. "
5/23/2019 18:22:02,"I wish to document local practices, I only want to document the features we use","Local practices (cataloging rules, subject and agent rules), Step by step guide for entering a finding aid from a PDF.",Yes,Yes,Yes,"We didn't have access when we started, so that was more based on what some other organizations have done. We do now, because it's outstanding.  However, it doesn't always address all of the issues that have come up for us.",Joint ,"Not sure.  Minimal for maintenance, though.",No,"It's very rough and very focused on what we do here.  Would probably share in a non-public way, though, if it would help."
5/23/2019 18:51:22,I wish to document local practices,"Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), Required elements, content standards",Yes,Yes,Yes,"It was useful for us while learning about the functionality, but we felt it didn't cover some aspects in enough detail.","Me (Karen Miller, Metadata Services)",Mainentance is probably about an hour per quarter. Too many hours to count were spent writing the initial document!,Yes,
6/5/2019 18:03:52,"I wish to document local practices, Setting up access for all of my staff to the ArchivesSpace member-only page is an added hassle. ","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), Plugins",Yes,No,No,"Rarely. I intermittently forget it exists, and even more frequently forget my ASpace login.",Self.,10 hrs/yr,No,It is likely either redundant to that provided by ASpace or specific to our institution.
6/6/2019 16:54:50,"I am unaware of the existing official documentation, I wish to document local practices, I only want to document the features we use","Core features (resource description, container management), Local practices (cataloging rules, subject and agent rules), Integrations with other systems",Yes,Yes,Yes,"I use the documentation to clarify use of features I don't use all the time, or recommendations for whether I might want to implement features not yet in use.",Me,"I maintain documentation for two repositories, and spend several hours each month making sure it's updated (I'm also orking with legacy documentation that is not completely updated)",Yes,