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 <[email protected]> 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" <[email protected]> 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" <[email protected]> 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 > >
