Discussion on the future of Phobos

[Metadorius]

I think the time is due for me as a head of this project to discuss something important for all of us. Even if I don't directly contribute or review code at the moment, it is still important to talk about this.

Key problems:

• We have an influx of contributors with contributions of varying quality, but not enough mature developers to review the contributions and decide whether they are up to our standards, help contributors learn and grow;
• There's not enough motivation for developers to keep improving and maintaining Phobos as a project (this is mostly because we are not sustainable and can't be, we can't pay salaries because we can't earn money, hence people only work as long as it's interesting enough to do so);
• We have no development direction apart from "improve the game" - so far we are randomly fixing and implementing stuff without defined plans (and scope).

The result? You see it:

Many of those are in the "fridge" for multiple years already. On top of that, almost all of our maintainers are mostly gone, and the development stalls further and further. For me personally it's sad to see, because:

• Phobos is my first (and so far the only) serious project that I achieved something with, and I don't want to see it go (even if I personally can't actively handle it atm)
• Phobos was intended to be the community project to which people will be able to contribute to, and so far this doesn't seem to be fulfilled with the contributions being left in fridge.

All of the listed problems are not something you can easily solve, and I personally don't have an answer to how to solve them at the moment, therefore, I invite any and all contributors and whoever has something to say on the topic to discuss this.

@Starkku @chaserli @MortonPL @ZivDero @FS-21 @tomsons26 @CCHyper @CrimRecya @TaranDahl @NetsuNegi @Multfinite @handama @DeathFishAtEase @Aephiex @Rampastring @Otamaa @secsome and whoever else

[DeathFishAtEase]

In fact, due to the lengthy cycle of PR merges for this project, many contributors eventually maintain their own branches and continue to develop them independently, which results in an extremely difficult merging process.
And both the project itself and the branches maintained by contributors have ultimately ended up being tailored to serve specific projects or a few projects. For instance, many features in the current version of this project are essentially functionalities that Starkku developed for his own projects and then generously shared.
That is to say, there is an issue where 'Many users come forward with demands that others completely will not need' and submit these demands to this project, but these highly customized demands can be entirely handed over to engines like DynamicPatcher, rather than Ares and Phobos.
However, it's clear that this project cannot be completely redone, and even engines that offer functional components for users to assemble, like the KratosPP project, already exist.

Moreover, for the current Phobos, those PRs still need to be addressed, which requires some method for prioritization and thus necessitates a 'vote' from users, even in the form of reacting with emojis (just an example, which is obviously not conducive to statistics). Addressing a portion of the PRs does allow the project to move forward, but of course, this does not fundamentally solve the problem.

For PR:
We need 'an idiot-proof, end-user facing merge tool,' but I believe creating such a tool is equally challenging.
From my communication below, I extract my own conception of it:

an idiot-proof, end-user facing merge tool to generate the dlls needed by users from the source code, where users can freely select the features they want in the tool (for this project, it can be extended to those PRs). If a feature/PR causes problems, users can directly trace back to the feature developer/PR contributor or even the contributor of the conflicting PR, for coordination.

Or by changing the Syringe.exe or other methods to allow users to freely disable some hooks, just like @handama made this, of course, the risks are also borne by the users themselves.

In summary, it's about giving users the ability to choose the content they want and having them bear the cost of time and effort for merging, testing, and other related actions themselves.

---

通过一个傻瓜式的、面向最终用户的合并工具借由源代码生成用户所需要的dll，这个过程中用户可以在工具中自由选取它们所想要选择的功能（对于这个项目而言可以拓展到那些PR）如果哪个功能/PR导致了问题则可由用户直接追溯到功能开发者/这个PR的贡献者甚至冲突PR的贡献者，以此进行协调。

或者通过更改Syringe.exe等方式允许用户自由禁用一些hook，就像 @handama 制作的这个，当然风险也由用户自己承担。

总之是让用户拥有选择自己想要的的内容的能力，并由他们自己承担合并与测试以及其他相关行为的时间精力成本

[Metadorius]

Moreover, for the current Phobos, those PRs still need to be addressed, which requires some method for prioritization and thus necessitates a 'vote' from users, even in the form of reacting with emojis (just an example, which is obviously not conducive to statistics).

This is already there in discussions, one of the reason I moved all suggestions to discussions, but for some reason no one uses the upvotes:

[Metadorius]

That is to say, there is an issue where 'Many users come forward with demands that others may not necessarily need' and submit these demands to this project, but these highly customized demands can be entirely handed over to engines like DynamicPatcher, rather than Ares and Phobos.

This is one of the reasons why I am usually pushing users to build generalized features. We must provide building blocks so people build their own stuff, not very specific features.

[DeathFishAtEase]

That is to say, there is an issue where 'Many users come forward with demands that others may not necessarily need' and submit these demands to this project, but these highly customized demands can be entirely handed over to engines like DynamicPatcher, rather than Ares and Phobos.

This is one of the reasons why I am usually pushing users to build generalized features. We must provide building blocks so people build their own stuff, not very specific features.

But there are already projects like KratosPP that have taken the lead in this direction, and it is very difficult to design something that is different yet equally universal. Users who can carry out such functional design often have a knowledge of engine functionality that is no less than that of engine developers (although they are often the same group of people)
However, even the mechanism of providing modules for users is not widely accepted by many users. The vast majority of users clearly prefer a single function to directly meet their needs. Even when I talk to other users about the YR engine's use of multiple functions to achieve results, many people tend to hastily end with the phrase "the learning cost is too high, I don't have the energy, I don't want to learn". After all, highly customized logic is much more convenient for specific projects than splicing different logical modules. Of course, this is not easy to comment on for the development of a community public engine

[secsome]

The three key problems have revealed the most important problem already. I'd like to give some of my opinion about these points below.

Key problems

The code quality

We do have a coding-standard, but haven't enforce people do that yet. The code quality can usually be separated into several parts:

• Does it obey the code naming standard?
• Does the new code have side effect on the old codes?
• Does the new code have been implemented in the proper way?

The naming rule is the basic one. But sadly, in the latest develop, there are too many places do not follow the rules. So my first suggestion is to add a step in our PR workflow. But to do this, a complete check on the project is required, and we may need to make an agreement about the naming rule. Those would take at least a week to be done. This is our basic coding-style check, and it will force the PR meet all requirements.

Another big problem is sometimes the new code is potential inefficiency, as you can always implement this feature in a better way. The main problem for this is this is a community based project and we don't have some plans, or iterations which lead our goal. So the main contributors cannot tell the newcomers whether there's a better way to implement the feature before the newcomer make the PR, and as it's a community based project, many people work at the time they are free, when they just want to do that, and their motivation fades really quickly, then this PR would never be completed!

As I've mentioned above, Phobos is a community based project which has really few active main contributors now. Usually the main contributor would also charge in make sure the new PR have no side effect to the existing things. So testing people are needed, while we can hardly find any of them and we cannot test all cases currently.

Lack of motivation for being a maintainer

As @Metadorius mentioned at the beginning, we don't earn money from this project, and for most developers, at least for me, take contributing to the project as a hobby to do at my spare time. I contribute to this project because I want to give my power to the community, but this isn't my work, so I can only have really few time spend on this. (And after coding from 10 a.m to 6 p.m everyday, I don't want to more code when I get back to home honestly, I'd rather to something else). But an active maintainer is necessary for any project, whether it's driven by the community or not.

