Taxonomy - Challenge Assumptions

[ExperimentsInHonesty]

Overview

Do we need Taxonomies? There are several taxonomies. Identify if all are needed for Project Index.

Assumptions

• We need a taxonomy for the brigades to use for project topics, technologies, skills
• It is crucial for success that all the brigades that will participate in Project Index will use the same taxonomy.

Action Items

• Challenge the assumptions by identifying other options
  • Identify pros and cons of other options
• Define what would be gained by using taxonomies over other options.

[ExperimentsInHonesty]

There are lot of Taxonomies.

See Issue codeforamerica/civic-tech-taxonomy#21 for details on the types and next steps for our team related to choosing and refining them.

Other Option

If we didn’t use a Taxonomy for everything we could use Boolean Searches.

Here is how that would work on each different proposed type of data:

---

Project Topics We could search the GitHub description for the project’s main repository.

Example: All projects addressing the issue of homelessness would show up in results when people type homeless or homelessness because one is a root of the other. It would also show up in a search for Housing if that word was used in the description. Also, some project span different topics. For instance LA has a project that addresses record expungement specifically for people experiencing homelessness. So if record expungement is also used in the description, then the project would come up with other projects having to do with record expungement as well.

Question? If we do not use boolean search for fields in our data set, we will need first topic, secondary topic, etc?

Github repositories currently allow 348 characters (informal test). We could also just have them put the text in a file or text string that is searched which would allow an even longer description.

• Pro:
  • It will be easier to get people to make a description on their GitHub for their project than to get them to wade through a taxonomy and decide which word or phrase fits the best. Having to deal with projects who’s work spans multiple Topics will be not be a problem.
• Cons:
  • It does not create a structured data set. So if data analysis of the raw data is one of our goals, then this could hamper that.
  • Someone could abuse the results by using every topic word in their description allowing their project to appear in every search.

---

Skills 
Needed Project Roles Technologies

Question? Can we use taxonomy on other fields? If we have the ability to search a file or string, then yes for these categories

• Pro:
  • Technology, Project Management and Design skills needed either change titles or new tech or roles get added. Keeping up with this is going to require quite a lot of upkeep work in order for the tool to be useable by new projects. Using Boolean searches removes the burden from the project maintainers.
• Cons:
  • It does not create a structured data set for analyzing things like what the most popular javascript framework across brigades is.

---

Project Status Project Stage The one category that agreement on a Taxonomy is crucial to having consistent results is Project Status and Project Stage

Example: If you are looking for a project that is Live in the market to use for your city, then getting a project that is just in ideation, is not going to do it. And to echo the con from above, if we want metrics across the all the brigades of how many live projects there are, or how many projects die in the ideation stage, etc. We will need a structured taxonomy for those types.

---

Next Steps

1. Review this document, and refer to it when we discuss Issue codeforamerica/civic-tech-taxonomy#21.
2. Add any additional pros or cons as comments to this document.
3. Add any additional examples that might help clarify as comments to this document.