Hi, @areusch Thank you, for posting the analysis of the benefits and drawbacks of merging a module. I would like to point out that there are a few critical pieces that are missing (mainly on the community side): - Welcome new contributors who would become an added force, these contributors also contribute normally not only contributes to the particular S0 module but also to other modules. - Enable TVM to solve problems that it was not able to atm and empower new users/developers who need them.
Thank you also for bringing up some of the factors to put into consideration in the RFC process: - Discussions of test strategy, modularization, and documentation during the RFC process and not land half-baked code. - Consider the relations among S0 modules to other modules, mainly on implicit impositions that S0 made on, say existing S1 APIs. - Consider the overall complexity of the codebase and presentation to the users. - Ease of maintenance overall for some of the core infra. These are great goals that we all carry when evaluating new modules(including S0) and I also support these goals. They all align with G0. The proposal text does not imply when an S0 module gets established, it will lack these considerations throughout the process. As a matter of fact, we would also take these goals into account when evaluating any proposals(including S0). One possible point of confusion here is connecting S0/S1 to importance, or how good the code is. The proposal intentionally avoids that, an earlier version of the proposal used the term "optional" which causes confusion, and we switched to a clear definition based on "scope of impact" rather than other factors such as importance, or how good the code test coverages are. An S0 module can become more important to some of our users than some of the S1 modules or have better code/tests coverage. The fact that they are more well-scoped simply means it is easier to remove them if needed, and there is less refactoring needed when refactoring other parts of the code. Admittedly, this does not mean that S0 can simply be ignored when working on other modules. It is naturally true that there are considerations around testing and API changes when working on some of the more central modules, they should be considered during RFC and follow-up actions. We want to come back and also acknowledge that the scope of impact is not binary – an S0 module in nature will have non-zero, but (sometimes significantly) less impact compared to non-S0, when it comes to changes in other modules and deprecations. This proposal calls for putting the non-binary scope of impact and community into consideration for module establishment. Of course, such consideration should be put together with other considerations, including tests, documentation, modularization, fit into the overall project, etc. All the members are expected to take these factors into account when evaluating an S0-RFC and make collective decisions for module establishment. This comes to the decision process. There are many discussions that can be made during the RFC process, which is very helpful, for example. Making sure that the proposal is technically correct, providing suggestions to testing coverage, documents, etc. All of us are taking those into account when making that collective decision. Then there comes about reasonings that are relatively subjective reasonings in module establishment. - Say we are introducing a new module to the codebase, majority of core devs think that the module provides new functionality that merits the module establishment, but some think that the new module has overlapped functionality(think about TorchFX and TorchScript case) that does not merit a module establishment. - In some cases, the majority of core devs think that the establishment of a new module to support a not yet supported by the framework outweighs the cost of extra flow maintenance while some do not. These are binary decisions that need to be made collectively by the community, they are likely subjective and different people have different pov and it is natural that people can disagree. Note that everyone also takes these factors into account. The proposal aims to provide guidelines and highlight different levels of open-mindedness. The proposal also helps to clarify the case for deprecation so we can get a cleaner codebase. Previously there wasn’t any text. Indeed we made the “S0 -> deprecation” part to be broad enough so we can handle various cases and we can talk about deprecation openly without having hard feelings about them. For example, in the case of “tests keep breaking or maintainers are relatively unresponsive”, would match this clause to start a discussion of deprecation without hard feelings. Such clarification is a positive step towards a more maintainable codebase overall. Actually having such broadness in the proposal would help, so we can welcome contributions and not have hard feelings when talking about deprecations broadly. As a community we operate by empowering each other. Indeed it is hard to have a 100% clean cut of responsibility boundaries due to some factors being discussed. The scope of impact on the other hand is also not binary. For example, many of us volunteered to review, contribute to core modules, documents, advocations, writing tests and welcoming new members across our “boundaries”. The proposal of course does not mean to indicate that S0 has zero impact on each of us. It certainly has a smaller scope of impact which is worth some different levels of open-mindedness. Remember the contributors/supporters of those modules also are contributing in different ways. They are all valuable and that is what makes us together as a community. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1288784796 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/95/c1288784...@github.com>