No clear objectives

This is something between the two points above, as we don't have an active maintainer, we cannot make plans to achieve, such as fix any vanilla bugs, implement any new features or resolve existing Phobos bugs. And it also made us hard to keep the code quality on a high level.

Solution?

My optinion is an/some active maintainers is necessary. Everything I said below requires a/many active maintainer(s).

I suggest we should make some plans, such as a release version every two months or some other intervals, and maintainers can arrange the things from the issues/existing pull requests at the beginning of this release cycle. And before the release cycle ends, we can give an experience pack to the modders, which is a time buffer for us to resolve the issues before the release version. And I suggest we to create branches for them with the naming like release/MAJOR.MINOR.BUILD.HOTFIX. So we can move to work on the next release cycle.

And if this is implemented, we can disallow people to push to branch develop directly. The hotfix should be pushed to the corresponding release/x.x.xx.x branch and develop only accepts the PRs. This would also help in management.

A true problem ahead is that as Phobos is growing HEAVIER and HEAVIER, modders begin to doubt if they really need this/that feature. I don't want to use someone's feature, but as it has been added into the latest version of Phobos I have to use it, even it will cause my FPS drops. So I have to stop upgrading Phobos, seeking for other self modified version, which is really bad for the consistent developing for Phobos itself. So by seperating all project into separate features, we can give the modder the ability to control which features should be enabled and which are not. We already have many feature have the switch, but the maintainer should take this reponsibility to decide which feature/bugfix need it.

In my opinion, an active maintainer is the key for Phobos to go further. And yeah I don't have any good ideas about that. But I think this is just where the key problem lies. Our discussion should focus on how to find an active maintainer and how to make the system work better with as least active mainainer I guess.

[Aephiex]

I. Help, unmerged PRs are stacking!

That sounds like the project is lack of active collaborators who have write access. And my suggestion is simple, just recruit some voluntary collaborators from active, responsible, and mindful contributors, and allow them merge whatever look good without too much discussion, and try to trust them to not show some destructive behavior.

About myself, I think I'm doing my best as who I am, or who I think I am. I make whatever I want, I intensively test my stuff, and sometimes help people doing something. That's the best someone without write access can do, because I can do nothing in advance. Eventually someone with write access will be needed, because a castle 99% built is a castle not built. I never asked, for whatever reason, such as stability regards, or simply not having the time to, it is always the collaborators' rights to decide how to spend their free time and whether to merge or even to look at the pull requests, and asking why you don't spend more of your free time on a non-commercial project doesn't sound like a polite thing to do. Can't blame people starting to maintain their own branch, even I do, and I will definitely use my play branch as a basis if someday I will ever create a mod for myself.

Don't forget, that RA2 is an old game that you can't expect many new comers, not to say new developers, and we who are still enthusiastic modding it (or used to be) are more likely to be more and more occupied by non-hobby activities such as career, marrage, children, or as simple as new fancy games like Black Myth Wukong. That's to say, maintaining a high standard can lead to a strictly limited human resource pool, among an already selective few group who can develop, among an already shrinking fanbase of a sunset title.

(If you really want to take my advice of recruiting new collaborators then don't come to me, I'm not a taker of long-term responsibility unless it's my job. Unless you don't mind me not doing everything you may have expected from a collaborator.)

II. Lego system?

Regarding KratosPP, in my narrow sights, the learning cost surpasses even c++ itself, and the resulting rulesmd.ini code are not straightforward and hard for another person to read how does it work out, that's not my prefered way to mod a game, and that's why I won't use it and would rather c++ instead. It might have a lower learning cost than c++ to some, but is still difficult to use, as it usually asks for ~20 lines of rulesmd.ini code to do something you can describe in one sentense with English.

I agree that the features should be generalized and as customizable as possible, but I don't really want to make a lego system, that would take years to design and to develop, and take weeks for a modder to learn how to use it, if I had that much free time I get more interesting things to do, such as playing new games, watching anime, and sampling decicious food, whatever it is, it is more fun than developing a lego system for a game like RA2, as in my sights, c++ itself is already a lego system, just you have to make your pieces from crude oil.

The closest thing in my todo list is the event handler system that user Metadorius (Kerbiter) mentioned in the issues panel. Can't believe whatever comes out from my hands will be something as lego-ish as KratosPP is, since I want to make it straightforward and keep the rulesmd.ini code readable.

III. Objectives?

Don't really think we need that. Some of our shinest creations, like unit tooltips and the super weapon sidebar, each may already present in a newer CNC game, and we are replicating these features on a game too old to have such on the launch. A modder can simply choose to mod on a newer CNC game and they start with many features that would take us months to develop and decades to merge, and even those they don't start with they can make a short work of it much faster than we can. That's said, we are still here because we like RA2 or want to stay here for whatever reason. Don't forget, that modding is for fun. Implementing features is fun on its own, but taking a long term objective is not for me.

Conclusion

Thank you for reading.

[Metadorius]

@secsome

About the code quality: so far I am yet to see the overlooked bad naming to cause some kind of a fault. Yes we do stray away from code style here and there, but I think it's one of the minor-est issues.

For stuff like that - there is clang-tidy and clang-format. They need to be intergrated into our workflows in CI and in the project. They are supported by all IDEs and they do provide automatic code style checks and linting. @chaserli was working on it but didn't finish it.

In my opinion, an active maintainer is the key for Phobos to go further.

The main problem: where should we find one?

1. The person needs to be well versed in software engineering.
2. The person needs to understand (ideally be interested in) Yuri's Revenge.
3. The person needs to be passionate to basically work on the project for free, especially tackle the usually not interesting stuff like reviewing and housekeeping.

This is basically trying to find a unicorn. Such a person is very rare.

[Metadorius]

@Aephiex

on Lego system: I don't think we need to go as far as Kratos goes, but there is still something to improve.

1. The event handler thingie in it's most basic form (I don't think the stuff with filters, multipliers, custom event invocation is needed for the first iteration).

2. Making every attachable thing (like shields, AE, possibly Laser Trails, Techno Attachments in future) all follow the same logic and managed by the same code. This will save us from reimplementing attach/detach stuff every time. Basically for the end user it will be almost the same INI code but more versatile and generic.

   This is also known as Entity-Component pattern (NOT Entity-Component-System! two entirely different things). Every modern engine uses this pattern to allow for generic behavior. It's the building blocks of type "Want movement? Add MovementComponent", not the "learn a cryptic language of fake weapons, units, superweapons".

[Aephiex]

@Aephiex

on Lego system: I don't think we need to go as far as Kratos goes, but there is still something to improve.

1. The event handler thingie in it's most basic form (I don't think the stuff with filters, multipliers, custom event invocation is needed for the first iteration).
2. Making every attachable thing (like shields, AE, possibly Laser Trails, Techno Attachments in future) all follow the same logic and managed by the same code. This will save us from reimplementing attach/detach stuff every time. Basically for the end user it will be almost the same INI code but more versatile and generic.
   This is also known as Entity-Component pattern (NOT Entity-Component-System! two entirely different things). Every modern engine uses this pattern to allow for generic behavior. It's the building blocks of type "Want movement? Add MovementComponent", not the "learn a cryptic language of fake weapons, units, superweapons".

