Hi, I'd like to make suggestions from the perspective of contributor, just for reference only.
About [1] As hudi project grows, users / developers will encounter various problems, will asking issues on this mailing list or GH issues or occasionally slack. I think committers should guide them to create a related jira about their problems firstly. Because committers or PMC may focusing on thier work(fix a bug / develop new features), and don't have enough time to answer these occasionally issues. We can see that Spark, Flink, Hadoop or other popular projects have turned the issue off on github. Users can not create issue on GH, they can create a jira or send a email, so committers / PMC can solve these issues in order. https://github.com/apache/spark https://github.com/apache/flink https://github.com/apache/calcite https://github.com/apache/hadoop Best, lamber-ken At 2019-12-08 04:01:13, "Vinoth Chandar" <vin...@apache.org> wrote: >Hello all, > >As we grow, we need a scalable way for new users/contributors to either >easily use Hudi or ramp up on the project. Last month alone, we had close >to 1600 notifications on commits@. and few hundred emails on this list. In >addition, to authoring RFCs and implementing JIRAs we need to share the >following responsibilities amongst us to be able to scale this process. > >1) Answering issues on this mailing list or GH issues or occasionally >slack. We need a clear owner to triage the problem, reproduce it if needed, >either provide suggestions or file a JIRA - AND always look for ways to >update the FAQ. We need a clear hand off process also. >2) Code review process currently spreads the load amongst all the >committers. But PRs vary dramatically in their complexity and we need more >committers who can review any part of the codebase. >3) Responding to pings/clarifications and unblocking . IMHO committers >should prioritize this higher than working on their own stuff (I know I >have been doing this at some cost to my productivity on the project). This >is the only way to scale and add new committers. committers need to be >nurturing in this process. > >I don't have a clear proposals for scaling 2 & 3, which fall heavily on >committers.. Love to hear suggestions. > >But for 1, I propose we have 2-3 day "Support Rotations" where any >contributor can assume responsibility for support the community. This >brings more focus to support and also fast tracks learning/ramping for the >person on the rotation. It also minimizes interruptions for other folks and >we gain more velocity. I am sure this is familiar to a lot of you at your >own companies. We have at-least 10-15 active contributors at this point.. >So the investment is minimal : doing this once a month. > > A committer and a PMC member will always be designated secondary/backup in >case the primary cannot field a question. I am happy to additionally >volunteer as "always on rotation" as a third level backup, to get this >process booted up. > >Please let me know what you all think. Please be specific in what issue >[1][2] or [3] you are talking about in your feedback > >thanks >vinoth
