New form component for skill suggestions

[vikasrohit]

(Users can select multiple answers)
Answers:
Primary Answers: These answer options should be displayed immediately as checkboxes. It is optional for the user to complete this question.
Display this Text above the answer options: Most Commonly Requested Skills:

• Structured Test Case Creation
• Structured Test Case Execution
• Unstructured Testing
• Mobility Testing
• Performance Testing
• Test Automation

Secondary Answer Option:
Underneath the commonly requested skills, display a responsive field for the user to type in additional skills.

• Behind this field, data should be fed from the api (https://api.topcoder.com/v3/tags/?domain=SKILLS&status=APPROVED) to identify a prefill skills matching what the user has begun to type and recommended word-completion should be generated (Note: no data will be returned for QA as this is not a defined challenge format today, so data is spotty)
• If what the user types does not match member skill data being provided in the API, the user should still be able to complete typing and save their selection
• Users should be able to type multiple skills into this field

[maxceem]

1. As per discussion on Slack we should be able to enter new skills which are not listead by API. We should post them to the backend and after use their IDs to be stored in the project details. When we post skills to the API, I guess they wouldn't have status=APPROVED while initially we show only approved skills. This could lead to the fact there the skills which we post may be already stored in the backend, but we don't know about them as we only show APPROVED. So the final logic I guess would be something like this:

• We should retrieve from the API all the skills, not only APPROVED.
• We suggest to choose for the user only APPROVED ones.
• If users types a new skill which is not listed we are checking if we already got it from the API but it's just not approved.
• if the skill hasn't been returned from API even not approved, we should create a new one
• we save to the server skill ids as we do in our current solution, so we should wait until we post a new skill to the server before user can proceed.

[vikasrohit]

@maxceem I checked the API, and it seems we don't have the ability to update the skills without admin privileges. I think for now we can just store the custom skills typed by the user only in our connect database as our regular question in details json. We don't need to update it to the server.

[maxceem]

@vikasrohit so we would store skills names like Jekyll, Word/Rich Text, Interaction Design (Ixd) instead of their ids, right?

[vikasrohit]

I think we can keep id for the skills which are selected from our available skills. That way we would be able to identity that which skills are missing from system and needed to be added. We can store skills just like we are storing addons i.e. as array of JSON objects where each object would have name as compulsory field while id would be optional field for custom skills.

[vikasrohit]

@maxceem do you think when ca we get these changes (fetching the skills from the api)?

[maxceem]

@vikasrohit yes we can do that.

The only thing I'm not sure if we should move this component to the react-components. The logic feels quite specific to Connect app. It feels that react-components is good for basic components which would be reused multiple times like Select, Checkbox and so on. But the component for displaying skills in two ways with checkboxes and select feels like would be used only once.
What do you think?

[vikasrohit]

I think it makes sense to have this component in react-components (and later on we might have to move it to react-utils repo), because I think we can use this component in community app as well to let users select the skills with some frequent skills listed on the top and in fact we can configure out component in way that it won't show frequent skills if they are not specified in its props so essentially it would look like exactly same we have on the profile page in community app right now.

In summary, I think it is a good candidate to move to the react-components, however, it is not urgent to move it there. We can do that later, just log a ticket for this for future reference.

[maxceem]

Got it @vikasrohit.

The last thing. Currently, we filter skills based on the selected deliverables. We have the next values for deliverables:

design
dev-qa
qa
deployment

While in the data returned by API we have the next categories:

DESIGN
DEVELOP
DATA_SCIENCE

So there are two questions:

1. As I understand we can match design => DESIGN and dev-qa => DEVELOP. But we won't get any skills for qa and deployment. The same time we wouldn't use skills from DATA_SCIENCE category, right?

2. As this component is intended to be stored in react-components it should not know about the categories we use in our templates. The Skills component should still be able to filter by categories DESIGN, DEVELOP, DATA_SCIENCE while we keep logic to match design => DESIGN and dev-qa => DEVELOP inside the Connect app, and don't put it inside this component logic.
   Do you think this is the way to go for our intentions?

[vikasrohit]

I think we need to keep the mapping between the deliverables and skills categories, in the template itself and pass the final category that is determined from that mapping to Skills components in react-components and if no category is determined from the mapping or there is no mapping specified, we won't pass any category to the Skills component which would in turn not filter skills based on any category and would list all skills. This way we can configure the component from the template in a way that we don't filter the skills by category at all.

[maxceem]

and if no category is determined from the mapping or there is no mapping specified

If no mapping specified - we show the all the items - it's clear.

if no category is determined from the mapping

I have some concerns regarding this. If we didn't choose any deliverables then no categories would be determined. Should we show all the skills in such case? See how it looks at the moment:

[vikasrohit]

Yep, I think we should be good with that. We would hide (by moving it to next subsection) the skill picker until user selects the deliverables in the first step.