Having good documentation in the code at least in the critical
section/methods/classes would ease anyone who would like to understand and
contribute. Given there is going to be issues with availability of
committers to help/mentor, adding "good" documentation can go a long way.
Something to conside
The motivation for contributing opensource work sometimes affected by
projects' popularity. And open source as a whole is hugely impacted by
public cloud companies since their profit-driven mindset. One of the
biggest public cloud provider even discourages employees from contributing
to open source
I think the complexities of actually using HBase is a fairly large
impediment since it limits our user base (where most of the contributors
are likely coming from). HBase is a complex machine and requires someone to
have a significant amount of knowledge of the internal workings to manage.
I think
Ok, that said, given these conditions the best thing we can do is lower
friction so contributors can solve problems for themselves. Things like
github PRs can help. That is the wide part of the funnel.
However a project like hbase has inherent complexity of the code and it’s
enviroment. Persistenc
I don’t think it is realistic, unfortunately. If you remember our OWNERS
initiative, which failed, the idea there was for various functional areas
or components there would in effect be a mentor, someone you could
at-mention for advice and review. This failed because if this isn’t your
full time pa
Another open source project I’m on is exploring the idea of a mentoring
rotation where each mentor serves for a week and especially looks out for
and provides practical assistance and review to new contributors for that
week, on an office-hours type of basis. Many hands make light work. WDYT?
I’d s
+1 one for the mentoring if one existing member who knows the feature plan
and is willing to create tasks for pickup.
my current barrier is to find a continuous topic/component and focus on it,
but I'm a bit too random with my approach.
Currently, not sure this is the right way, I lookup JIRAs by
Would be great to have mentors. Ted used to review my patches and provide
feedback on timely basis, understand everyone is busy but would be nice to
have a point person (per feature, bug, branch, module, etc). I have cycles
to burn but currently it feels a bit overwhelming as community may feel
the
#1 this is difficult code. That’s probably the one we can’t surmount but I
wanted to put it out there.
On Tue, Mar 19, 2019 at 5:03 PM Sean Busbey wrote:
> I have my own opinions, obvs. But I'm curious what other folks think are
> the biggest impediments to new contributors?
>
Good question, some points in my opinion:
1. The current workflow is quite complex compared to github PR workflow.
For ex, creating a JIRA while new
contributors has no permission to assign it to self ? Github PR will help
a lot.
2. Long PR merge cycle, the hadoop QA take a long time, reviewing,
I have my own opinions, obvs. But I'm curious what other folks think are
the biggest impediments to new contributors?
11 matches
Mail list logo
