Communicating with Curators about Reviewing and Changes #911
Replies: 4 comments 1 reply
-
@kristhayer11 and @salger1, I remember talking with both of you about navigating working with colleagues unfamiliar with Quire. Do either of you have any tips for @vhellstein or materials you can share that helped streamline communication/the review process with your stakeholders? @salger1 I remember you developed a course of sorts to help your colleagues better understand Quire. Do you have anything you can share in that regard? Thank you both for your time! |
Beta Was this translation helpful? Give feedback.
-
In my experience, the most challenging phase of the workflow for others to understand is the review process. Unfortunately, I was never able to get anyone else comfortable enough to work in Quire on an independent branch in Github. All the edits came through me. This was doable, but not recommended, and doesn’t make use of one of Quire’s most powerful capabilities...the ability of multiple collaborators to simultaneously work on a common project non-destructively. I would have loved to have curators and editors working alongside me, with Quire taking care of all the version control issues. However, we had to come up with a workaround. We ended up creating a google spreadsheet we all had access to. When our publication was ready for review, I distributed the url, the link to the spreadsheet, and a few bullet points of instruction. When we were ready for the review to begin, I asked for two primary types of feedback:
Each row on the google spreadsheet represented an edit and had columns:
This is not how I wanted to work--my last catalog the spreadsheet ran to 1,000 rows! But in the end, it was successful. Please let me know if you need more info or clarification on any of this. |
Beta Was this translation helpful? Give feedback.
-
So sorry about my delay! Short answer: our authors send us an email with a list of changes organized by page. They give us the beginning of the sentence where the change needs to be made. I never really explained that they don't need to point things out multiple times for universal changes unless it looks like it is eating up a lot of their editing time, it seems to comfort them to know we are aware of the extent of the problem. Longer explanation: I have one curator who works directly in markdown and has for years. She is pretty knowledgable about the basics of Quire and what is/is not possible while sometimes needing help to execute. To get her comfortable in Quire I taught all my colleagues about Quire, markdown, HTML, YAML, git, and command line but it only stuck for a couple of them. I can share the class docs if you want, but they are for V0 and fairly old at this point so I don't know how useful they would be. If you are going to have non-technical colleagues working directly in Quire you need a fairly good understanding of git. It is probably about once a month I have to help with a merge issue of some sort. Hopefully that wasn't too late for it to be helpful! Let me know if you have questions. |
Beta Was this translation helpful? Give feedback.
-
Thanks so much Stephanie! I'm working on a document to share with curators and other stakeholders to explain some of what you outline. It's just a matter of finding the right balance between understandability and technicalities. I don't think I'll ever get curators to work directly in markdown, but maybe I can dream! :) Luckily, I do have IT support who handles most of the merge issues, but I'm getting better at it myself. |
Beta Was this translation helpful? Give feedback.
-
We're currently working on our third and fourth Quire catalogs at the DAM, but I'm struggling with how best to communicate efficiently with Curators/CAs when it comes time to review a draft of a Quire publication. I think part of it is a lack of basic website literacy--how changes are made/easy vs. hard changes, how responsive design works and why it's important, style vs. content, expectations about digital vs. print, webpage vs. PDF, etc.
Short of opening up the hood and showing curators how the publication is actually built (which I can barely wrap my head around), has anyone been successful in communicating with stakeholders who aren't into the technology side of things that you don't have to comment on the style of a subhead or the notes section every time you encounter it? That content and style are separate things? We're trying out a "guided review" process on a current project, but I wonder if other folks have found successful ways to communicate changes between content and digital teams? Any insights/advice would be appreciated!
Beta Was this translation helpful? Give feedback.
All reactions