Implementing optional means for authors to self-identify

Hello,

We recently had a request from one of the journals we host, if we could implement optional means for journal contributors’ self-identification. With equity, diversity and inclusion in mind, the journal would like to track who gets published on the basis of subfield, seniority, type of institution, race, and gender, analyze, disaggregate the data, and prepare a public report. We now have some internal discussions regarding privacy, data security, and data management.
I am not aware of any such feature in OJS at the moment. I would like to know if similar discussions came up at other institutions or between the OJS developers and if there are any plans to include such features in future versions of OJS.

Thank you,
G

Hi @gabriela,

Thank you for your comments. Including those data on users is not something that the user profile in OJS currently includes, nor do I think that there are plans for including such data as part of the user profile in the future. Including such fields would likely require modifying the software code, modifying the underlying underlying structure, as well as other dependent features that utilize the user profile - not a small feat, and it would require signficant resources - something that, as a small team, we don’t have.

One thing that might be possible though, is if you were to export users and then augment your list with the information you’ve mentioned in a separate data source - such as a spreadsheet or other data source. I’m not sure what specific version of OJS you are using (if you could please indicate that in your posts, that would be appreciated). OJS 3.3 now has the capability of exporting users to CSV - (Under Statistics > Users). You might be able to say, survey authors using exported data, and then update a separate data source with the fields for which you are seeking information. That way there wouldn’t need to be any modification of the software and you could still collect the information you need.

Discussion of modification to our software, typically takes place on our Github issues. For example, Remove gender fields · Issue #3387 · pkp/pkp-lib · GitHub. We also do blog posts about our efforts to enhance inclusivity and accessibility within our software, such as this recent one: https://pkp.sfu.ca/2021/02/19/improving-usability-inclusivity-and-accessibility-in-3-3/. It’s possible that there are other discussions. around Diversity, Equity, and Inclusion related to PKP software that are ongoing (we have an internal working group on DEI). I have tagged @asmecher here who may be able to speak further to these efforts, as well as your specific use case.

-Roger
PKP Team

Hi @gabriela,

Sorry for the delay in responding!

Are you thinking about a mechanism for contributors to interact with the published article and indicate that they were involved, in ways that the normal submission/editorial/publishing process wouldn’t capture?

Regards,
Alec Smecher
Public Knowledge Project Team