2019-11-22 Documentation meeting agenda/notes
Date
12:00pm EDT / 11:00am CDT / 10:00am MDT / 9:00am PDT
Attendees
Kandice Harris
Angela White
Not in attendance
Conference Call Info
https://ucla.zoom.us/j/178232231
Dial by your location
+1 669 900 6833 US (San Jose)
+1 646 558 8656 US (New York)
Meeting ID: 178 232 231
Find your local number: https://ucla.zoom.us/u/aLp51XpUu
Discussion items
Item | Time | Who | Discussion Topics and Questions | Notes |
---|---|---|---|---|
Roll Call | 5 minutes | Note taker: Kevin | New team member, Kandice Harris, taking the place of Jamie Weeks from Weber. Rotate notetakers alphabetically. Sarit Hand will be notetaker at next meeting. | |
Updates from Jessica | 15 minutes | Jessica Crouch | Progress with new help center and tentative launch date Sections to prioritize for augmentation: digital objects, events, and classifications Review and editing of early drafts of new sections: languages and ARKs | Administrators in the Help Center for member institutions should clean up their accounts in the old help center soon. The new Help Center is hoped to be launched on December 13; by then we (the User Docs sub-team) should be happy with the pages that are presently in the User Manual. Jessica has been making a few structural changes to the User Manual to transform it into the Help Center; the old manual is still there in the form we recognize, Jessica is just going about adding links to training videos and other resources in different formats which were not in the Manual before. At some point in the next week or two we'll get a chance to look through the new Help Center and let her know if there are any bugs or issues related to accessibility, user experience, etc. that will make the Help Center difficult to use. New pages (languages and ARKs) ready to go by December 13. These are the only sections that are missing from the docs at the moment, since they're new with 2.7.0. Links are in the column to the left. Jessica proposes that these could be used as guidance as we come up with a formal process for creating and revising existing docs in the user manual. Sarit asked what specific aspects of DOs/Events/Classifications get feedback. Jessica said most comments indicate that it's just very "flimsy," not very robust. Sarit noted that these are sections of the application that don't get used consistently across institutional ArchivesSpace instances. Should we provide use cases or examples of use in the manual, or do we not want to be that prescriptive? Ex. digital objects, which let you be very descriptive about what the digital object is – does that level of complexity lose people? Is that how people are using ArchivesSpace?
Have a page of link to other resources in the manual that are useful Make the manual more approachable in the language (user). Current language is formal. Any documentation about what the user manual has historically set out to do, or assumptions in the ArchivesSpace data model? Should we provide some? |
Updates from last meeting | 5 minutes | Jasmine Jones (Unlicensed) | Connecting to Testing sub-team and Dev Pri ticket activity |
The next community call is scheduled for January 22; it could be a good opportunity for User Docs to reach out to discuss some of these issues, if there are topics we want to talk about. |
Review and discuss 2019-2020 workplan | 20 minutes | Jasmine Jones (Unlicensed) | UAC Documentation Sub-Team: 2019-2020 Work Plan Feedback on timeline, other objectives and activities to undertake Assigning leads and team members to different objectives | Strategies for completing the work plan:
What's the difference between work plan items 1 and 2?
Work plan item 4 ("Develop documentation for users about how to use new User Manual and Help Center") is LYRASIS' responsibility so we don't have to do it. Jasmine will remove. Comments on the Help Center are public. We'll need an editorial process for that. Should we clear comments when their issues are resolved, and/or keep a record of comments as they are submitted? Can we generate Jira issues from comments, and have them assigned to User Docs members? In Jira comments may be directed to bug reports or feature requests, where Dev Pri will prioritize them. We would need a way for Dev Pri to divert these tickets to User Docs. Or would it be easier to just address issues directly as comments come in, and only create a Jira ticket for comments requiring more substantial action? Team members volunteered to take on the lead for various Work Plan objectives. These are documented on the Work Plan page. Team members also volunteered to look at the five sections of documentation that were prioritized for revision/augmentation:
Drafts done by so that there's time for feedback from other User Docs members that week. Feedback on drafts due on Update documents on Confluence on |
Team onboarding documentation and communication | 10 minutes | Jasmine Jones (Unlicensed) | What information do/did you wish you knew to onboard onto this team? What channels should our team use to communicate? | |
High-level Confluence overview | 10 minutes | Jasmine Jones (Unlicensed) | ||
New business | 5 minutes | All | Documentation requests from TAC | Tech Docs received requests for enhanced documentation regarding the definition of permissions in the staff interface, and on ingest using MARCXML. These seemed out of scope for them, so they wanted to forward them to our attention. |
Action items
- Type your task here, using "@" to assign to a user and "//" to select a due date