> Having a dragging conversation simply due to bundling reduces the ability for
> volunteers to participate
I'm sorry but having a 'dragging conversation' is entirely the point of a RFC.
It's not a rubber-stamping process, nor should it be. And this RFC
fundamentally changes the governance model of the project.
> I recommend listening to the majority community's voices and empowering the
> community.
Firstly, there aren't many community members even present commenting here, let
alone a majority, so I'm not sure what's meant by this. But more importantly,
and with my Apache hat on, I fundamentally disagree with the characterisation
of those who are not unconditionally supportive of this RFC as
'anti-community'. In my view this is both unnecessarily antagonistic and indeed
wrong.
There are multiple different stakeholders that make up our community, I'll
enumerate 3 types below:
- **Feature developers**
They contribute new capabilities to TVM to ensure it keeps pace with ML
landscape.
- **Maintainers**
They maintain the code to ensure existing capabilities don't regress and fix
bugs when they arise.
- **Users**
They actually apply TVM to real problems so that the project provides value
to the world.
As drafted, S0 modules seek only to empower feature developers at the cost of
maintainers. Users wouldn't even see significant benefits as S0 modules would
necessarily need to be hidden from the majority of users, otherwise they'd
become de facto S1 modules. I therefore consider this proposal, in its current
form, as hostile towards those wishing to contribute towards the maintenance of
TVM.
I would further question whether we have substantial evidence that S0 modules
are routinely blocked. We have 3 different auto-tuners, 3 executors, 12 backend
targets, 14 BYOC targets and 11 frontends too. The vast majority of RFCs are
approved, as are the vast majority of pull requests. These all point towards a
community that is already extremely accommodating of new features, perhaps to a
fault given our limited capacity to maintain these different components.
However, the S1 and S2 mechanisms would be of enormous value to maintainers
(and users!) by strictly defining the maintenance surface (S1) and allowing for
that maintenance surface to shrink as well as grow (S2). This would finally
allow us to start reducing the complexity in the code base and aim to provide a
rock-solid user experience where TVM could compete with PyTorch/TensorFlow/ONNX
on robustness.
Could we therefore please stop pretending this RFC 'empowers the majority of
the community' and say what we mean: it empowers the PMC - the composition of
which currently doesn't closely reflect the active contributors in the
community. There's a clear and obvious route to evolving this proposal into
something that benefits everyone via S1/S2 processes, but for an unknown reason
that's being refused.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1339463770
You are receiving this because you are subscribed to this thread.
Message ID: <apache/tvm-rfcs/pull/95/[email protected]>
