[openstack-dev] Dealing with changes of plans, rejections and other annoyances
anteaya at anteaya.info
Fri Mar 28 01:25:33 UTC 2014
On 03/27/2014 08:12 PM, Stefano Maffulli wrote:
> Hello folks,
> we've been hearing a lot about the incredible growth of the OpenStack
> community but we don't hear much about the incredible amount of pressure
> that comes with such growth. One huge problem that growth brings with is
> that new comers have not had time to assimilate the culture of OpenStack
> community. If you look at the stats and notice that only a small
> percentage of the original developers is still committing code .
> This is translating in more and more people (tens per week) getting
> closer to OpenStack and being greeted in ways that can be too easily
> misunderstood. We've already introduced friendly measures to gerrit so
> that the first time one submits a change for review is greeted with a
> nice email. We're also starting a new program to teach newcomers how to
> be a better upstream contributor. I think these are only partial
> measures and we all as a community need to collaborate on being better
> at dealing with our growth.
> I think we have a nice problem (growth is good) and we should address it
> before it gets too big and unmanageable . I have filed this session for
> the Design Summit and I sincerely hope we'll find time to discuss more
> together in Atlanta:
> Ideally I would like to have in the same room to discuss people who have
> had bad/good experiences with their first commits, people who still
> haven't committed the code they wanted to commit, those afraid of -2 and
> those who love them, those that made grandiose plans and merged and
> those whose plans were squashed... And I would like to have all PTLs
> there too.
> What do you think?
> Best regards,
I'm not sure how broad to interpret your "What do you think?" so I will
offer my thoughts and if that isn't what you meant please correct me.
I looked at the info wiki page for the training. I think one of the
things that creates a gap in those in OpenStack and some of those
wanting to be in OpenStack is the background with which they are
approaching the project.
By background I specifically mean an understanding of opensource and
what that means as an internal metric for behaviour.
I spent time in Neutron and I burnt out. I tried as best I could to work
towards a cohesive workflow based on my best understanding of opensource
activity. The level of comprehension of opensource and its processes
exceeded my ability to offer support for other's learning as well as
accomplish anything personally meaningful in my work.
When those with the internal understanding outnumber those without by a
significant enough ratio, the information comes in myriad unspoken ways.
When I was learning other tasks, camera assistant on films comes to
mind, my ratio was 4:1 - I had 4 people with more knowledge than me
whose job it was directly or indirectly to ensure I learned both the
technical and cultural knowledge necessary to be an asset on set when I
was in training. Part of what I learned was how to train others.
When those with the internal understanding have less than an optimal
ratio to those not having the understanding (I don't know what that
ratio is) then they do the best they can but the amount of newcomers
become overwhelming. The frustrated newcomers then move off in their own
direction when they don't like the speed of development. This can cause
Back to my point, when newcomers come into an opensource project with no
understanding of what opensource means or how to communicate in an
opensource project, that creates additional learning demand that might
not have been in evidence previously.
I wonder if in addition to large numbers of new contributors, there is
an expectation from new contributors that was not in evidence
previously. I also wonder if the new contributors are coming to
openstack with a different understanding of what it means to contribute
to openstack, compared to new contributors a year ago.
I am glad that the newcomers training includes "how to review a patch".
I wonder if there should be any part that includes how to
help/support/teach others in the training. If we teach supporting the
growth of others as an expectation, then the developers can scale
better, at least that has been my experience.
Those are my thoughts, thanks for broaching the topic, Stef,
More information about the OpenStack-dev