That's ideal for software engineering and when making an indie game you have absolute control over the whole project. I know Unity engine work that way and I like it alot, it makes modding of Unity games easy to do. Don't forget we don't have control over the codes of Yuri's Revenge and Ares engine extension, it is not easy to do even as simple as to fix a bug with them, and it is the nature of c++ programs, that most of the info that will help you understand will be lost after it was compiled, and the program already present are completely not following the entity-component pattern. Making something like that on top of such complexity is even more consuming than it sounds like.

[Metadorius]

That's ideal for software engineering and when making an indie game you have absolute control over the whole project. I know Unity engine work that way and I like it alot, it makes modding of Unity games easy to do. Don't forget we don't have control over the codes of Yuri's Revenge and Ares engine extension, it is not easy to do even as simple as to fix a bug with them, and it is the nature of c++ programs, that most of the info that will help you understand will be lost after it was compiled, and the program already present are completely not following the entity-component pattern. Making something like that on top of such complexity is even more consuming than it sounds like.

Yeah absolutely. It should be an inspiration, not a direct copy.

Entity-Component pattern is mostly based on OOP principles, not C#-specific reflection and such, so I think the core idea can be implemented so it is convenient for both us and users.

[DeathFishAtEase]

Key problems

The code quality

We do have a coding-standard, but haven't enforce people do that yet. The code quality can usually be separated into several parts:

• Does it obey the code naming standard?
• Does the new code have side effect on the old codes?
• Does the new code have been implemented in the proper way?

Regarding the implementation of standards:
The implementation of this standard itself has some difficulties due to the original PR merge cycle issues, and there are many PRs that have not been merged for a long time. Obviously, it is not convenient for you to renovate the entire functionality on behalf of the PR submitters who may have lost contact during the standardization process, and there are also PRs with the same functionality submitted by different contributors.

Solution?

I suggest we should make some plans, such as a release version every two months or some other intervals

Regarding the release cycle:
The Phobos project's build version release interval is already close to the length you mentioned, but it seems to have little effect, and there are even cases where many users no longer follow updates due to issues like build34 forcibly enabling $Include. Also, can you describe your idea in more detail? Do you mean to release a new version and then have other contributors provide patches to complete the release version?

A true problem ahead is that as Phobos is growing HEAVIER and HEAVIER, modders begin to doubt if they really need this/that feature. I don't want to use someone's feature, but as it has been added into the latest version of Phobos I have to use it, even it will cause my FPS drops. So I have to stop upgrading Phobos, seeking for other self modified version, which is really bad for the consistent developing for Phobos itself. So by seperating all project into separate features, we can give the modder the ability to control which features should be enabled and which are not. We already have many feature have the switch, but the maintainer should take this reponsibility to decide which feature/bugfix need it.

Regarding whether users feel they need a certain feature:
In fact, I had once conceived an idea for such a tool many years ago: to use an idiot-proof, end-user facing merge tool to generate the dlls needed by users from the source code, where users can freely select the features they want in the tool (for this project, it can be extended to those PRs). If a feature/PR causes problems, users can directly trace back to the feature developer/PR contributor or even the contributor of the conflicting PR, for coordination. But I was already questioning at that time whether such a tool could be made, or how it could be accomplished. As you mentioned, regarding the current state of the code standards issue, end-users often lack the ability to handle merge conflicts. And as the source code updates, the tool itself also needs to be upgraded, and users often need to follow the version of the tool, which means it is not universal. And it is also difficult for the tool to be very intelligent and complex - complexity may not be convenient... There are many problems, obviously, such a thing is not easy to design and produce.

[DeathFishAtEase]

I. Help, unmerged PRs are stacking!

That sounds like the project is lack of active collaborators who have write access. And my suggestion is simple, just recruit some voluntary collaborators from active, responsible, and mindful contributors, and allow them merge whatever look good without too much discussion, and try to trust them to not show some destructive behavior.

About myself, I think I'm doing my best as who I am, or who I think I am. I make whatever I want, I intensively test my stuff, and sometimes help people doing something. That's the best someone without write access can do, because I can do nothing in advance. Eventually someone with write access will be needed, because a castle 99% built is a castle not built. I never asked, for whatever reason, such as stability regards, or simply not having the time to, it is always the collaborators' rights to decide how to spend their free time and whether to merge or even to look at the pull requests, and asking why you don't spend more of your free time on a non-commercial project doesn't sound like a polite thing to do. Can't blame people starting to maintain their own branch, even I do, and I will definitely use my play branch as a basis if someday I will ever create a mod for myself.

Don't forget, that RA2 is an old game that you can't expect many new comers, not to say new developers, and we who are still enthusiastic modding it (or used to be) are more likely to be more and more occupied by non-hobby activities such as career, marrage, children, or as simple as new fancy games like Black Myth Wukong. That's to say, maintaining a high standard can lead to a strictly limited human resource pool, among an already selective few group who can develop, among an already shrinking fanbase of a sunset title.

(If you really want to take my advice of recruiting new collaborators then don't come to me, I'm not a taker of long-term responsibility unless it's my job. Unless you don't mind me not doing everything you may have expected from a collaborator.)

However, we're doomed from the very first step because we don't have enough active participants, and accepting all features
would also lead to the FPS drop issue mentioned by secsome above.

III. Objectives?

Don't really think we need that. Some of our shinest creations, like unit tooltips and the super weapon sidebar, each may already present in a newer CNC game, and we are replicating these features on a game too old to have such on the launch. A modder can simply choose to mod on a newer CNC game and they start with many features that would take us months to develop and decades to merge, and even those they don't start with they can make a short work of it much faster than we can. That's said, we are still here because we like RA2 or want to stay here for whatever reason. Don't forget, that modding is for fun. Implementing features is fun on its own, but taking a long term objective is not for me.

But you're right! We gathered here originally just for the sake of having more fun, rather than for anything else, although it might seem somewhat irresponsible to say so, but that's the truth.

II. Lego system?

Regarding KratosPP, in my narrow sights, the learning cost surpasses even c++ itself, and the resulting rulesmd.ini code are not straightforward and hard for another person to read how does it work out, that's not my prefered way to mod a game, and that's why I won't use it and would rather c++ instead. It might have a lower learning cost than c++ to some, but is still difficult to use, as it usually asks for ~20 lines of rulesmd.ini code to do something you can describe in one sentense with English.

I agree that the features should be generalized and as customizable as possible, but I don't really want to make a lego system, that would take years to design and to develop, and take weeks for a modder to learn how to use it, if I had that much free time I get more interesting things to do, such as playing new games, watching anime, and sampling decicious food, whatever it is, it is more fun than developing a lego system for a game like RA2, as in my sights, c++ itself is already a lego system, just you have to make your pieces from crude oil.

The closest thing in my todo list is the event handler system that user Metadorius (Kerbiter) mentioned in the issues panel. Can't believe whatever comes out from my hands will be something as lego-ish as KratosPP is, since I want to make it straightforward and keep the rulesmd.ini code readable.

