This section of our forum is where our community comes together to propose, discuss and refine feature requests for our scholarly publishing software. Make proposals here for changes that you’d like to see in Open Journal Systems (OJS), Open Monograph Press (OMP) and Open Preprint Server (OPS).
Everyone who uses our software is welcome to make a proposal or comment on other proposals, as long as they follow our community’s code of conduct. Before you post a new topic, please search the category to see if someone has suggested it before.
PKP staff regularly read topics in the featured requests forum. However, we can’t keep up with every proposal. We rely on our community to discuss the proposals together and vote for the most important topics.
PKP reviews the most highly voted topics and takes these signals into account when identifying community priorities. When a feature request has reached maturity, it may be converted into an issue on GitHub where work can be scheduled and tracked.
A proposal will reach maturity when it meets the following conditions:
- It is popular.
- It has reached agreement about how it should work.
- The benefits for the whole community outweigh the consequences.
- PKP approves it and believes it should be in OJS/OMP/OPS.
- It has a clear, comprehensive description of the proposed changes with everything the dev team needs to begin work.
You can help a proposal reach maturity by voting for the topic, posting a comment with more details about your requirements, or refining the original proposal by clarifying the description or outlining the known requirements.
When an issue is created in GitHub, it doesn’t mean that we’ll start working on the feature right away. But a proposal must reach maturity before our development team can begin considering it.
Most proposals will not have reached maturity yet and it may be hard to determine what’s needed to encourage a proposal’s development. We may assign one of the following tags to help identify where a proposal is in its lifecycle.
This tag will be applied to proposals that need more discussion from the community. This often means that we need to understand the use cases in more detail or that we need to hear about use cases from a wider diversity of users in our community.
This tag will be applied to proposals when we don’t yet agree how the proposal should work or whether we should implement it.
This tag will be applied to proposals when they reach maturity. They may have a GitHub issue associated with it, in which case you can track the issue to see if it has been scheduled for implementation.
This tag will be applied to proposals that have been implemented. You should see information in the topic about what versions of the software are expected to support it.
The best way to bring attention to your feature request is to write a clear, compelling proposal that follows the topic template. Make sure that you’ve included the following:
- Why do we need this feature?
- Who will benefit from this feature? (examples: journals, presses or preprint servers? editors, authors or reviewers?)
- Who might be impacted by this feature? (examples: a proposal about peer review might impact closed and open review formats)
- Does this proposal benefit the whole community or just one segment of it?
You can also improve other similar proposals or suggest that they be closed in favor of your proposal. However, please be considerate when doing so. Your proposal should include more information, be better organized, and attract more community engagement before another proposal will be closed in favor of yours.
If the other proposal includes more information, consider improving that proposal instead of creating a new one.
The best way to discover proposals is to search the feature requests category. When viewing the Feature Requests category, click the icon at the top of the forum and click the option to search “in Feature Requests”.