| Reference | Downloads | Github

How to cite PsychoPy code

I think it would be a good idea to standardise how to reference PsychoPy experiments and code.

For example, the reference for my credit card Screen Scale code from last May could be:

Morys-Carter, W. L. (2020). ScreenScale (Commit 12) [PsychoPy; PsychoJS].

using the template LastName, F. N. (date). SoftwareTitle (Version) [ProgLanguage; System]. URL

There are a few issues with this.

I’d prefer to give the version of the code in brackets rather than commit number or the version of PsychoJS. However, this needs to work without intervention from the author and releases can only be created via the “Release API” which means that route isn’t simple.

@sal suggested that I could create a DOI using Zenodo. However, this only seems to work for Github, not Gitlab. To use Zenodo or OSF would therefore require the author to upload a version there rather than use Pavlovia as the location for their code.

The URL could be to Gitlab Wakefield Morys-Carter / ScreenScale · GitLab but I feel that the dashboard page is the most convenient hub.

Thoughts @jon @thomas_pronk @Becca ?


My first intuition here was to cite in a similar way to how an OSF project would be cited? (which I think is in the form of an electronic source) which could be flexible to allow citing in different format depending on the journal the user is submitting to?


Morys-Carter, W. L (2021, July 28). ScreenScale. Retrieved from


Morys-Carter, Wakefield. L. “ScreenScale” Pavlovia, 28 July 2020. Web.


Morys-Carter, Wakefield. L. 2021. “ScreenScale” Pavlovia. July 28.

Actually I wonder if this would be simple enough to autopopulate the README file with when the project is created…

To add to this: the template he’s currently using (LastName, F. N. (date). SoftwareTitle (Version) [Language; System]. URL/DOI) is an APA citation for software. You don’t have to include the version if there isn’t really one like with journal editions and such.

I also found this thread that says you can manually update a completed version of the code to get a DOI, but then “supplement your record metadata on Zenodo with a “related identifier” (e.g. a URL) and point back to the tag on your live repository” so that people can be directed to the live code if they search for it via DOI. I haven’t tried this though, so I’m not exactly sure how that works. I think the DOI is good just so the credit you receive is better documented (URLs might change or break, but DOIs are forever), but that’s really just for your records if that matters to you.

1 Like

I would never say you need to use OSF instead but there’s no harm in uploading it there as well. I’d like us to integrate with OSF to make this a bit easier so that, exactly as @sal suggests, you could use OSF to mint a DOI with a fixed version but from there get back easily to the live code which is better to be in Git in my opinion

1 Like

Okay, so I’ve just had a go at using OSF

The auto citation is Morys-Carter, W. L. (2021, August 3). ScreenScale.

I don’t seem to have the possibility of changing the date so I guess it’s minted at the time it’s created.

I went for the GNU General Public License (GPL) 3.0


1 Like

It’s a shame that OSF doesn’t automatically put the category (in this case Software) in square brackets.

Yes, I think the date is always going to be the date it was minted - if it allowed you to back-date the creation date you might use that feature to cheat! They don’t know this is you, and how reputable you are! :smiley:

1 Like

This seems a suitable place to save a link to a journal I just came across.

Here’s my proposal for APA format:

Author, Initials (Date of substantial commit used). Title [Computer software]. Pavlovia. URL.

This is based on the information from Reference List: Electronic Sources // Purdue Writing Lab.

I think the best URL is to the Pavlovia page (since it is easy to get to Gitlab from there) or an OSF/ Zenodo DOI.

e.g. Morys-Carter, W. L. (2021, May 18). ScreenScale [Computer software]. Pavlovia.