The issue you mentioned does exist; we're not aiming to teach users how to cast spells of forbidden magic. In fact, I've experienced some engines that have comprehensive logic links and are relatively easy to write. But forgive me for not being able to find another usable example in the public community. In short, what I'm trying to express is a shift in the direction of functional design. I'm glad you understand what I'm saying. :P

As for Lego, I'm more inclined to think it's a matter of how finely to split the functions. Personally, I believe the engine can split functions to the extreme. After all, simplifying the syntax doesn't need to be done by the engine; this can be entirely handed over to external tools to provide syntactic sugar, tool scripts, node-based visual editors, or even Excel.

[DeathFishAtEase]

1. The person needs to be well versed in software engineering.
2. The person needs to understand (ideally be interested in) Yuri's Revenge.
3. The person needs to be passionate to basically work on the project for free, especially tackle the usually not interesting stuff like reviewing and housekeeping.

This is basically trying to find a unicorn. Such a person is very rare.

And most importantly, he is willing to take over this project :P

[Metadorius]

there are even cases where many users no longer follow updates due to issues like build34 forcibly enabling $Include

Development builds were always reserving the right to be a testing ground. I don't think we ever advertised dev builds as something stable and robust, so I don't know where the expectations of those users come from.

We try to do our stuff reasonably, and we expect people staying with us to be also reasonable. It is not our job to cater to false expectations or persuade users who don't understand or even hate the project, so I don't think this is a problem.

[DeathFishAtEase]

so I don't know where the expectations of those users come from.

It is indeed the case that they are just test versions, but those test versions have indeed had a negative impact. Moreover, I've found that many users perhaps because the release version is far behind the development version or for other reasons also regard the Build versions as sufficiently 'official' and place high expectations on them, and it seems difficult to change this concept. xD

[Aephiex]

IV. Quality issues

If something confirmed to be working can somehow break for an update, how can I feel safe grab the latest update as someone who don't code? I have encountered 2 incidence where a certain Phobos feature or fix caused an unexpected side effect.

1. The AI parallel queue customization is described to allow the similar feature in Ares to take precedence when the latter is enabled, but it is a lie, it in fact renders the latter not working.
2. The "Building upgrades now consistently use building's PowerUpN animation settings..." is known to make the Foehn barracks (Mental Omega) not look right, it always look like it had the knightfall extension even if it in fact had the netrunner protocal extension. Commenting out relative codes fixed it.

Having an unforseen side effect in the code is something inevidable in software engineering, sometimes old stuff can break by stupid reasons, not to mention an interest driven project that not all of us are trained to be careful on such regards. I know it is hard to ask for people to take more responsibilities, but please at the very least make sure every line in your doc is confirmed, not supposed, and if something can have a side effect, give an option to turn it off. I'm following these in my pull requests.

Lower standards, quality issues. Higher standards, everyone gets a custom branch. It is really hard to find a balance, when we are absolutely lack in active people.

[Aephiex]

It is indeed the case that they are just test versions, but those test versions have indeed had a negative impact. Moreover, I've found that many users perhaps because the release version is far behind the development version or for other reasons also regard the Build versions as sufficiently 'official' and place high expectations on them, and it seems difficult to change this concept. xD

That's an issue caused by low level of activity and low frequency of stable release update. Despite such, even the latest dev build isn't new enough, that many useful features are still lying in the pull request panel, they aren't even becoming part of a dev build.

I SEE NIGHTLY BUILDS ON MOD RELEASES CAN YOU BELIEVE ME??? That even makes me want to say well done because they somehow got a nightly build of the feature they want, which isn't easy to do for someone not quite familiar with github and how this project build nightly builds for pull requests.

[Metadorius]

Note to myself: it appears that the current release schedule/versioning scheme is suboptimal and can be made simpler to follow, with more frequent releases and less burden on the maintainers (while also adding a possibility of better automation of stuff like changelog generation).

[Metadorius]

Few more contributors who I forgot to mention: @Fryone @ststl-s @Super-StarX @Belonit @Coronia

[Coronia]

Here're some personal takes, might not be correct:

ABOUT CODE QUALITY
I know that Phobos (and to an extent, many community project) suffers from coding standard issues, and if it's an other project with more popularity I would definitely support doing more standardization work. But that's not the case now cuz RA2 is an old game with decreasing popularity by itself, and modifying its engine already requires knowledges that many people don't know. We're already the 'selected few' who'd still like to working on it, and there's no salary and such to inspire people. The only 'award' is the sense of achievement: someone makes a function and sees it works, then it's been accepted by the public, so he has the motivation to contribute next time. I've seen some people don't really have much experience in coding before, but still trying their best to learn and make contribution, only because they love the game and still have interest and passion in modding.

But in this case, coding standardization might discourage such passion cuz again, it requires further ability for participants and reduces the chance of merging pull request naturally, which is also a reason that there're many PRs being left there: once they losing the passion to continue, or having real life business, they won't be bother to do further maintaineance on it. Or instead, they'll develop their own branch instead since it doesn't have that much rules to follow.

Again, I'm not against code quality by itself, but pushing it might result in ineffectiveness and de-motivation (considering people already don't have much motivation now). So a balance should be made, but so fat I don't have much idea on it either. The only thing I can think about as of now is: If a pull request just has some minor coding style problems, then maybe there's no need to ask the contributor to modify it by themselves. Maintainers could do it when merging instead as it's only a few minutes work, and they have the writing access.

ABOUT MAINTAINER
Here's an opinion due to my own working experience: The one who maintains the project and decides on the direction of development MIGHT NOT have to be a programmer. In an IT company there often be 3 types of characters: Developers, testers and product designers (or PD for short), and PDs are the one who really decides where the project should go. They don't need to do coding by itself or have any knowledge about coding, but they need to know what's really needed for this project, and have the ability to organize others to work on it.

For the case of Phobos: in before there're criticisms about it 'doesn't know what's a modder truly want', considering some of our functions are impractical in actual modding scenarios. And as of now we also don't have much goal but to make the game better, but again the definition of 'better' is varied by people. Considering this 2 things, maybe it's better that we inviting some real modders to help with the maintaineance. Phobos can't standalone with a YR mod after all, so let's say modders are the 'clients' of this project, and we as a 'provider' is to provide them with what they need. Again, they don't have to know about coding, but could just give instruction such as 'what functions are still needed' and 'which pull request should be merged first',then the other programer help with execution.

ABOUT REDUNDANT FUNCTIONS
TBH, I think this is due to the nature of Phobos being a community project. Again, RA2 engine extension is already a group with very small amount of participants, and it can't shine alone without an actual YR mod. Despite we're trying to make our functions as universal as we could, there're still many explict requirements from different mods that can't always be satisfied by a public build. But if we're adding too much of these custom functions and additions in the official build, it'll create extra performance tax and might even break existing stuffs unintendedly, which is bad for those who don't need these functions. As of now both those who don't get their desired functions and those who get interrupted by new additions might adbandon official build and make their own branches instead.

I think we should allow users to decide which functions they want to use, and cut out those they don't really need manually in order to prevent them from disruption their mods. 2 methods to achieve that:

