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 <ethan.guoyi...@gmail.com> 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 <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 > > > > > > > > > >
