Samillion
commented
2 days ago As a ModernZ user, I often make changes but hesitate to submit a PR because I'm unsure if they align with the project goal. A clear project vision would be nice for contributors to know what to focus on.
Answering you specifically, never hesitate. I've already seen your work and have a glimpse of what you think is practical. Worst case scenario is that your PR will be a discussion, but your ideas and implementations have been solid.
To answer generally for all contributors, the goal is to establish a stable OSC alternative to stock with a modern look. Practical use is the key vision. Niche features or additions like https://github.com/Samillion/ModernZ/issues/84 can be considered, but they're definitely not the main priority.
At least while the project is still fixing very old bugs from previous forks or origin.
Main project goals:
- Revive and maintain the Modern OSC, as it is either abandoned or partially maintained by adding new code without fixing the old.
- Apply common features that are missing and most users would want (ie: customization, button functions, lists and so on)
ModernZ is trying to be in a middle area between stock OSC and a project like uosc. One is too simple, the other is too complicated.
One of the first things that happened in ModernZ was to re-base on stock osc and integrate features that mpv already has, which eliminated a ton of bloat from the code. (example: https://github.com/Samillion/ModernZ/commit/cbce79c9cf378e19dc1417304e2d6fc0bc69f282)
In essence, we want to be better than stock OSC, but we don't want to do everything. That is why for example I loved that you integrated locale as extras, and the same thing was done for the pause indicator. If it's useful, but not necessary to the OSC, it should be in extras or an independent script. Modular methodology.
Commit message guidelines: Adopting a format like Conventional Commits to make it easier to understand the history and purpose of changes.
I absolutely agree. I was hectic in the beginning, but recently I've been applying the same commit format as mpv.
Branching strategy: Clearly defining how feature and fix branches should be named and managed can simplify collaboration.
I honestly haven't thought of this much, what I've been doing is: if it's for testing, any random (yet relevant naming scheme) to branch would suffice, if it's a branch point that I know might be merged, I implement a clear naming related to the commit message with the prefix dev_.
Which I guess we can utilize as commit conventions, ie: dev_, fix_, feat_
I came across release drafter and think it could be handy for automating release notes based on commits. It’d keep users updated with clean changelogs.
That is wonderful, and I agree, it would make things a lot smoother and seamless. Not just for users, but for maintainers and contributors as well.
Thank you so much for your detailed input. If you have any ideas of something that you'd think should be implemented, please share it and never hesitate.
Xurdejl
ThousandDemonDaggers
Hi,
I've thought of a few ideas that I think could help improve the project. Since this is a rewrite, I think it's a good opportunity to establish a solid structure that could serve as a foundation for future forks or contributors.
Establishing a clear vision
As a ModernZ user, I often make changes but hesitate to submit a PR because I'm unsure if they align with the project goal. A clear project vision would be nice for contributors to know what to focus on.
Implement conventions
Commit message guidelines: Adopting a format like Conventional Commits to make it easier to understand the history and purpose of changes.
Branching strategy: Clearly defining how feature and fix branches should be named and managed can simplify collaboration.
release drafter
I came across release drafter and think it could be handy for automating release notes based on commits. It’d keep users updated with clean changelogs.
Let me know what you think about these ideas.