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 about the underlying product specification.
ALL BELOW FIELDS ARE REQUIRED
The Problem
The high level abstract object in Lopenling/Translate is going to project. At the moment, there is no functionality related with managing such objects (arising from creating new projects). Therefore, we must create this.
NOTE: Within the current system for glossary and user management, there are particular considerations to be made regarding that, together with this RFW.
User Story
Story 1) User gives the project the following:
Name
Source language
One or more target languages
Assign it to a team
Story 2) User is able to observe and manage projects in a single view:
NOTE: Story 2 is not pertaining to the actual translation content, but to the meta aspect of the project.
Payload storage pattern and setup for project payload
Integration with User-Management sub-system
Is This Really Necessary?
Yes, this is really really necessary, because it was actually requested by engineering. No, just kidding, while that is something quite extraordinary, we also have to make the case from the product perspective. This is necessary because we don't have any means by which a project could be managed even minimally now. This tends to lead into the requirement for engineers to manage projects for users, which can be highly detrimental to motivation and overall developer experience. That is one reason. Then, from the user perspective, it is little bit more nuanced, because we could offer a solution which always works at the level of a the translation view alone, but I think we would deeply regret it down the road for a plethora of reasons I will not go further into here.
Motivation
The motivation have been made crystal clear in the above section/s.
Named Concepts
NA
Examples, Risks & Assumptions
Explain concretely what will manifest as a result of this RFW.
The previous already cover this.
Explain how is it different from what is already manifesting i.e. what we already have?
We don't have anything related.
Explain what users 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?
Explained in the user stories section.
If applicable, provide sample messages for any new messages the system will display as a result of this RFW.
Engineering will provide google sheet with the required messages once all that becomes clear from the RFC following this RFW.
Define what is out of scope in this request.
Not applicable here.
What are the data protection, privacy and security assumptions made for this request (example, should this be GDPR, compliant etc)
Not applicable here.
Explain how this user story will be supported (i.e customer support - if the user story fails technically, how will the user be supported).
Through regular user support channels.
Explain how this user story impacts revenue or billing (if applicable).
Not applicable here.
State any additional risks identified as a result of this user story.
Data risk arising from the possibility of losing data. Losing the project object, and particularly the source and target language content is the single most critical data risk mitigation in the entire Lopenling project.
Success Metrics
The scope of work provided in this RFW is going reach fulfilment.
Conceptual Design
All required information is conveyed above.
Drawbacks
Not applicable.
Alternatives
Adopt open-source package to do it? Use something that is already built? There is also the kind of whacky option of re-thinking how this whole pattern plays out and placing capabilities typically associated with higher level management functions, deeper into the project.
New Data
For this RFW, I think we can talk about it being a new data object, which consists of two data sub-objects. The new data object, is the project object. Then, the two data sub-objects are 1) project meta object, and 2) project content object.
NOTE: It would be super duper nice, if here we can make the difference between what the data object is, and what the payload is, disappear. That is to say, that whatever interacts with the payload, it's always the one and the same payload. If it is stored, it is the same, if it is used by API, it is the same, and if it in the GUI, it is the same.
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 about the underlying product specification.
ALL BELOW FIELDS ARE REQUIRED
The Problem
The high level abstract object in Lopenling/Translate is going to
project. At the moment, there is no functionality related with managing such objects (arising from creating new projects). Therefore, we must create this.NOTE: Within the current system for glossary and user management, there are particular considerations to be made regarding that, together with this RFW.
User Story
Story 1) User gives the project the following:
Story 2) User is able to observe and manage projects in a single view:
NOTE: Story 2 is not pertaining to the actual translation content, but to the meta aspect of the project.
Request Type A/B
Type-A
Owner
mikkokotila
Summary
User-Managementsub-systemIs This Really Necessary?
Yes, this is really really necessary, because it was actually requested by engineering. No, just kidding, while that is something quite extraordinary, we also have to make the case from the product perspective. This is necessary because we don't have any means by which a project could be managed even minimally now. This tends to lead into the requirement for engineers to manage projects for users, which can be highly detrimental to motivation and overall developer experience. That is one reason. Then, from the user perspective, it is little bit more nuanced, because we could offer a solution which always works at the level of a the translation view alone, but I think we would deeply regret it down the road for a plethora of reasons I will not go further into here.
Motivation
The motivation have been made crystal clear in the above section/s.
Named Concepts
NA
Examples, Risks & Assumptions
The previous already cover this.
We don't have anything related.
Explained in the user stories section.
Engineering will provide google sheet with the required messages once all that becomes clear from the RFC following this RFW.
Not applicable here.
Not applicable here.
Through regular user support channels.
Not applicable here.
Data risk arising from the possibility of losing data. Losing the project object, and particularly the source and target language content is the single most critical data risk mitigation in the entire Lopenling project.
Success Metrics
The scope of work provided in this RFW is going reach fulfilment.
Conceptual Design
All required information is conveyed above.
Drawbacks
Not applicable.
Alternatives
Adopt open-source package to do it? Use something that is already built? There is also the kind of whacky option of re-thinking how this whole pattern plays out and placing capabilities typically associated with higher level management functions, deeper into the project.
New Data
For this RFW, I think we can talk about it being a new data object, which consists of two data sub-objects. The new data object, is the project object. Then, the two data sub-objects are 1) project meta object, and 2) project content object.
NOTE: It would be super duper nice, if here we can make the difference between what the data object is, and what the payload is, disappear. That is to say, that whatever interacts with the payload, it's always the one and the same payload. If it is stored, it is the same, if it is used by API, it is the same, and if it in the GUI, it is the same.
Business release date
Not applicable.