# Repositories, structure, and terminology
# Introduction
The following sections introduces a few important business concepts that are essential for understanding the structure of the different repositories, packages etc.
# Terminology
In general, we like to avoid too much company specific terminology, but there is a few terms that you must be aware of to gain value from this site.
The list below outlines what we consider essentials:
| Client / Requesters / Customer | The customers of no-more. The people for who we work. |
|---|---|
| Specialists / Designers / Freelancers | The "designers" / freelancers that conduct most of the work for the clients. Note: Until around 2020 we referred to these as specialists, but changed it to Designers to better reflect their role |
| Project managers / Admins | Our internal team of colleagues who conduct quality assurance of projects and deal with clients on each project. On the KnowMorePlatform these are referred to as "admins" in the code |
| Customer success | A team in no-more responsible for helping clients become more success and use the service in the best possible way |
| " NM" | = NoMore – the previous name of the company and is normally related the customer facing brand of the business |
| " KM" | = KnowMore – the specialist facing brand of the business |
# Key data concepts and dependencies
Certain core concepts of the application and how they relate are outlined below. Many of these are important to understand in order to work on the platform:
# SlideHub products
As a company we provide two main products, an on-demand PowerPoint Service, and a web/add-in offering we refer to as PowerPoint Software. Additionally, we sometimes help clients using the PowerPoint software via an offering we refer to as Slide Management.
# Understanding the PowerPoint Service
What we do: In short we provide a service to help busy business people to make well designed PowerPoint Presentations - fast! The clients sends (via email, web or addin) draft presentations and we then make them highly designed.
The service is delivered to our clients via an combination of our pre-vetted freelancers (specialists) and our in-house team of project managers (members of SlideHub as a full time employees).
Both designers and project managers conduct their work via our freelance and project management platform: app.knowmoreplatform.com
# Tasks / request / subproject
All work we do for clients / customers center around solving their "problems". From a coding perspective, these "problems" take different form depending on the "level" of granularity in which we operate. We operate with three different "layers" that are important to understand how relate:
Requests are the highest level. Requests reflects / mirrors a conversation with the customer on Zendesk (our main ticket handling system). A request can have many tasks , but most often there are only have 1 or 2 tasks per request.
A task is a "job" to be conducted for a customer in relation to a request made by the customer (also called "requester" – see later). A task has information about the overall instructions, the client's deadline etc. A task can (and must have) one request.
Subprojects are the lowest level of the three. Subprojects are what the specialists apply for and work on. Subprojects often inherit a lot of information from the task, but only contain several specific information unique to that subproject e.g. specialist deadline, hours of work to be conducted, descriptions. A subproject must have 1 task, but tasks can have multiple subprojects (75% of tasks only have 1 subproject.
Its really important to understand these three "levels". Throughout the code base some concepts are related to requests, some to tasks and some subprojects. Which one depends on the UX and the specific case.
# User types
For the purpose of authentication we have two types of "users" on the knowmore repository the users are found in the "Users" model and on nomorePost the users the found the "Requesters" model.
On knowmore there are 3 types of users as of now – who of which are defined by the "type" property on the user object:
- Specialists (freelancers / designers)
- Admins (in house project managers)
- TeamLeads (type = admin – but identified via UserTeamLeadMap table)
Specialists are then further classified by where in the application / onboarding process they are.
For specialists that have passed the entire application and onboarding process they are further characterized by their level (1-5) depending on the subproject ratings (volume and performance)
# Companies and requesters
We do not have "teams" but we operate instead with "companies". Thus, the people (humans) using our service is referred to as "requesters" and not customer/clients.
A requester is identified via their email.
A requester must have 1 and only one company.
A company must have 1 and only one team owner / manager – who is the only one responsible for handling changing to the company details, kick members etc.