Skip to content
This repository has been archived by the owner on Sep 24, 2022. It is now read-only.

Create user personas #2

Open
barbaricyawps opened this issue Sep 21, 2020 · 3 comments
Open

Create user personas #2

barbaricyawps opened this issue Sep 21, 2020 · 3 comments
Assignees
Labels
glossary project For issues that are specifically related to the glossary project

Comments

@barbaricyawps
Copy link

We need to create a set of user personas for the glossary project and validate those personas with project contributors.

@barbaricyawps barbaricyawps added the glossary project For issues that are specifically related to the glossary project label Sep 21, 2020
@barbaricyawps
Copy link
Author

I'm brainstorming a few possible use-case scenarios for the glossary project that we can use as we're thinking through our user personas.

Parent-child scenario - In this scenario, there is an authoritative parent guide that a smaller guide wants to inherit terms from. For example, let's imagine Google has developed a glossary for developer terms that I want to inherit in my smaller open-source project. So one persona would be the maintainer of the standard guide (the parent) and another persona would be the maintainer of the new open source guide. The maintainer of the open source guide might want to mostly inherit terms, but add some new ones, or modify a few of them for their needs. They might also want to submit their changes upstream to the parent guide.

Peer-to-peer scenario - In this scenario, there are two organizations that have developed their own separate guides with their own unique definitions. These two peer guides might want to import the terms from the other guide, but merely to use them as reference and identify how they are different. They might not want to merge, but just be aware of each other and cognizant of the differences.

Merging peers - Much like the previous scenario, we might have two organizations with their own separate guides that now want to merge their guides together and resolve all the merge conflicts.

These are just my initial thoughts on it. Are there other scenarios?

@barbaricyawps
Copy link
Author

We got some excellent feedback in tonight's meeting:

  • @camerons points out that in the parent-child scenario, in some cases the child glossary might want to be able to submit glossary terms upstream to the parent.
  • Rob mentioned that one scenario is that some glossaries will be less structured than others. Part of the process will be to "clean up" terms to make them more structured for integration.
  • Ron points out that we're going to need to support a range of different schemas that need to be supported but we should start with commonly used standards.
  • When @Naini-K asked for some clear job titles or roles, Cameron suggested we should keep it a little basic and use personas like "glossary maintainer" and "glossary contributor"

@camerons
Copy link
Member

camerons commented Nov 3, 2020

We did another variant of the persona split in our Glossary pilot manifesto:

User stories

This project is designed to address the following use cases:

  • As a general document reader, I want to find definitions for the terms and acronyms in the document I am reading. There may be multiple definitions for a term, determined by context, or having multiple upstream source definitions.
  • As an advanced document reader or term maintainer I want to understand the inheritance path back to upstream source definitions.
  • As a technical writer, I want to find the preferred spelling, capitalization and word choice for a term.
  • As a technical writer, I want a tool which builds a glossary of the organisation specific terms used within my document, by searching my organisation’s glossary.
  • As an organisation, I’d like a tool which seeds my organisation specific glossary by searching my organisation’s docs for terms in a superset of reference glossaries.
  • As a document translator, I want glossary terms to be translated into my target languages, so I can consistently translate a source term to the same target term.
  • As a project, I want a glossary which includes terms specific to my project, as well as terms sourced from multiple external glossaries.
  • As a foundation, I want a glossary which sources terms from my many sub-communities.
  • As a glossary owner, I want to ensure my glossary is continuously updated to align with updates in my source glossaries.
  • As a software developer, I want terms and relationships between glossaries in a machine-readable form so that I can integrate glossary functionality into software.
  • As a data modeller, I want the terms described in my model to use existing term definitions, (from APIs, standards, etc), as defined within my domain, so that I can share my terms with others, and seamlessly integrate datasets from multiple sources.

@barbaricyawps barbaricyawps removed their assignment Mar 22, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
glossary project For issues that are specifically related to the glossary project
Projects
None yet
Development

No branches or pull requests

4 participants