# Feature requests in PKP projects

Caveat: I have been a fan of PKP for quite awhile but am still new to the inner workings, so there are big gaps in my assembling of past discussions and activities! This is just to get us going...

## NEW - Possible Discussion questions for Members' Committee Meeting

- Where do we get feature requests? Was the survey useful?
- Have you ever requested a feature? How did it go?
- How do we communicate about feature requests and their implementation? Are there ways we could improve?
- What is a feature request? Do you see evidence of common understanding, or confusion? What value do people place on being able to make feature requests?
- How do we give squeaky wheels the right amount of attention? (They are important! but there are also quiet people who may not share their ideas, or quiet people who leave and go to other platforms -- we want to understand these people too)

## Relevant Existing PKP Documentation/Notes:
- https://forum.pkp.sfu.ca/t/how-to-propose-and-discuss-feature-requests/74213
- https://forum.pkp.sfu.ca/t/about-the-feature-requests-category/17
- https://docs.pkp.sfu.ca/dev/contributors/
- https://docs.pkp.sfu.ca/help-guide/en/
- https://pkp.sfu.ca/wp-content/uploads/2019/06/PKP-Technical-Committee-OJS-Priorities-Survey-Report.pdf
- Community > Get Involved tab on main web page (https://pkp.sfu.ca/community/get-involved/)

## Some preliminary thoughts/guiding questions/context for this conversation:
- How are we currently doing with managing feature requests?
- What are all the sources of feature requests? (Forum, GitHub, conversations, conferences…?)
- What value do members place on being able to make feature requests?
- The energy that people bring when they get excited about new possibilities and how the software can serve their needs is really important – but sometimes their requests are not realistic or can’t be implemented quickly. Are there strategies to engage/temper expectations without shutting them down? Are there ways to redirect that energy? Who is responsible for that engagement?
- Are there best practices we’re not currently using/is there a benefit to gathering some information from other projects or the scholarly literature on software feature requests?
- Are we doing a good job of communicating when a new feature has been added as a result of community desires?
- Are there strategic things to think about in terms of peoples’ understanding of what it means to use a free software project – e.g. if they think customization is a key reason to choose it, how can we direct that to contributing to the upstream project rather than local changes that will break on update? ie, Communicating PKP’s place in a bigger scholcomm movement that they are part of

## Projects/things that may be helpful for us to work on:
- Reviewing previous feature requests on PKP Forum – are the right features getting prioritized? Do people feel heard, even when/if their features are not implemented?
o Plan for a twice-annual (?) group to review all feature requests/communicate/retire old ones (suggestion to do a sprint in some old TC minutes, maybe it is a regular thing?)
- People paying for features, or sponsoring implementation…? (Thinking about 4Science and DSpace, not sure if there are similar things in PKP) – need to balance overall strategy with people wanting their own problems solved but worth at least discussing
- Reviewing our current communication around feature requests – are our current messages still in line with what we want people to understand? Maybe we need more language about the bigger picture of PKP’s role in the scholcomm ecosystem?
- Is there additional communication we could be doing, e.g. reporting on new features that were implemented because of community requests specifically?
- How useful was this survey? Would we want to do another one? https://pkp.sfu.ca/wp-content/uploads/2019/06/PKP-Technical-Committee-OJS-Priorities-Survey-Report.pdf

## Some things that come up in past Tech Committee minutes:
(https://github.com/search?q=repo%3Apkp%2Ftechnical-committee+path%3A%2F%5Emeeting-minutes%5C%2F%2F+feature+requests&type=code&p=1)
- Need for transparency
- Area for features that PKP can’t write but that could be done with grant funding
- How do feature requests get retired?
- Feature request and contributor guide updates
- Survey collecting and categoring feature requests from multiple sources (2020)
- Some big picture themes from 2023: Communication: bounced emails, notifications; Submission lists and tracking; business intelligence; Typesetting / XML; Data migration and import/export; Compliance and standards integration (security, CRediT; Don't forget community survey from several years back, and support forum priorities...
- Capturing features from the forum, GitHub, and elsewhere is a huge task – sorting, prioritizing, etc. – how to handle that better (2021)
- Some responsibility on person requesting the feature to format it well (2024)
- Proposed sprint group to review feature requests (2024)
- Need better help with how features are described, voted on, etc.
- Managing relationship between Forum feature requests (more functionality) and GitHub issues and discussions (more tech heavy) (2022)
- Keeping published documentation around milestones/roadmap up to date is important for communicating with people about requests and bringing on new contributors quickly (2013)
- Need to prioritize ‘common benefit’ over solutions to individual issues (2022)
- https://github.com/pkp/technical-committee/blob/522f3b6d83880042ae2230f70de8185b11b6f726/meeting-minutes/2022-08-18.md?plain=1#L59: Space for feature requests needs to be taken as a ‘serious act of participation’ – deliver good description, etc.; Explain FR process: When are FRs selected to be included in development? Who decides? What is the criteria? How many will be implemented?

## Some relevant literature/communities/conferences that may be helpful:
There is a lot of literature out there in terms of software development and feature requests; of particular interest here is those in free and open source software communities because we have a different relationship with our user communities
- Science of Community track @ FOSSY: https://2025.fossy.us/pages/tracks/ and wrap up blog posts https://blog.communitydata.science/
- And Community Data Science collective: https://wiki.communitydata.science/Main_Page

(Quick Google Scholar search, some of these may be nonsense, will take a closer look later😊!)
A. S. Nyamawe, H. Liu, N. Niu, Q. Umer and Z. Niu, "Automated Recommendation of Software Refactorings Based on Feature Requests," 2019 IEEE 27th International Requirements Engineering Conference (RE), Jeju, Korea (South), 2019, pp. 187-198, doi: 10.1109/RE.2019.00029.
Nyamawe, A.S., Liu, H., Niu, N. et al. Feature requests-based recommendation of software refactorings. Empir Software Eng 25, 4315–4347 (2020). https://doi.org/10.1007/s10664-020-09871-2

Heppler, L., Eckert, R., Stuermer, M. (2016). Who Cares About My Feature Request?. In: Crowston, K., Hammouda, I., Lundell, B., Robles, G., Gamalielsson, J., Lindman, J. (eds) Open Source Systems: Integrating Communities. OSS 2016. IFIP Advances in Information and Communication Technology, vol 472. Springer, Cham. https://doi-org.cyber.usask.ca/10.1007/978-3-319-39225-7_7

L. Shi, C. Chen, Q. Wang and B. Boehm, "Is It a New Feature or Simply “Don't Know Yet”?: On Automated Redundant OSS Feature Requests Identification," 2016 IEEE 24th International Requirements Engineering Conference (RE), Beijing, China, 2016, pp. 377-382, doi: 10.1109/RE.2016.65.

Heck, P., Zaidman, A. A framework for quality assessment of just-in-time requirements: the case of open source feature requests. Requirements Eng 22, 453–473 (2017). https://doi.org/10.1007/s00766-016-0247-5

F. Ahmed, P. Campbell, A. Jaffar and L. F. Capretz, "Managing support requests in open source software project: The role of online forums," 2009 2nd IEEE International Conference on Computer Science and Information Technology, Beijing, China, 2009, pp. 590-594, doi: 10.1109/ICCSIT.2009.5234491.
https://www.igi-global.com/article/separating-the-wheat-from-the-chaff/148150

@misc{kc2025betterrequirementscrowddeveloper,
title={Towards Better Requirements from the Crowd: Developer Engagement with Feature Requests in Open Source Software},
author={Pragyan KC and Rambod Ghandiparsi and Thomas Herron and John Heaps and Mitra Bokaei Hosseini},
year={2025},
eprint={2507.13553},
archivePrefix={arXiv},
primaryClass={cs.SE},
url={https://arxiv.org/abs/2507.13553},
}