Where we discuss & make the Open Access Button
Latest commit d3b48cc Feb 17, 2017 @JosephMcArthur JosephMcArthur committed on GitHub Update README.md


Open Access Button


Hi, welcome to Github. Github is where the Open Access Button keeps all it's code, discusses huge amounts of our work & more. It's all openly availiable, and we do it here because we want your help.

About the project

The Open Access Button is an app that helps researchers, patients, students and the public get legal access to research they need and request research be made available. Since November 2013, we have made 15,000 requests for research articles and data.

Getting Started

If you want to help us build the tools, here are some helpful bits of information! We'll start putting more here soon as it's harder than it should be to dive in and help right now! Let us know what you'd like to see.

 Quick Guide

Ways to contribute

or if you're not interesting in the technical side of things we'd love your help talking to users (potential, new & old) and scheming for how to making things better.

Open Access Button Repositories

We have a few different repos here:

Getting in touch

We have decided not to use a general mailing list (because who needs another list?), and have decided to work through issues here on Github. General queries and issues are best dealt with in the backend repo. We use Zenhub for some extra layers of co-ordination that Github isn't so good at yet.

Labels, Milestones, Assignments & other notes on how we use issues

Important: Before a change is tested on the development site, an issue can't be considered completed. This counts even for simple copy changes.

What do the various labels/assignments mean for the project?

  • Bug: something that isn't working as expected
  • Enhancement: a way to improve something, usually a new requirement
  • Question / Discussion: a question or topic of discussion. Doesn't denote we should actually do something, just think about it.
  • help wanted: we'd love help here! (coming soon: good first bugs)
  • Plugin / Bookmarklet / Website / Emails / Admin: the place the issue relates too
  • Priority: more important than other things in a catagory
  • Blocked x : We need x in order the close the issue. These labels are added when an issue is created as part of estimating how much work will be needed to close it (and how to close it). They are not removed.
  • Jisc: This label shows work supported by Jisc (thanks Jisc!).

Assignmenting to a milestone is confirmation we're planning to do something. Otherwise, we're not currently planning to do much with it and the issue is just there for safe keeping incase one day we do.

Assignmenting to a person means it is currently possible for that person to work on that issue & signifies who is currently needed to move an issue forwards. An issue can be assigned to multiple people at once. If you're assigned an issue, but don't know what you should be doing (or can't do it for some reason) just say.

@comment someone if you need them to see a message.


Who are the people you see commonly in this repo at the moment?

  • Joe: Co-founder of the project
  • Mark: Lead dev from Cottage Labs
  • Chealsye: Our communications lead who discusses bits and pieces
  • Megan: Does a lot of testing for the Button
  • a variety of other contributors who pop in and out

we're all super friendly, say hello! The people involved in the project more broadly can be found here: https://openaccessbutton.org/about#team

How we handle bugs

  • Bugs are considered maintainance, rather than development. They are handled on a bug - by - bug basis independantly of sprints.
  • When a bug is filed on Github we will triage it to understand it's severity, and complexity.
  • A bug fix can be intergrated into a current sprint if desired - if needed we can move issues out of the sprint in this case.


We have lots of different names and concepts in the tools now, and it can be hard to know what on earth people are talking about. Below is a work in progress glossary.

  • Sign up: Someone for whom we have an email
  • User: Someone with the app installed
  • Advocate: Someone who as taken action to directly engage an author, or share the tool.
  • External User: Someone making a block or request via external service (not via request page or apps) e.g PeerLibrary or Sparrow
  • People: Catch all for all user types
  • Resource: A paper, dataset, program or other material associated with a paper (e.g plasmid)
  • Block Story: User or advocate generated message associated with a story
  • Block: Any instance an individual can’t access a resource they want. A paper can have multiple blocks associated with it, e.g one block for the paper and one for the data.
  • Found: A resource delivered automatically via a repository or search engine (i.e available and discoverable)
  • Block Meta-Data: Paper URL, paper metadata, User type, User location associated with a block
  • Inactive Block Rate: A block whose resource wasn’t found, and with no associated request
  • Request: An active request from a user for us to find access to a resource, usually via an author
  • Support: Taking an action to ... ???
  • Success: Delivery of a resource to a user or advocate (or acceptable reason why resource can’t be delivered) that couldn’t be found via automated means
  • Active *: Interacting with or logging a block in the past month
  • Former *: Not interacting with or logging a blog in the past 4 months


All users and email functionality can be found here if you have admin access: https://openaccessbutton.org/admin/

Testing Sites & Processes

To aid with testing, we have accounts at:

  • Peak & Usertesting
  • (for multibrowser / device testing)


We <3 Open Source. All of our code is licenced under an MIT licence and all site content is licenced CC-BY. Moreover, we try to be an open project general with much of our discussion & plans availiable to all.