Diversity & resources selection

A previous thread (https://github.com/Devographics/surveys/issues/52) was opened about using more objective metrics to select resources to feature as pre-written, selectable options when people are taking a survey.

But relying solely on metrics presents the issue that we reinforce existing biases. For example, if mainly English speakers take the survey, then English-speaking video creators will get the most votes, and appear at the top of the rankings year after year even if some Spanish streamers may have more total viewers. And the same problem exists not just with language but with gender, race, etc.

Some potential solutions I'm considering:

### 1) Keep the rankings value-neutral but try to address the problem at the root by diversifying the survey audience.

- Pros: cleanest solution
- Cons: really hard to do, might not ensure a diverse final list

### 2) Manually set aside spots in each list for a quota of gender/race/language minorities

- Pros: ensures diversity
- Cons: hard to figure out right quota or where items should be seeded in the list

### 3) Set aside spots in each list for answers *by* gender/race/language minorities

In other words, instead of featuring e.g. women video creators, we'd feature video creators *cited by* women respondents (which may or may not be women themselves).

- Pros: less subjective than 2)
- Cons: might not ensure a diverse final list; same practical seeding issues as 2)

### Current Thoughts

I currently think 2) might be the best solution, if done right.

For example, out of a list of 10 items the first 7 could be ranked according to an objective metrics, while the last 3 would be hand-picked to highlight minoritized demographics (or even just less visible new entrants in a category that deserve to be highlighted), along with some kind of visual tag to indicate that.

Obviously this will irk some people (the "leave your politics out of my code!" crowd) but I think erring on the side of transparency is good, and clarifying why items appear or not in the survey it something we should be doing a much better job of anyway.

(Note that this is kind of what I'm already doing more or less by default, but this would clarify the process)

Read issue #52 and inspect the repository's YAML survey configuration to understand how selectable resources and rankings are currently defined. Before changing anything, resolve the proposed diversity policy and how transparency or visual tags should work; done means an agreed approach is reflected consistently in the relevant survey options.

Written by the indexing model from the issue text.