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 <leesf0...@gmail.com> 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 <n.siv...@gmail.com> 于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 vbal...@apache.org <vbal...@apache.org> > > 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 < > > > 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 > > > > > >
