https://cwiki.apache.org/confluence/display/HUDI/Community+Support Anyone interested in giving the rotation a shot, please add your name next to the a slot. Let's see how this goes in Jan and we can learn
On Mon, Dec 16, 2019 at 5:27 AM Vinoth Chandar <[email protected]> wrote: > Thanks everyone for the suggestions. Always great to see a healthy > constructive discussion! > > Overall it seems like > - At-least 3-4 are willing to give the support rotation a shot. As > concrete followup, will document the support responsibilities clearly in a > wiki and share it again here. To be clear, ANYONE can answer the dev > questions or GH issues or JIRA at ANY time. The rotation simply exists to > minimize context switching for those willing to take part. > - PR assignment process feels like a good idea. Will try to document the > current process, as we iterate on it in another wiki. And share it here as > well. > - One alternate suggestion proposed multiple times is - growing PoC/Leads > for each area inside Hudi. I am definitely open to this model as well. But, > would n't that have the same skewness in support for handling[1]. For e.g > deltastreamer and datasource are lot more user-facing and will have > questions. I believe the questions follow the 80-20 rule, 80% of questions > can be answered by FAQs/or anyone .. 20% need some sort of > experts/PoCs/code authors to chime in. (That's atleast the healthy endstate > IMHO) > - Immaterial of support, for [2][3], it makes a ton of sense to have area > leads or component owners in JIRA. @mentors any guidance on how they are > assigned in other projects? > > On Sat, Dec 14, 2019 at 7:00 PM 蒋晓峰 <[email protected]> wrote: > >> Hi Vinoth, >> About scaling community support, I agree with the suggestions above >> mentioned. My suggestion is that Hudi community requires contributors, >> committer and PMC member to partipate in community together, who could >> answer users' question of Hudi. Multiple modules should be divided in Hudi >> community, and each module needs one or more committers to follow the >> progress of the module, which helps attract more contributors to the >> community. About community user support, I thought that the community needs >> to vigorously expand Chinese users and train multiple Chinese submitters to >> answer local Chinese user questions, which way Apache Flink practices. >> >> >> Thanks, >> Nicholas >> >> >> >> >> >> >> >> At 2019-12-14 01:28:47, "Vinoth Chandar" <[email protected]> wrote: >> >Thanks everyone for chiming in! Any more thoughts, before I try and >> >summarize? >> > >> >On Tue, Dec 10, 2019 at 9:33 PM Y Ethan Guo <[email protected]> >> >wrote: >> > >> >> Here are my two cents in addition to the great suggestions in the >> thread: >> >> >> >> I agree with @Sivabalan that folks in Hudi community have different >> levels >> >> of expertise and amount of effort to put in the community. So in >> general, >> >> it may be good to have PoCs or contributors for each area in Hudi, >> e.g., >> >> indexing, Timeline, performance, user facing APIs like deltastreamer, >> etc. >> >> Then for issues, tickets and PRs, we may tag and label them >> accordingly so >> >> that contributors can jump on them quickly based on the tags. >> Committers >> >> and PMC members with more expertise can help triage the tickets/PRs >> with >> >> labels in one pass and trickle them down into sub-areas. Then every >> >> contributor can take up something easily without skimming through all >> >> tickets/PRs each day. Speaking from my experience, I'm able to help on >> >> deltastreamer and docs related issues, but not yet comfortable >> addressing >> >> areas like Presto, indexing and such. I feel it's hard to keep track >> of >> >> all tickets/PRs each day by a single person as the number of them are >> >> growing. >> >> >> >> Specifically, >> >> >> >> for [1], we can have the support rotations by triaging the issues, >> tickets >> >> and PRs with labels and tags, and looping in area PoCs and relevant >> >> contributors if necessary. Other contributors are still welcome to >> jump in >> >> this process. >> >> >> >> for [2], similarly, contributors can simply tag the PRs if he or she >> is not >> >> able to review the code in full. The authors of PRs can also tag the >> PRs, >> >> based on the areas, to make the review process easier. Again, other >> >> contributors are still welcome to review the code. >> >> >> >> for [3], as suggested by others, we can have 2-day ETA for the >> responses, >> >> so people can expect a response within the ETA guarantee. The first >> >> response can just be an ack and triaging by looping in related area >> PoCs >> >> and contributors. >> >> >> >> Best, >> >> - Ethan >> >> >> >> On Tue, Dec 10, 2019 at 5:48 PM leesf <[email protected]> wrote: >> >> >> >> > Agree with @Sivabalan that any person who is interested in PRs would >> help >> >> > to review, I think assign PR to someone just indicates that he/she is >> >> > responsible for the progress as the lead person. Anyone is highly >> >> > appreciated and encouraged to review PRs if they are interested. >> >> > >> >> > Best, >> >> > Leesf >> >> > >> >> > Sivabalan <[email protected]> 于2019年12月11日周三 上午5:46写道： >> >> > >> >> > > IMO, open source community has folks with different needs and >> >> interests. >> >> > > For eg: “pro active” folks like you and Balaji who is very active >> in >> >> all >> >> > > aspects of the project. 2nd category is “selectively active” >> people, >> >> who >> >> > > will have good knowledge in few code blocks like Sudha in case of >> >> presto >> >> > > and so on. 3rd category is “active” folks who are interested in the >> >> > > project, but they need to be assigned specific task items for them >> to >> >> > > contribute. 4th is “newly active”, who are genuinely interested to >> >> > > contribute, but got lost somewhere and don’t know where to get >> started >> >> > and >> >> > > will be dormant or slowly fade away. 5th is “user of the project” >> who >> >> > might >> >> > > be interested in consuming the project in most part and doesn’t >> have >> >> real >> >> > > intentions to contribute much. Last set of “passive” who just want >> to >> >> > have >> >> > > a tab at Hudi. >> >> > > >> >> > > I don’t think we can expect everyone to become an active >> contributor >> >> with >> >> > > our proposals. I mean, on a lighter note, the point I am trying to >> make >> >> > is, >> >> > > not sure if we can expect 20 folks to pitch in with our on-call >> >> proposal. >> >> > > Anyways, having said that, I really appreciate you thinking about >> >> scaling >> >> > > the community. It is really important to think these at this >> stage. We >> >> > > should def employ something. >> >> > > >> >> > > Here are my thoughts. >> >> > > 1: having 2 to 3 day on call would really help folks like me who is >> >> > looking >> >> > > to become an active contributor. Just that it may take some time to >> >> > triage >> >> > > an issue compared to someone like you or Balaji. But can’t do >> much, we >> >> > got >> >> > > to go through these to become more active. >> >> > > On the contrary, I am not sure how many among the 15+ contributor >> you >> >> > > quoted would be interested in fielding/answering ANY questions >> related >> >> to >> >> > > hudi. I feel some are more equipped to answer certain questions >> >> relating >> >> > to >> >> > > their forte. To tackle these, I thought of an alternative >> suggestion. >> >> We >> >> > > can have leads for each area in general. Each of these leads should >> >> have >> >> > a >> >> > > tab of people who has good knowledge in these areas and who is just >> >> > getting >> >> > > started. So, for new issues raised, the lead should feel free to >> assign >> >> > to >> >> > > specific person whom he/she thinks could answer. If the issue >> hasn't >> >> been >> >> > > responded within some SLA, then the lead could take charge and >> answer >> >> > them. >> >> > > I understand, that this is differing from the 2-3 day on-call >> strategy, >> >> > but >> >> > > just putting it out to hear others thoughts. Hope is that, slowly >> these >> >> > > folks will become conversant w/ the respective area and might >> start to >> >> > take >> >> > > up issues on their own and not depend on lead to assign them. >> >> > > >> >> > > 2: Again following on the previous proposal, leads for each area >> should >> >> > > assign reviewers for any PRs. Obviously, others can pitch in if >> >> > interested, >> >> > > but we need ways to nurture people to start contributing more. If >> the >> >> > > assigned person is not interested or couldn’t review within some >> SLA, >> >> > then >> >> > > the respective leads or any other leads(if the resp lead is busy >> with >> >> > other >> >> > > stuffs) pitch in. Just that, we don't want Vinoth or Balaji to be >> >> > reviewing >> >> > > every PR out there. >> >> > > >> >> > > 3: Again, similar to 1. Not everyone can answer questions about >> >> anything. >> >> > > So each contributor should nurture a habit of answering and >> helping the >> >> > > community in general with good faith. Don't have good suggestions >> here. >> >> > > >> >> > > >> >> > > On Tue, Dec 10, 2019 at 9:13 AM [email protected] < >> [email protected] >> >> > >> >> > > wrote: >> >> > > >> >> > > > >> >> > > > Regarding (1), I support the "on-call" model for answering to >> dev@ >> >> > > > emails, triaging GH and Jira. This would help reduce >> context-switch >> >> for >> >> > > the >> >> > > > contributor community as a whole. Also, Trying to answer >> questions >> >> > about >> >> > > > Hudi is a good way to ramp up on the internals of it. A 2 day >> >> schedule >> >> > > > would be good way to start and we can try this to see how this >> oncall >> >> > > model >> >> > > > works for us. >> >> > > > Regarding (2), Code-reviews are critical to building our >> community. >> >> > > Maybe, >> >> > > > we can try a recognition model for most active code-reviewers >> every >> >> > month >> >> > > > would help here. We can send a recognition/appreciation email >> >> > > identifying >> >> > > > new and most active code-reviewers. >> >> > > > Regarding (3), How about we assume that if a ticket owner is not >> >> > > > responding for more than 1 or 2 weeks, then they are not working >> on >> >> > this >> >> > > > and we can re-assign if it is a critical feature that needs to go >> >> into >> >> > a >> >> > > > release. The response from ticket owners need not be a complete >> >> answer >> >> > > but >> >> > > > just enough communication that they are actively working on it. I >> >> agree >> >> > > > with @leesf that this depends on each person's situation but a >> clear >> >> > > > communication regarding ETA expectations and sticking to it would >> >> help >> >> > in >> >> > > > project planning. >> >> > > > Thanks,Balaji.V >> >> > > > >> >> > > > >> >> > > > 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. >> >> > > > On Saturday, December 7, 2019, 12:01:28 PM PST, 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 >> >> > > > >> >> > > >> >> > >> >> >> >
