Okay, thanks for reminding me, I'll see earlier discuss thread.
At 2019-12-09 14:09:56, "Vinoth Chandar" <vin...@apache.org> wrote: Please see an earlier discuss thread on the same topic - GH issues. Lets please keep this thread to discuss support process, not logistics, if I may say so :) On Sun, Dec 8, 2019 at 10:03 PM lamberken <lamber...@163.com> wrote: In addition, we can use some tags to mark these issues, like "question", "bug", "new feature". we can solve these bug firstly. Best, lamber-ken At 2019-12-09 13:43:38, "lamberken" <lamber...@163.com> wrote: > > >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
