Hi Vinoth Regarding [1], I recommend that people who cannot triage or find a owner also chip in. i.e. make this open ended so that anyone from community could answer it. But if the thread reaches a dead end or doesnt progress, then such threads should be picked up by someone more experienced eg: someone who knows that part of the code/has more experience in that area. And we need to keep improving FAQs based on questions posted on mailing list. Regarding [2] and [3] - I agree with your thought as I would definitely do the same if it were only me. But I am keen and I am listening to others on the thread. Thanks Kabeer.
On Dec 9 2019, at 6:59 am, Bhavani Sudha <bhavanisud...@gmail.com> wrote: > +1 on 2 or 3 day rotations for mailing list and GH issues. Both work for > me. For [2] and [3] I cant think of a proposal either. May be we can ensure > that each PR has no more than 2 committers involved in the review and we > pull in other only when absolutely necessary. This way there is a spread of > load and also not everyone needs to look into all PRs. > > Thanks, > Sudha > > On Sat, Dec 7, 2019 at 12:01 PM 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 > >
