Open Stack

A somewhat self-serving way to start to solve this is to make training and mentoring as the first steps to getting involved with contributions. We would continue to gradually give more responsibilities as the experience and skills increase. We do this last part already, but are missing the support for the mentoring and training. I think landing this mentoring responsibility into the ambassador program makes some sense. 

This doesn't directly solve the subject of this thread. But it does start the process of giving help to those that are trying to learn inline while the cores are trying to land quality code. 

What do you think?

~sean

> On Sep 8, 2014, at 5:20 PM, Stefano Maffulli <stefano at openstack.org> wrote:
> 
>> On 09/05/2014 07:07 PM, James Bottomley wrote:
>> Actually, I don't think this analysis is accurate.  Some people are
>> simply interested in small aspects of a project.  It's the "scratch your
>> own itch" part of open source.  The thing which makes itch scratchers
>> not lone wolfs is the desire to go the extra mile to make what they've
>> done useful to the community.  If they never do this, they likely have a
>> forked repo with only their changes (and are the epitome of a lone
>> wolf).  If you scratch your own itch and make the effort to get it
>> upstream, you're assisting the community (even if that's the only piece
>> of code you do) and that assistance makes you (at least for a time) part
>> of the community.
> 
> I'm starting to think that the processes we have implemented are slowing
> down (if not preventing) "scratch your own itch" contributions. The CLA
> has been identified as the cause for this but after carefully looking at
> our development processes and the documentation, I think that's only one
> part of the problem (and maybe not even as big as initially thought).
> 
> The gerrit workflow for example is something that requires quite an
> investment in time and energy and casual developers (think operators
> fixing small bugs in code, or documentation) have little incentive to go
> through the learning curve.
> 
> To go back in topic, to the proposal to split drivers out of tree, I
> think we may want to evaluate other, simpler, paths before we embark in
> a huge task which is already quite clear will require more cross-project
> coordination.
> 
> From conversations with PTLs and core reviewers I get the impression
> that lots of drivers contributions come with bad code. These require a
> lot of time and reviewers energy to be cleaned up, causing burn out and
> bad feelings on all sides. What if we establish a new 'place' of some
> sort where we can send people to improve their code (or dump it without
> interfering with core?) Somewhere there may be a workflow
> "go-improve-over-there" where a Community Manager (or mentors or some
> other program we may invent) takes over and does what core reviewers
> have been trying to do 'on the side'? The advantage is that this way we
> don't have to change radically how current teams operate, we may be able
> to start this immediately with Kilo. Thoughts?
> 
> /stef
> 
> -- 
> Ask and answer questions on https://ask.openstack.org
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev