oops!

OOPs (Operese Omprovement Proposals¹ ) are the mechanism by which new Operese features and enhancements are proposed, discussed, and tracked before implementation begins. No substantive new functionality will be accepted until consensus has been reached on an OOP.

OOPs are similar to Godot's GIPs or Python's PEPs.

Finally, all interactions in this repository are governed by our Code of Conduct. Please remember the human, and that Codeberg is not a social media platform.

Opening a proposal

To submit an OOP, open an issue on this repository and fill out the template, after checking that no one has already submitted the same proposal.

Do not make a pull request to this repository unless you want to make a change to the template or README files.

Proposal lifecycle

After a proposal is submitted, most discussion will happen in the comments on its issue. Public Zulip discussion is also fine, but if it influences any decisions made on the proposal, the relevant thread(s) must be linked to in a comment.

If a proposal is well-received by the community and meets the criteria below, we welcome implementations! Upon deciding to take one on, please leave a comment claiming it and linking to your fork, so as to avoid duplication of work.

Proposal evaluation criteria

• Migration-focused
  • Operese is a Windows-to-Linux migration tool, and nothing more. Proposals dealing with desktop Linux as a whole are outside of its scope.
  • Example: A proposal to migrate screen reader settings would be considered migration-focused, while a proposal to ship a custom accessibility dashboard would not be.
• Impactful
  • The proposal should bring a meaningful improvement for potential users, or at worst not affect them.
  • A proposal with a small impact on a large group will be evaluated similarly to one with a large impact on a small group. Both will be prioritized over proposals only relevant to a tiny (<5%) group.
  • Example: A proposal to install Realtek helper packages would be considered impactful, while a proposal to migrate 0 A.D to its native Linux version would not be.
• Complexity/Effort
  • The proposal should not require sweeping changes to the existing application or extensive effort on the part of the implementer without a strong indication that the value delivered will be proportionate.
  • Example: A proposal to change the default line spacing in the log display would be considered straightforward, while a proposal to rewrite certain dependencies in Zig would be considered more trouble than it's worth.