Simpler approach: adding toggles for several functions, especially those that needs to be calculated per frame. For example:

[Phobos]
PassengerDeletion=false

If this is set, then everything about PassengerDeletion will be omitted, saving the cost of its calculation.

Harder approach: we make a branch with only basic framework, and split all functions into standalone pull requests. If someone only want to make use of a few functions in it, he can make a build with only those included. In this case, instead of a unified official build, people could assemble their own build in a more modular way. But it also has the disadvantage of requiring more work and knowledge in the field of coding.

[Fryone]

Small note. I'm far from being an expert, so I don't know what Phobos should be in total. But at least, it's good stuff to expand YR engine, so I don't see why it should be super-customizable, cause there is OpenRA for that. Of course, a lot of similar logic stuff should be united and generalized, but sometimes it's hard to find borders, cause everything seems to be connected in some sort.

About big PR number, there is a lot of small PRs with fixes or small stuff plus some PRs for ideas/discussions/demos, so it's not that bad.

[hejiajun107]

In my opinion, It's unnecessary to worry about tons of the pull-requests leave here.
Ensuring the stability of the current version is more important.
Since phobos is an open-source project ,anyone those who wants new features in pr can maintaining and relaese their own branch under the license.
On the other hand, that would be better if a plugin structure could be designed.The authors of the plugins may responsible for maintaining themselves, and users can choose which plugin they need.

[TaranDahl]

我认为可能的解决方案：I think possible solutions are:

We have an influx of contributors with contributions of varying quality, but not enough mature developers to review the contributions and decide whether they are up to our standards, help contributors learn and grow;

降低代码审核的标准。审核只需确保：
Lower the standards for code review. The review only needs to ensure:

1. 最基本的可读性。变量名、函数名不能是“aaa”之类的东西。大部分代码意义明确，不明确的部分要求贡献者补充注释。
   考虑到我们目前的人力资源，我不认为花时间在代码风格等细枝末节上是明智的行为。另外，不要忘了我们是一个基于gamemd逆向成果构建的项目——我们的开发者们都能看懂IDA输出的那些反编译代码了，区区代码风格真的会影响到他们吗？
   The most basic readability. Variable names and function names cannot be things like "aaa". Most of the code has clear meaning. For the unclear parts, contributors are required to add comments.
   Considering our current human resources, I don't think it is wise to spend time on minor details such as code style. Also, don't forget that we are a project built based on the reverse engineering results of gamemd - our developers can understand the decompiled code output by IDA. Will mere code style really affect them?
2. 除了bug修复类pr，在不开启任何pr功能的默认情况下，已有的东西（gamemd的、Ares的、Phobos已有的其它功能）应当以原有的方式运作。
   pr本身的功能能否运转，通常来说pr作者比审核者要更清楚，我们可以假设它们在大多数情况下工作良好。而且正如上面多次被提及的，很多提交的功能缺少通用性，这意味着当我们考虑接收一个新功能时，可能大部分使用者都不会用到这个功能。所以只要我们确保它不会影响已有的东西，那么我们就满足了大部分使用者的需求。
   Except for bug fix pull requests, by default without enabling any pull request functions, existing things (those of gamemd, Ares, and other existing functions of Phobos) should operate in the original way.
   Whether the function of the pull request itself can operate is usually clearer to the pull request author than the reviewer. We can assume that they work well in most cases. And as mentioned many times above, many submitted functions lack universality, which means that when we consider accepting a new function, probably most users will not use this function. So as long as we ensure that it does not affect existing things, then we meet the needs of most users.

There's not enough motivation for developers to keep improving and maintaining Phobos as a project (this is mostly because we are not sustainable and can't be, we can't pay salaries because we can't earn money, hence people only work as long as it's interesting enough to do so);

解决办法同上。如果你没法开源，那么你就得节流。把宝贵的人力资源省着用，用在那些对大多数人来说有意义的地方。
The solution is the same as above. If you can't increase the income, then you have to reduce the outcome. Save and use precious human resources sparingly and apply them to places that are meaningful to most people.

We have no development direction apart from "improve the game" - so far we are randomly fixing and implementing stuff without defined plans (and scope).

我不认为这是个需要解决的问题。尤里的复仇引擎就像一台型号老旧而且本来就粗制滥造的机器，把西木留下的这台破烂修好本来就是这个游戏最需要的开发方向之一。
I don't think this is even a problem that needs to be solved. The Yuri's Revenge engine is like an old and shoddily made machine. Fixing this junk left by Westwood is one of the most needed development directions for this game.

[DeathFishAtEase]

On the other hand, that would be better if a plugin structure could be designed.

This is why I said we need 'an idiot-proof, end-user facing merge tool,' but I believe creating such a tool is equally challenging.

The authors of the plugins may responsible for maintaining themselves, and users can choose which plugin they need.

But I think the feasibility of creating a similar tool for developers is relatively high, as you mentioned here.

[Otamaa]

I love experimenting with stuffs and iam glad phobos exist so we dont stuck on waiting AlexB publishing his ares source.
I often ignoring code style myself , and that the reason iam not really interested doing review on that field , so what iam doing most of the time probably pointing out some weird code usage that can lead onto unoptimized stuffs or bug.
I also hate writing documentation btw , thats why iam not publishing my own codes nowdays , which i have plenty of it on my own repo if anyone wanna play with it.

As for PR issues , yeah we need someone that can do review and have an handfull of time on their life to spend on those , since most people not have that time atm , or maybe lack of motivation.

Also please stop with those force push abuses, why not discuss it before get merged instead nuking people stuffs that already mereged , jeez .

[Metadorius]

Also please stop with those force push abuses, why not discuss it before get merged instead nuking people stuffs that already mereged , jeez .

I also think it is not correct to handle stuff like this and I am already talking with people about this. Apologies for this.

[Super-StarX]

Phobos is still a powerful drive for the community, continuing to push its development. However, due to the shortage of programmers and lack of financial support, several issues have arisen.
For developers, the main challenge lies in the lack of developers to maintain PRs and fix bugs. For users, the issues include bugs and a large number of "for self fun" features created by individual developers, leading to a very unstable experience.

I believe the future of the engine extension lies in plugin-based or custom toggle-based approaches:

1. Plugin-Based: Each feature or organization can develop a standalone DLL, and a mod can utilize multiple DLLs.

   • We have already made some preliminary attempts in this direction:
     LLF - text-style csf, introducing a solution called LLF Format Text. This simplifies the CSF file editing process, allowing the game to directly support LLF format files and eliminating the need for traditional CSF editors.
   • Based on this, the community would benefit from a plugin manager (similar to Minecraft’s mod manager or DP) to handle hook conflicts and other issues.

2. Custom Toggle-Based:

   • This would be a promising direction for Phobos. Ideally, users could customize the compilation process, such as providing a compilation script with a visual UI that allows users to select the features they want to compile.
   • Alternatively, we could precompile features and offer a feature manager similar to Ares’ INJ file functionality (still requiring a visual UI or user-friendly configuration file) to control which features the user needs.

---

