> I'd appreciate a separate reply. Here they are:
Thank you for laying out the personas. I agree with some of those categorizations. I would like to point out however, that almost every one of us in the community are wearing multiple hats. I personally contributed features, maintained the modules myself and others contributed, fixes test-cases, bring refactoring, write documents. It is **unfair to use simplified arguments to categorize any S0 proposer as only feature developer**. This is some form of labeling that some of us unconsciously apply in our conversations, and they are not helpful for our conversations nor being fair to many community members here, please stop doing so. Let's come back to think about bringing people along on the journey. Please remember that a set of “maintainers” are not fixed in the community. Bringing additional contributors along would mean we would get more people maintaining the code together. This has been the case in a lot of our past empowerment. The proposal text explicitly suggested that the proposer would need to maintain the module. Additionally, we enable a broader set of people who will help contribute to maintenance of existing modules. These are the people who otherwise will not be given opportunity or motivation to contribute. It is indeed true that there will always be part of impact, and everyone in the community is supposed to take these into consideration when evaluating the factors. In each proposal however, we would certainly evaluate the scenarios, and if such cases do occur – where the proposer ignores the maintenance duty, please let us know and we would certainly take these into strong consideration and resolve the case. The proposal also have an explicit deprecation trigger that makes suh case clear. > Relax RFC treatment I would suggest we move the conversation of relax RFC treatment to the particular thread. But to elaborate a bit, there are indeed constructive explainations of technical approach were taken, features that is going to be implemented. The questions were being genuinely answered through that thread. There was a disagreement on whether or not deprecation roadmap should be included as a gating criteria of that particular RFC that proposes module co-exist -- this is again a disagreement on how we should do things -- which should be resolved through community conversations. I would expect continued conversation, and will work wearing my Apache hat to help resolve that conversation separately from this process RFC and empower the community members. Please share followup thoughts on that thread as well. > Could you reaffirm you're original commitment that this new process will not > apply retroactively, including to Relax? I have stated that and I am reaffirming that the new process will not apply retroactively to existing RFCs, that would include the current relax RFC. It is more important on how the community should move forward in the future. I would love us to be in a world where community's voices are being heard, and we **collectively working** to decide on how we do things through the defined process . I would love us to be in a world where community's voices are being considered as an important factor besides code. As someone who created the project and deeply invested into it, I am very concerned about the needs of community empowerment. Without such empowerment and consideration, we could be very successfull maybe even merging relax, doing very well on the code, but we will simply not get there as a community that empowers each other. Thank you for having this conversation. I know that we have disagreements on hows. I would like to acknowledge again: - The approaches(on must laying out X, Y Z) being described in your post are completely valid and possible approaches on how to do things in Apache TVM. There is nothing wrong in stating these positions. There is nothing wrong for you to make these suggestions on how we should do things. - There are also different valid opinions on how to do do things. Which are also not wrong. Especially when it comes to putting community factor into consideration. Please look into those messages and re-evaluate under these context. In the end, after having conversations constructively, acknowledging different approaches on how to do things. We need to collectively work together on which approach to go as a community. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1339974580 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/95/c1339974...@github.com>
