Page MenuHomePhabricator

Surface Open Access content in The Wikipedia Library
Open, Needs TriagePublic

Description

The Wikipedia Library was created to solve the problem of Wikipedia volunteers not being able to access paywalled content from non-open access publishers. To that end, it now contains more than 100 collections hosting paywalled content. Users have often requested that the library also index major open access publishers, and we've found that in many non-English countries, major publishers are often hosting their content online without a paywall, which has contributed to a lack of content in non-English languages.

If we want to address knowledge equity issues in the library, and enable the library to be a better one-stop-shop for research, we should enable editors to browse and access open access content from the library too.

The primary reason this hasn't been done yet is that there is a potentially infinite number of sources which could be added to the library, and we were concerned at the workload this would generate for TWL staff to add and maintain data on these sources. We have also simply focused our efforts on the library's primary aim of facilitating access to paywalled content.

Proposed solution

To address this need, we could develop a community-based solution which facilitates Wikimedia community members adding, updating, and maintaining a list of open access publishers. More details on this proposed solution are summarised below:

  • My Library
    • A new tab would be added to My Library for open access content

Screenshot 2023-01-12 at 14.50.43.png (634×2 px, 230 KB)

    • Users browsing to this tab would find a curated list of reliable, free, content
    • A link on this page would take users to a Meta wiki page where the community can discuss and process requests for addition on the page
  • Open access coordinators
    • To reduce the workload burden on TWL staff, and put the community in control, a group of editors would be given the 'open access coordinator' role in the library
    • These users would have the technical capability to add, update, and remove collections from the open access list
    • They would also be the coordinators of the on-wiki process
  • Other changes
    • To facilitate this feature set, there are some other things to be considerate of.
    • We may need to implement T289254 if the list of open access collections is expected to be substantially longer than the other tabs, which only have 50-100 items.
    • 'Open access collections' would likely need to be a separate model from Partners, as they need far fewer pieces of information to be listed, and descriptions would likely not be desirable, due to the additional translation burden.
    • We may want to add additional tags (e.g. Size) if open access collections have no user-facing descriptions.

Open questions

  • Currently, users who do not meet the library's access requirements cannot browse the library at all. Would we change that if we add a list of free content?
  • Is there sufficient interest from the community that we could find folks interested in being coordinators?
  • What should the on-wiki process look like? What would the criteria be for listing a collection?

Event Timeline

Samwalton9-WMF updated the task description. (Show Details)
Samwalton9-WMF updated the task description. (Show Details)
Samwalton9-WMF updated the task description. (Show Details)

TWL holds editor data and doesn't have a very featureful RBAC model in place, so I'd rather not hand out logins for managing resources that don't need any kind of access control. I'd look for a way to decouple this from our current app and processes. A few ideas:

What if we had static pages (in app or on wiki?) for open access resources for each tag and just linked to it? Or if it's important to have oa resource cards alongside paid resources, what if we just used json files to store that data? Or what if we spun up another app to manage the resource list?

TWL holds editor data and doesn't have a very featureful RBAC model in place, so I'd rather not hand out logins for managing resources that don't need any kind of access control. I'd look for a way to decouple this from our current app and processes.

How different would this be from our system of having some users who are coordinators and can manage applications?

What if we had static pages (in app or on wiki?) for open access resources for each tag and just linked to it? Or if it's important to have oa resource cards alongside paid resources, what if we just used json files to store that data? Or what if we spun up another app to manage the resource list?

Interesting ideas! I think the main benefit of having this in the library itself is that we could presumably leverage the cross-section of filtering by both languages and topics which already exists in My Library. If there are going to be a large number of OA resources listed this would be extremely helpful as compared to a static list (even if that list was already paginated by e.g. tag).

Storing in JSON is an interesting lightweight idea in terms of implementation, but adding technical steps might be a barrier to some folks who would be interested in coordinating. Would another app for the resource list really be an easier option than adding functionality to the library? I'm not doubting it, but 'make a new thing' seems like it would be more complicated.

The above was based on a thought that OA coordinators would use /admin, but we could give them a new form. They wouldn't access PII or need to sign NDAs.