Description

Summary

Develop at least one low-effort way to receive ongoing feedback from users about Openverse’s usability, both things that work and things that don’t work.

Background

Openverse users currently have three main methods to deliver feedback:

1. The Google form in the Openverse.org website, behind the "Feedback" link in the homepage header. This form is unmonitored and to my knowledge not a single Openverse maintainer regularly reviews the information from the form. The form's fields are also poorly structured and do not do a good job capturing the various reasons why someone could be giving feedback. The form gets a lot of spam.
2. GitHub issues. GitHub requires a separate account, potentially one completely irrelevant to a lot of Openverse users. It is also a specialist website, with terminology specific to the development of software, rather than the management of feedback about software features. We almost never get feedback about Openverse in this way other than from relatively technical folks or people already involved with the project.
3. WordPress's communication channels like the Make blog or Make chat. We sometimes receive helpful feedback here, especially from within the WordPress community, but rarely from folks outside the existing WordPress community.

We also sometimes receive email, though these are usually emails for/from integrations rather than from regular users. Some users also use the content report form to give feedback, but that's not ideal because it's not the right place for feedback to go. It is also not a well-structured form for feedback, as its goal is for reporting media on Openverse, not for feedback about Openverse itself.

Of these, only the unmonitored, spammy Google form is presented to users in any kind of meaningful or direct way as a method of feedback delivery. We never solicit feedback directly from users (for example, by prompting regular users to give feedback).

There are a variety of people who have an interest in the maintenance and improvement of Openverse. These are non-exclusive categories (individuals can be in more than one):

• Users, within which there are at least the following important subdivisions:
  • Educators
  • Students
    • Primary
    • Secondary
    • Tertiary
  • Young people generally
  • Older people
  • People with low technological literacy (people for whom using computers or the web is not “intuitive”)
  • Bloggers
  • WordPress editors
  • People in the various regions of the world
  • People who speak languages other than English
• Creators whose works are included in Openverse
• Providers/sources
• Openverse maintainers
  • Designers
  • Translators
  • Coders

Very few (if any) of our available feedback mechanisms are well suited to these categories of people. The goal of this project is to change that by adding some way of soliciting feedback directly from users of Openverse.org, following some heuristic to decide when to prompt for feedback. The project also includes the creation of the feedback repository, whether it's reusing one of the existing ones, or creating/using a new tool or approach.

In short, we need input from these different categories of people, especially the various types of users, but we do not make it easy for them to give input at the moment. We also do not proactively seek input, relying instead on a passive stream of input. Both of these approaches have resulted in the development and prioritisation of Openverse feature being informed almost exclusively by Openverse developers and WordPress Foundation's needs. Those aren’t necessarily bad sources, and we fall into some of the other categories above as well, they’re just not the only sources we should consider, and the needs of users should be paramount in informing our decisions, much more so than our "hunches". Our position as people with high technical literacy and deep familiarity with Openverse inextricably colours our perception of what works and what doesn’t. It is vital to get input from people who do not have those same preconceptions or experiences.

At minimum, the project proposal should explore different methods of feedback collection, ideally, evaluating approaches and tools that others in a similar domain to ours use. When searching for these, consider Openverse's domain to be the following:

• WordPress community
• FOSS internet infrastructure
• Search
• Education

Some examples are:

• Plausible's feedback site: https://feedback.plausible.io/
• Kagi's feedback site: https://kagifeedback.org/
• Make WordPress: https://make.wordpress.org/
• Yoast: https://yoast.com/help/support/

The project proposal should also identify the heuristic we will follow to identify users to prompt for feedback. Examples of heuristics:

• A user has completed at least N distinct searches and at least X have resulted in click on a single result
• A user has clicked the "Get this <...>" button on Z different single results
• A user has spent > M minutes on Openverse.org

There should be at minimum the following implementation plans:

• Infrastructure set up for the feedback mechanism (e.g., creating a new form, standing up a new feedback service, etc)
• Implementing the prompt for feedback into Openverse.org based on the heuristic defined in the project proposal

This project also requires design input depending on the outcome of the project proposal.

Documents

• Project Proposal
• Implementation Plan(s)

Milestones/Issues