[Ksummit-2012-discuss] [ATTEND] Building up younger contributors and high volume trees

[Jeff Liu]

On 06/22/2012 02:55 PM, Srivatsa S. Bhat wrote:

> On 06/19/2012 09:48 PM, Josef Bacik wrote:
> 
>> Hello,
>>
>> Sorry for using gmail but I'm between email addresses atm.  I've been
>> an active contributor to Btrfs for years now and have done lots of
>> random things in the file system space, mostly in the area of
>> creating/fixing interfaces for things like hole punching and
>> seek_hole/seek_data.
>>
>> I'm interested in the writeback discussions of course but I'm also
>> relatively young in the community, both in age and experience.  I know
>> this topic has been beaten to death over the years and I'd like to
>> join in the beating.  The thing that hinders new contributors the most
>> is that most subsystems have very busy maintainers.  For Btrfs we have
>> Chris who is working just as hard developing the damn thing as well as
>> playing maintainer.  I've tried to step in and handle the patch monkey
>> side of things, that way new contributors patches don't get lost in
>> the fray.
>>
>> Long term developers are all so busy working on their corner of the
>> world that they often don't look up long enough to notice or help new
>> contributors.  This is the same problem with patch reviews as well.  I
>> think that having one person who is in charge of what goes in and
>> doesn't works great for our quality, but it adds a lot of churn where
>> people have to re-send patches over and over to get them included, not
>> to mention sitting there for an entire release period to wait and see
>> if it got picked up or not.  Having something like btrfs-next where I
>> cram anything that hits the mailinglist in (within reason of course) I
>> believe has already helped us immensely with including new
>> contributors and making them feel like they are making progress.  Then
>> from there Chris can have a nice view of what he wants to take and
>> what he doesn't, and all of the other developers have a nice tree to
>> base their work on so we don't all trample on each other.
>>
>> I think having something like btrfs-next for every maintainer would be
>> helpful to existing developers and new developers.  I would like to
>> have a discussion that actually comes up with a solution to the
>> problem that we can all go back and implement, so for example all
>> maintainers appoint a sub-maintainer that takes on this kind of work
>> or something like that.  It seems like every year the conclusion is
>> "yup we could do better, but we're still doing pretty great so carry
>> on!", and I'd like to avoid that this year and have some real tangible
>> thing that most of us go back and implement to try and make every ones
>> life easier.
>>
> 
> 
> Being a new contributor myself, I'd definitely be interested in discussing
> what factors hinder new contributors and what roadblocks they face, so that
> we can try to resolve them.

Me too. somehow, I missed this proposal.

> However, I didn't exactly get what you meant by
> having new trees for each subsystem. Don't we already have enough development
> trees (atleast one for each of the major subsystems) that eventually feed
> linux-next? Or maybe you meant something else and I missed your point..
> (perhaps you were trying to outline how the work involved in managing these
> trees could be split up for faster response times?)

I feel Josef's opinion is if we have a sub-maintainer who could help
merging those patch sets which are qualified and most likely to be
accepted by the project to a xxx-next tree, so that the contributers
don't need to re-send the patches again if they already hit xxx-tree.
At least, it could reduce the exposure rate of [PATCH RESEND] on the
mailing list.

And also, the sub-maintainer could give response to contributers in a
relatively fast point, like a project coordinator maybe.
This might could also make the lead maintainer's life a bit easier,
since the leader could pick up the desired patches from that xxx-next
tree directly.


Thanks,
-Jeff

> 
> Regards,
> 
> Srivatsa S. Bhat
> 
> _______________________________________________
> Ksummit-2012-discuss mailing list
> Ksummit-2012-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/ksummit-2012-discuss