Phobos 依然是目前社区的一个强大动力引擎，推动着社区的发展。然而，由于程序员数量不足且缺乏资金支持，导致了许多问题。
对于开发者来说，主要困难在于缺乏维护 PR 和修复 Bug 的人力；而对于用户而言，则面临大量无用的、开发者“写着玩”的功能，以及平台上的大量 Bug，导致整体体验非常不稳定。

我认为拓展引擎的未来方向应该是 插件式 或 自定义开关式：

1. 插件式：每个功能或组织可以开发一个独立的 DLL 文件，一个 Mod 可以调用多个 DLL。

   • 在此方向上，我们已经做了一些初步尝试：
     LLF-文本可编辑csf，提供了一种名为 LLF 格式文本 的解决方案，旨在简化 CSF 文件的编辑过程，让游戏直接支持 LLF 文件格式，摆脱传统 CSF 编辑器的繁琐操作。
   • 在此基础上，社区需要一个插件管理器（类似于 Minecraft 的 Mod 管理器或者DP）来处理 Hook 冲突等问题。

2. 自定义开关式：

   • 这是 Phobos 的一个理想发展方向。最好能够让用户自定义编译内容，例如提供一个带有可视化 UI 的编译脚本，让用户选择需要编译的功能模块。
   • 另一种实现方式是我们预先编译好功能，并提供一个类似 Ares 的 INJ 文件功能管理器（需要可视化界面或用户友好的配置文件），使用户能够灵活控制需要启用的功能模块。

[FS-21]

Regarding financial support why not apply something like cncNet Open-collective initiative ?

Some stagnated features that are very interesting or useful could get a push if other people push for it. if overtime the feature got sufficient finnanical ammount maybe it is picked by some contributor/mantainer with more priority.

In the case the feature contributor does it for free & declines the accumulated ammount then the money goes to the mantainer/dev that was checking reviewing it and if the mantainer/dev declines the ammount then that person can push the feature's ammount to another feature he whishes.

Or a similar idea

[reedom114514]

A review from @ststl-s , translated by AI, post by me due to the network issues, the final interpretation is owned by Ststl:

I believe that the main problem is the lack of testers and the slow review process for PullRequests. Many new features, whether in the development build or PR, are eagerly desired by modders. However, due to the prolonged lack of testing, the official version has fallen seriously behind the version they compiled (branches), or even some PRs have never been merged. This leads to the following issues:

First, when a new development version is released, some features may have bugs or be unnecessary for modders, those who are leading to game lag. This discourages modders from testing new versions. Currently, there are fewer and fewer people making RA2 mods, and they have less time. Modders are more inclined to use a compiled dll that is quickly available and stable. Waiting for an official version that is indefinitely delayed is clearly not an acceptable option for them. In the end, they stop following up on tests and simply use an old version of the development build, further reducing the number of testers for new versions and pushing the official release even further away.

