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 > > >
