Audiences, content_types, tasks, and subject_domains are the new fields introduced by https://meta.wikimedia.org/wiki/Toolhub/Data_model#Taxonomy_v2 which will be empty for nearly everything at this point.

The taxonomy v2 fields plus tool_type, for_wikis, and available_ui_languages are the most expected to be useful for tool discovery search facets.

In T328335#8570758, @bd808 wrote:

Audiences, content_types, tasks, and subject_domains are the new fields introduced by https://meta.wikimedia.org/wiki/Toolhub/Data_model#Taxonomy_v2 which will be empty for nearly everything at this point.

The taxonomy v2 fields plus tool_type, for_wikis, and available_ui_languages are the most expected to be useful for tool discovery search facets.

Thank you for the input; that's very useful information. tool_type and for_wikis were on my high-priority list, and I'll add available_ui_languages as well.

I'm curious about the taxonomy v2 fields; they felt a little subjective to me, but since the field appears to accept multiple values the hypothetical person-making-an-update doesn't have to restrict their response to, say, a single audience type.

Here are my thoughts about the fields.

Given @bd808's input about their expected usefulness, I think we should certainly prioritize tool_type, for_wikis, available_ui_languages, and the v2 fields (audiences, content_types, tasks, and subject_domains).

I'm also in favor of prioritizing repository, as it seems like that's one field that can open up a lot of other fields: where we find the repository, we're likely to find documentation, a bugtracker, a location for feedback, etc.

The lowest-priority fields, IMO, would be wikidata_qid (it feels like locating wikidata_qids is something that could be automated) and icon.

Deprecated and replaced_by deserve special mention. What I would like/intend to do is check the value of deprecated on all incoming tools and prevent the creation of any tasks pertaining to a tool where deprecated == True unless the "replaced_by" field has no value, in which case that would be a high-priority task. If a tool should for some reason become deprecated, I'd like to either flag or remove other tasks for that tool so that they don't get sent out in the task bundles.

Something for the presentation layer:

The v2 fields and tool_type only allow for responses chosen from a list of possible responses (the v2 fields allow for multiple choices, whereas tool_type allows for only one).

It's worth considering how we want to represent this: a drop-down menu? Radio/checkbox inputs?

In T328335#8570802, @NicoleLBee wrote:

I'm curious about the taxonomy v2 fields; they felt a little subjective to me, but since the field appears to accept multiple values the hypothetical person-making-an-update doesn't have to restrict their response to, say, a single audience type.

These fields are a bit like categories and it is expected that tools may fit for multiple values at the same time, especially for audiences and tasks. There is some amount of subjectivity in these types of classification, but that I think is to be expected with categorization.

In T328335#8570929, @NicoleLBee wrote:

The v2 fields and tool_type only allow for responses chosen from a list of possible responses (the v2 fields allow for multiple choices, whereas tool_type allows for only one).

Toolhub itself could be updated to provide API endpoints for getting the lists of allowed values for these fields. The OpenAPI spec includes enums for them, but those enums are only for the "native" values that are stored in the database and do not include display values in the original English or any translations that we may have from the translatewiki.net community.

Further to today's discussion:

Fields we won't be implementing at start: (i.e., the ones that take arrays, or potentially take arrays)
developer_docs_url
user_docs_url
feedback_url
privacy_policy_url
deprecated
experimental
for_wikis
available_ui_languages

That leaves us with the following, sorted by input type:

String
wikidata_qid (requires pattern)

String(URL)
replaced_by
icon (requires pattern)
repository
api_url
translate_url
bugtracker_url

Enum array
audiences
content_types
tasks
subject_domains

Single enum value
tool_type

For icon & wikidata_qid I can pass the required pattern along with the other field-related data, or we can skip those as well if we want to wait on validation. Do we want to validate URLs? I can pass a regex pattern with those fields, too.

I'd be inclined to skip replaced_by – not sure how easy that info would be to find for someone unfamiliar with the tool, and also probably rare in general.

On the other hand, we had identified for_wikis and available_ui_languages as fields to prioritize earlier:

In T328335#8570929, @NicoleLBee wrote:

Here are my thoughts about the fields.

Given @bd808's input about their expected usefulness, I think we should certainly prioritize tool_type, for_wikis, available_ui_languages, and the v2 fields (audiences, content_types, tasks, and subject_domains).

In T328335#8603959, @Slst2020 wrote:

I'd be inclined to skip replaced_by – not sure how easy that info would be to find for someone unfamiliar with the tool, and also probably rare in general.

On the other hand, we had identified for_wikis and available_ui_languages as fields to prioritize earlier:

replaced_by is a special case, for sure, and figuring out how to deal with it was fun. In terms of frontend implementation, it's easy to handle (just requires a URL) and the frontend's already handling a bunch of fields just like it, so I figured that there was no reason not to include it.

The trouble with for_wikis and available_ui_languages is that they both require special validation and can accept multiple inputs, so they're trickier to present on the frontend. There are ways, but it's a question of how much complexity we (or, more accurately, @Hannah_Njoroge and @Damilare) want to deal with right now.

What is the status of this task? It's in the review column, but it's not clear to me whether any feedback or decision is needed at this time. Maybe we could summarize what fields we decided to include in the MVP and consider this done for now?