Secondly, For developers, such as myself, due to the slow PR review process and insufficient testing, it is often impossible to merge my features into the development branch. However, my friends may require these new features, leading to the creation of custom versions that mix in some new functions. This often involves self-testing and modifications, which are not easily tracked and merged by Git. Typically, after updating my own version, I would manually make changes again to port them to my own phobos branch (and they might not even be correct, some of my PRs have had issues when just simply copying code over, requiring additional adaptation and correction). As time goes on and my academic workload increases, I have even less time to keep these in sync. Eventually, I stop submitting PRs because each one brings complex merging issues between the official version and my custom version, greatly increasing the time cost and leading to a loss of motivation due to the long period without merges (although having someone use the features you've written is certainly a positive psychological boost, even if it has no practical significance).

In the last, although code style is not critical, it affects the speed of the review process. Given time constraints, reviewers prefer to see simple and understandable code rather than spending time trying to understand someone else's naming conventions and guessing the purpose of functions, variables, and hooks. I have had such significant issues with this: my past PRs have been quite arbitrary, and many, including myself, have had to refactor PRs multiple times. It would be best to provide an excellent example, explaining the naming conventions, to make PRs easier to understand.

Okay, so, Issue 1 is difficult to resolve; the reality that must be faced is the continued decline of the YR modding community, and the inevitable reduction in the number of testers. The only thing developers can do is to speed up the PR review process and the release of the official version, even if it's not perfect, as hotfixes can quickly address issues and motivate testers to continue their efforts. However, this again brings up the issue of the time cost for developers, which is limited, and reviewing others' PRs is less satisfying than creating new features and cannot drive more participation, unless developers are motivated to focus on phobos as the core and find more interest and benefit in pushing for the official release of phobos.

Issue 2 is also a result of the slow iteration of the official version and the slow PR review process. Speeding up reviews and the iteration of the official version could at least improve the situation and reduce the time cost of manual merging.

Issue 3 arises from new developers not understanding PR standards well. Adding an example might help to some extent.

Most of these issues are not solvable and can only be alleviated. The time cost for developers and the time cost for modders to test and iterate are fundamentally conflicting points. What that can be done is to reduce waste of time, ensuring that more time is spent on mutual advancement rather than on manual merging and waiting for the next official version.

Original text for reference:
Phobos的问题主要是缺测试者和PR审核太慢了，大量新功能无论是开发构建版本还是PR功能modder都想要用，但是因为长期没人测试导致正式版严重落后于他们想要的功能出现的版本甚至是从来没有合进去的PR，会有以下问题：

1. 开发版本出现新的之后，某些功能存在bug或modder不需要的功能导致游戏变卡顿，让modder没有了测试新版本的动力，现在本身做mod的人已经越来越少，时间也没那么多，modder更倾向于很快就能用得上的，更稳定的版本，等待遥遥无期的正式版对于modder来说显然不是一个可以接受的选择。最后不再跟进测试，干脆用开发版本某一旧版本了事，进一步导致新的版本测试者更少了，正式版更是遥遥无期
2. 开发者方面，开发者比如我自己，由于pr审核过慢，而且测试不足所以长期无法合并到开发分支并呈现在新的版本中，但是自己的朋友或者自己的mod需要这些新的功能，于是开始混合新的功能做自己的定制化版本，但是由于这种做法往往涉及到自己测试，自己修改，这种修改显然不是git可以跟踪并且方便的合并的，往往是自己的版本更新后手动再改一遍弄到Phobos里（而且还不一定正确，我自己的有些PR把代码复制去Phobos结果八成要出问题，还需要很多适配修正），时间长了加上我自己学业也越来越忙更没有时间赖同步这些。最后不再提交pr，因为每个pr都会带来复杂的官方版本和自己的定制版本之间复杂的合并问题让时间成本大大提高，也会因为长期没有合并而失去动力（虽然没有实际意义，但是有人用得上自己写的功能肯定是一种正向精神激励）
3. 代码风格虽然不重要，但是代码风格涉及到审核速度，受限于时间，审核pr肯定希望看到简单易懂的代码而不是花时间试图理解别人的命名规则推测函数，变量，钩子的作用，这点我自己其实有很大问题，我过往提交的pr都比较随心所欲，当时包括饿不死自己也是有很多这样的问题导致我后来也重构了很多次pr，最好能给一个优秀的范例，解释一下命名规范，让pr能更好懂
   1的问题是难以解决的，必须要面对的现实就是yr mod圈持续衰落，测试者变少是完全不可避免的，这点上开发者能做的只有加快pr审核和正式版出现的速度，哪怕正式版不那么完美也可以通过hotfix来快速修复来让测试者有继续跟进的动力。然而这又回到了开发者时间成本上的问题，时间是有限的，而审核其他人的pr又显然没有做出新的功能有满足感无法推动更多的，除非能让开发者都以Phobos为核心，让推动Phobos正式版的出现带来更多的兴趣收益
   2的问题同样也是受限于正式版迭代更新过慢，pr审核过慢这些问题，加快审核和正式版迭代至少可以让情况有所好转，尽量降低这种手动合并的时间成本
   3的问题在于新来的开发者不能很好的理解pr规范，加一个范例或许多少会有些左右
   这些问题多数都是死结，只能缓解不能彻底解决，开发者时间成本，modder测试迭代时间成本这两个完全就是矛盾的两个点，能做的只是减少一些垃圾时间，至少让更多数时间可以互相推进而不是浪费在手动合并，等待新的正式版这种垃圾时间上

[TaranDahl]

话说，我们是否需要个官方QQ群或者其它什么的？我知道这是个国际项目，但似乎大多数用户来自中国，这有助于获得他们的反馈。中文互联网不能直接访问Discord，Github也经常连不上。
By the way, do we need an official QQ group or something else? I know this is an international project, but it seems that most users are from China. This will help obtain their feedback. In the Chinese Internet, Discord cannot be directly accessed, and GitHub is often disconnected.

[Aephiex]

话说，我们是否需要个官方QQ群或者其它什么的？我知道这是个国际项目，但似乎大多数用户来自中国，这有助于获得他们的反馈。中文互联网不能直接访问Discord，Github也经常连不上。 By the way, do we need an official QQ group or something else? I know this is an international project, but it seems that most users are from China. This will help obtain their feedback. In the Chinese Internet, Discord cannot be directly accessed, and GitHub is often disconnected.

Why not? Let's do this.

630590659

(Last one was removed because it was reposted to the Phobos-log channel which may lead to potential leaks of private QQ accounts. Sorry for my privacy anxiety. This comment was initially posted without a QQ group number, and later edited to append the number, meaning it will not be reposted by the bot.)

[TaranDahl]

话说，我们是否需要个官方QQ群或者其它什么的？我知道这是个国际项目，但似乎大多数用户来自中国，这有助于获得他们的反馈。中文互联网不能直接访问Discord，Github也经常连不上。 By the way, do we need an official QQ group or something else? I know this is an international project, but it seems that most users are from China. This will help obtain their feedback. In the Chinese Internet, Discord cannot be directly accessed, and GitHub is often disconnected.

Why not? Let's do this.

630590659

(Last one was removed because it was reposted to the Phobos-log channel which may lead to potential leaks of private QQ accounts. Sorry for my privacy anxiety. This comment was initially posted without a QQ group number, and later edited to append the number, meaning it will not be reposted by the bot.)

Good. But we still need the support from the developers to make this official. @Metadorius What do you think?

[Metadorius]

Good. But we still need the support from the developers to make this official. @Metadorius What do you think?

I don't mind and I can advertise it, but I am not sure if the group itself should be called official. Official groups are usually curated by the staff of the project, which would be only partially true in this case, unless there's some way to get in the group for outsiders like me. Maybe something like "Phobos QQ group (maintained by: usernames here)" without explicitly stating it's official?

I have a few questions though:

• How does QQ work at all? Is it an app, a website?
• Is there moderation and who will be doing it if yes?
• Is it possible for non-Chinese users to join?
• If yes - is there some sort of automated translation available?

[Aephiex]

I have a few questions though:

• How does QQ work at all? Is it an app, a website?
• Is there moderation and who will be doing it if yes?
• Is it possible for non-Chinese users to join?
• If yes - is there some sort of automated translation available?

1. QQ is a Chinese equivalant of discord, except an APP is mandatory.
2. The owner of the group can assign a number of moderators and revoke at will. The capacity depends on how many members are there in a group.
3. Yes, it is, you can either download and use the main branch or go for QQ international. The APP is hard to use and it takes long to tame it, I'm not kidding.
4. I don't think so.

The Chinese netizens are used to call a group "official" as long as it is advertised via an "official" source. Many games have their "official" QQ groups for Chinese players, and the game staffs themselves will not join it.

[DeathFishAtEase]

I have a few questions though:

• If yes - is there some sort of automated translation available?

Unfortunately, QQ only offers manual translation, and you will have to right-click on "Translate" for each conversation to get a result.

[TaranDahl]

I don't mind and I can advertise it, but I am not sure if the group itself should be called official. Official groups are usually curated by the staff of the project, which would be only partially true in this case, unless there's some way to get in the group for outsiders like me. Maybe something like "Phobos QQ group (maintained by: usernames here)" without explicitly stating it's official?

我的设想是最好能由项目的维护者（或者至少是开发者）组织这个群，收集来自中文社区的意见（例如：哪些已有功能需要改进、哪些pr有很多人希望能尽快合并）以及测试成果（例如某个mod的开发者使用包含pr的构建版本进行了测试且表现良好，那么我们可以收集这个信息用于代码审查时的参考），并将其反馈到Discord上。
简单来说就是让这个群在中文社区作为github issue、discussion和discord的替代，因为一部分中国用户使用github和discord有困难。
My idea is that it would be best if a maintainer (or at least a developer) of the project organizes this group to collect opinions from the Chinese community (for example: which existing functions need improvement, which pull requests many people hope can be merged as soon as possible) and test results (for example, if the developer of a mod uses a build version containing a pr for testing and it performs well, then we can collect this information for reference during code review), and feed it back to Discord.
In simple terms, this group is used as a substitute for GitHub issues, discussions, and Discord in the Chinese community because some Chinese users have difficulties using GitHub and Discord.

[Metadorius]

Alright, I'll have to think about the QQ group for a bit more.

Regarding features being too specific: I agree that having Phobos as a playground for only some of the mod developers who are making features custom-made for their mods is, while a somewhat working strategy, not a very good one because it's a bit one-sided. This is why I said we should strive for generalization of features (where reasonably possible without it turning into a complex programming language on it's own).

On other alternatives:

1. Plug-in architecture - I am not sure if this is easily doable in a sensible manner for this project. This also requires quite a bit of effort to do right and not sure if the benefits outweigh the cost. More so, I believe @Xkein is working on a custom scripting solution, so mod-specific non-generic features could be done that way.
2. A program to provide custom builds - I believe this is a big undertaking as well (the project was not built with this in mind and I have little idea how such a program would work, even less so in a user-friendly manner) with less benefit than generalization of features.
3. Togglable custom features - I don't quite understand what benefit that would bring apart from a minor performance increase? Most of the features are barely affecting the performance if not used. More so, if the feature is niche, then it ideally wouldn't be in Phobos at all.

Meanwhile I'll ask the next question: if we were to pick a new person to help maintain Phobos/YRpp, review PRs, release new versions etc., who do you think is the most fitting out of all the current active contributors (if at all) and why? I have my own opinion on this which I mostly intend to follow soon but I want to hear some more thoughts.

So, what I think so far is:

