Make sure to clearly understand Type-A and Type-B requests, and the relevant limitations. Failing to follow the guidelines pertaining to the two acceptable types of RFWs will automatically lead to the disqualification of the RFW.
Take time to complete each section below with as much detail as is required to establish a comprehensive understanding of the underlying product specification.
ALL BELOW FIELDS ARE REQUIRED
The Problem
Lopenling users must be able to add their own dictionaries to be associated with their accounts.
User Story
The user goes to my.lopenling.org and clicks their account avatar in the right upper corner of the viewport. From here the user has the option to select Glossary which takes them to the administrative view for managing glossaries.
The administrative view for glossaries involves two things:
Being able to add and remove dictionaries
Being able to manage read rights for dictionaries
Being able to add and remove dictionaries
This has two parts. First, there is the ability to add and remove dictionaries that are native Lopenling dictionaries. Second, there is the ability to add and remove custom dictionaries.
In terms of native dictionaries, between zero and all available can be added. In terms of custom dictionaries, up to three can be added (i.e. if the user at any time tries to add more than three, it will not be allowed). Moreover, custom dictionaries can not exceed the length of 100k entries. Native dictionaries can have any number of entries.
Being able to manage read rights for dictionaries
All dictionaries, both native and custom, can be subjected to read rights. By default, all added dictionaries are visible to all users in the organization. Any dictionary, native or custom, can be restricted to be visible only to selected users.
As per the description in the User-Story section. Everything is already available in the backend. Here we are simply tying it together with user experience.
Is This Really Necessary?
This is necessary.
The justification for the part related to adding and removing dictionaries is that without this fulfilling this specification, users will not be able to add their own glossaries or remove the native ones they don't want to use.
The justification for the part related to being able to manage user rights pertaining to dictionary visibility is that without this fulfilling this specification, users will not be able to limit visibility to glossaries at the user level, which can cause important deviations from their particular guidelines and best practices.
Motivation
This is the natural next step in our progression towards drop-in replacing Padma.io while integrating those capabilities into the Lopenling eco-system.
Named Concepts
Native dictionary is a dictionary that comes with Lopenling. These are available by default for all users.
Custom dictionary is a dictionary that is added by the user.
Examples, Risks & Assumptions
Explain concretely what will manifest as a result of this RFW.
The User-Story section provides a conclusive description of what will manifest.
Explain how is it different from what is already manifesting i.e. what we already have?
We don't have anything like this currently. Everything has to happen through a request to an engineer.
Explain what users/brands will experience as a result of this RFW. How will they feel as a result of it? How will they benefit as a result of it?
Users will be able to integrate all of their glossary use into a single system. No longer having to switch between multiple systems serving the same purpose.
If applicable, provide sample messages for any new messages the system will display as a result of this RFW.
Once the GUI mocks are ready, and it is clear what messages are required, these will be provided separately. The engineer should request them from the owner of this RFW.
Define what is out of scope in this request.
Things like being able to edit the contents of the dictionaries and other more advanced features will be introduced in future RFWs.
What are the data protection, privacy, and security assumptions made for this request (for example, should this be GDPR, compliant, etc)
None. The only data security concern here is that we have to keep custom dictionaries strictly within the perimeter set by the user in the glossary administration view. In other words, dictionaries can't be shown beyond what is set in there.
Explain how this user story will be supported (i.e. customer support - if the user story fails technically, how will the user be supported).
NA
Explain how this user story impacts revenue or billing (if applicable).
NA
State any additional risks identified as a result of this user story.
Data loss. The user saves their dictionary in Lopenling and thinks it is safe. We lose it, they don't have a backup, and they lose years, sometimes decades, of work.
Success Metrics
Users feel great with the experience they have adding and removing glossaries, as well as managing rights related to that.
Conceptual Design
The User-Story section provides sufficient detail to understand the conceptual design.
Drawbacks
This is a very simple implementation, which lives in total isolation from everything else (in the glossary administration section).
Alternatives
At this point, the alternatives are not viable.
New Data
This does not introduce any new data artifacts that we don't already have. The nuance here is that we will now become responsible for users' data, so we do have to consider the risks that come with it. I think a simple way to think about this is that we have a Github as a backup; for example, once per hour, we sync all custom dictionaries in a private Github repo so that the latest version is always there.
Table of Contents
Housekeeping
Make sure to clearly understand Type-A and Type-B requests, and the relevant limitations. Failing to follow the guidelines pertaining to the two acceptable types of RFWs will automatically lead to the disqualification of the RFW.
Take time to complete each section below with as much detail as is required to establish a comprehensive understanding of the underlying product specification.
ALL BELOW FIELDS ARE REQUIRED
The Problem
Lopenling users must be able to add their own dictionaries to be associated with their accounts.
User Story
The user goes to my.lopenling.org and clicks their account avatar in the right upper corner of the viewport. From here the user has the option to select
Glossarywhich takes them to the administrative view for managing glossaries.The administrative view for glossaries involves two things:
Being able to add and remove dictionaries
This has two parts. First, there is the ability to add and remove dictionaries that are native Lopenling dictionaries. Second, there is the ability to add and remove custom dictionaries.
In terms of native dictionaries, between zero and all available can be added. In terms of custom dictionaries, up to three can be added (i.e. if the user at any time tries to add more than three, it will not be allowed). Moreover, custom dictionaries can not exceed the length of 100k entries. Native dictionaries can have any number of entries.
Being able to manage read rights for dictionaries
All dictionaries, both native and custom, can be subjected to read rights. By default, all added dictionaries are visible to all users in the organization. Any dictionary, native or custom, can be restricted to be visible only to selected users.
Request Type A/B
Type-A
Owner
https://github.com/mikkokotila
Summary
As per the description in the User-Story section. Everything is already available in the backend. Here we are simply tying it together with user experience.
Is This Really Necessary?
This is necessary.
The justification for the part related to adding and removing dictionaries is that without this fulfilling this specification, users will not be able to add their own glossaries or remove the native ones they don't want to use.
The justification for the part related to being able to manage user rights pertaining to dictionary visibility is that without this fulfilling this specification, users will not be able to limit visibility to glossaries at the user level, which can cause important deviations from their particular guidelines and best practices.
Motivation
This is the natural next step in our progression towards drop-in replacing Padma.io while integrating those capabilities into the Lopenling eco-system.
Named Concepts
Native dictionary is a dictionary that comes with Lopenling. These are available by default for all users.
Custom dictionary is a dictionary that is added by the user.
Examples, Risks & Assumptions
The User-Story section provides a conclusive description of what will manifest.
We don't have anything like this currently. Everything has to happen through a request to an engineer.
Users will be able to integrate all of their glossary use into a single system. No longer having to switch between multiple systems serving the same purpose.
Once the GUI mocks are ready, and it is clear what messages are required, these will be provided separately. The engineer should request them from the owner of this RFW.
Things like being able to edit the contents of the dictionaries and other more advanced features will be introduced in future RFWs.
None. The only data security concern here is that we have to keep custom dictionaries strictly within the perimeter set by the user in the glossary administration view. In other words, dictionaries can't be shown beyond what is set in there.
NA
NA
Data loss. The user saves their dictionary in Lopenling and thinks it is safe. We lose it, they don't have a backup, and they lose years, sometimes decades, of work.
Success Metrics
Users feel great with the experience they have adding and removing glossaries, as well as managing rights related to that.
Conceptual Design
The User-Story section provides sufficient detail to understand the conceptual design.
Drawbacks
This is a very simple implementation, which lives in total isolation from everything else (in the glossary administration section).
Alternatives
At this point, the alternatives are not viable.
New Data
This does not introduce any new data artifacts that we don't already have. The nuance here is that we will now become responsible for users' data, so we do have to consider the risks that come with it. I think a simple way to think about this is that we have a Github as a backup; for example, once per hour, we sync all custom dictionaries in a private Github repo so that the latest version is always there.
Business release date
This is the required next step for Lopenling.