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