1. To solve the problem of too specific features (and partly the pull request amount) we need to set up some sort of boundaries/requirements for the level of reusability, generic-ness and impact of contributions (questions like "how can this be used outside of the designed use case", "how many mod authors will benefit from such a feature"), and work out a workflow for taking new contributions in. The overly specific features could stay in the forks, be done as separate projects based off the framework set up by Ares/Phobos or even be done using DynamicPatcher or Xkein's new solution.
2. The addition of (a) new maintainer(s) and/or triage(s) for pull request is required, even if it might lower the code standards, and I think we should be looking into expanding and maybe even restructuring our maintenance crew soon. I have an opinion and reasoning for who to pick on my own but I also want to hear others too.
3. (Extra based on prev. messages) The release schedule and versioning needs to be rethought. Current stable release cycle is horrendous. I am thinking that maybe we should be doing development builds followed by almost as frequent release builds. Why? Because it is frequent to release a development build then do a bunch of hotfixes. I think we could treat devbuilds as "alpha/beta" builds and then after the hotfixes just release another small build that will be a "stable" build. Also restructuring the versioning scheme may allow for more automated releases (auto changelog and build generation).

Please say if I missed anything important, and/or leave a reaction if you think we're on right track with this line of thinking so far.

[Metadorius]

P.S. for point 1: Phobos is a community project, hence why it should at least try to cater to the wide community and not individual mod devs. And I also think we all should make a better use of discussions and issues.

Discussions are great for thinking out the feature design and they have upvotes which allow people to express whether they think this should be taken in and/or leave comments to improve how the feature should be implemented. For some reason though ever since I moved feature suggestions to discussions everyone stopped caring about them and they barely get submitted, viewed or upvoted.

[TaranDahl]

Discussions are great for thinking out the feature design and they have upvotes which allow people to express whether they think this should be taken in and/or leave comments to improve how the feature should be implemented. For some reason though ever since I moved feature suggestions to discussions everyone stopped caring about them and they barely get submitted, viewed or upvoted.

也许你应该在README.md里告诉其他人我们正在那里收集意见。
就我个人的印象来说，Discussion中的内容大多是"我想要一个什么什么新功能"，而且很多都不在我的兴趣范围内。当我刚来到这个项目的时候翻过一遍Discussion，然后就没再去那里看过。
Perhaps you should tell others in the README.md that we are collecting opinions there.
Personally, most of the content in Discussion is "I want a certain new function", and many of them are not within my area of interest. When I first came to this project, I flipped through Discussion once and then never looked there again.

[TaranDahl]

To solve the problem of too specific features (and partly the pull request amount) we need to set up some sort of boundaries/requirements for the level of reusability, generic-ness and impact of contributions (questions like "how can this be used outside of the designed use case", "how many mod authors will benefit from such a feature"), and work out a workflow for taking new contributions in. The overly specific features could stay in the forks, be done as separate projects based off the framework set up by Ares/Phobos or even be done using DynamicPatcher or Xkein's new solution.

我觉得投票表决是比较好的。具体需要多少比例支持才能算得上“通用”，这需要实际统计之后才能决定。
I think voting is relatively good. How much support ratio is needed to be considered "universal" needs to be determined after actual statistics.

The addition of (a) new maintainer(s) and/or triage(s) for pull request is required, even if it might lower the code standards, and I think we should be looking into expanding and maybe even restructuring our maintenance crew soon. I have an opinion and reasoning for who to pick on my own but I also want to hear others too.

我推荐CrimRecya👍
I recommend CrimRecya.👍

(Extra based on prev. messages) The release schedule and versioning needs to be rethought. Current stable release cycle is horrendous. I am thinking that maybe we should be doing development builds followed by almost as frequent release builds. Why? Because it is frequent to release a development build then do a bunch of hotfixes. I think we could treat devbuilds as "alpha/beta" builds and then after the hotfixes just release another small build that will be a "stable" build. Also restructuring the versioning scheme may allow for more automated releases (auto changelog and build generation).

更频繁地发布build总是好的。
Releasing builds more frequently is always good.

[CrimRecya]

(Extra based on prev. messages) The release schedule and versioning needs to be rethought. Current stable release cycle is horrendous. I am thinking that maybe we should be doing development builds followed by almost as frequent release builds. Why? Because it is frequent to release a development build then do a bunch of hotfixes. I think we could treat devbuilds as "alpha/beta" builds and then after the hotfixes just release another small build that will be a "stable" build. Also restructuring the versioning scheme may allow for more automated releases (auto changelog and build generation).

I also quite agree with this point.

我也比较认同这一点。

---

我推荐CrimRecya👍
I recommend CrimRecya.👍

I don't think so.
Although I may be enthusiastic about this, I think the more important thing should be ability to become a maintainer.
Obviously, I am not competent enough at present. I have some experience in the implementation of some functions, but when it comes to deeper, what I can do is usually copying and pasting.

我觉得不太合适。
尽管我可能对此比较热情，但我觉得要成为维护者更重要的是能力。
显然我还能力不足，虽然对于一些功能的实现我有些许经验，但涉及更底层知识的，我通常只会复制粘贴。

[Aephiex]

我推荐CrimRecya👍
I recommend CrimRecya.👍

I don't think so. Although I may be enthusiastic about this, I think the more important thing should be ability to become a maintainer. Obviously, I am not competent enough at present. I have some experience in the implementation of some functions, but when it comes to deeper, what I can do is usually copying and pasting.

我觉得不太合适。 尽管我可能对此比较热情，但我觉得要成为维护者更重要的是能力。 显然我还能力不足，虽然对于一些功能的实现我有些许经验，但涉及更底层知识的，我通常只会复制粘贴。

I don't think you have to "learn more" to be "qualified" as a maintainer. Listen, you are a dev, whatever a dev wants they eventually find a path to it, whatever a dev doesn't know they will learn it quickly when needed. It's not a matter of your capacity, it's a matter of your willingness to be a maintainer.

We are already doing something that most modders don't know how to do. We don't born with the knowledge about c++, assembly, hooks, and so on, and we already learnt that through months / years of practise. I don't think there is anything too difficult even we can't learn in any possible future.

[Metadorius]

I don't think so.
Although I may be enthusiastic about this, I think the more important thing should be ability to become a maintainer.
Obviously, I am not competent enough at present. I have some experience in the implementation of some functions, but when it comes to deeper, what I can do is usually copying and pasting.

@CrimRecya I think in these words you devalue your experience and capabilities (compared to what you are really capable of) a lot :)

[a851903106]

I have a very minor question as to whether old PRs that are too old (sitting for 6 months or even a year or more) will still be reviewed and merged.

I also have some PRs that need to wait for another PR to finish merging before I can submit them up. So I opted for the long wait.

However, the wait was so long that I almost lost my enthusiasm to submit them.

[Metadorius]

I have a very minor question as to whether old PRs that are too old (sitting for 6 months or even a year or more) will still be reviewed and merged.

We do want to want to still review (and merge if they're fitting) them. The "PR fridge" as we call it was not intentional.

However, the wait was so long that I almost lost my enthusiasm to submit them.

That's sad but understandable. Hope we'll be able to solve the situation with PRs and maintainers so there would be a point to submit the PRs again. Thanks for understanding the situation and sticking around with us.