Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Adam Spiers]

Doug Hellmann  wrote:

Excerpts from Adam Spiers's message of 2018-04-25 18:15:42 +0100:

[BTW I hope it's not considered off-bounds for those of us who aren't
TC election candidates to reply within these campaign question threads
to responses from the candidates - but if so, let me know and I'll
shut up ;-) ]


Everyone should feel free to participate!


Jeremy Stanley  wrote:

Not only are responses from everyone in the community welcome (and
like many, I think we should be asking questions like this often
outside the context of election campaigning), but I wholeheartedly
agree with your stance on this topic and also strongly encourage you
to consider running for a seat on the TC in the future if you can
swing it.


Thanks both for your support!

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Doug Hellmann]

Excerpts from Adam Spiers's message of 2018-04-25 18:15:42 +0100:
> [BTW I hope it's not considered off-bounds for those of us who aren't
> TC election candidates to reply within these campaign question threads
> to responses from the candidates - but if so, let me know and I'll
> shut up ;-) ]

Everyone should feel free to participate!

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Rico Lin]

2018-04-25 22:13 GMT+08:00 Jeremy Stanley :
>
> On 2018-04-25 14:12:00 +0800 (+0800), Rico Lin wrote:
> [...]
> > I believe to combine API services into one service will be able to
> > scale much easier. As we already starting from providing multiple
> > services and binding with Apache(Also concern about Zane's
> > comment), we can start this goal by saying providing unified API
> > service architecture (or start with new oslo api service). If we
> > reduce the difference between implementation from API service in
> > each OpenStack services first, maybe will make it easier to manage
> > or upgrade (since we unfied the package requirements) and even
> > possible to accelerate APIs.
> [...]
>
> How do you see this as being either similar to or different from the
> https://git.openstack.org/cgit/openstack/oaktree/tree/README.rst
> effort which is currently underway?

I think it's different from oaktree, since oaktree is an upper layer which
depends on API Services (allow shade to connected with), And what I'm
saying is to unify all API Servers. An example will be like what tempest do
for tests, tempest provide cmd and tools to help you generate and run test
cases, each service only required to provide a plugin. So if first step (to
unified) is complete, we can even focus on enhancing API service for all,
and the cool part is, we only need to do it in a single place for all
projects. Think about what happens when Tempest trying to enhance test
performance (just do it and check the gate is green).
Also, what kevin's idea is to have a API service to replace all API
service, which IIUC will be a API server directly use RPC to reach
backend for each services in OpenStack. So it's also different too.

> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
May The Force of OpenStack Be With You,
Rico Lin
irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Jeremy Stanley]

On 2018-04-25 18:15:42 +0100 (+0100), Adam Spiers wrote:
> [BTW I hope it's not considered off-bounds for those of us who aren't
> TC election candidates to reply within these campaign question threads
> to responses from the candidates - but if so, let me know and I'll
> shut up ;-) ]
[...]

Not only are responses from everyone in the community welcome (and
like many, I think we should be asking questions like this often
outside the context of election campaigning), but I wholeheartedly
agree with your stance on this topic and also strongly encourage you
to consider running for a seat on the TC in the future if you can
swing it.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Adam Spiers]

[BTW I hope it's not considered off-bounds for those of us who aren't
TC election candidates to reply within these campaign question threads
to responses from the candidates - but if so, let me know and I'll
shut up ;-) ]

Zhipeng Huang  wrote:

Culture wise, being too IRC-centric is definitely not helping, from my own
experience getting new Cyborg developer joining our weekly meeting from
China. Well we could always argue it is part of a open source/hacker
culture and preferable to commercial solutions that have the constant risk
of suddenly being shut down someday. But as OpenStack becomes more
commercialized and widely adopted, we should be aware that more and more
(potential) contributors will come from the groups who are used to
non-strictly open source environment, such as product develop team which
relies on a lot of "closed source" but easy to use softwares.

The change ? Use more video conferences, and more commercial tools that
preferred in certain region. Stop being allergic to non-open source
softwares and bring more capable but not hacker culture inclined
contributors to the community.


I respectfully disagree :-)


I know this is not a super welcomed stance in the open source hacker
culture. But if we want OpenStack to be able to sustain more developers and
not have a mid-life crisis then got fringed, we need to start changing the
hacker mindset.


I think that "the hacker mindset" is too ambiguous and generalized a
concept to be useful in framing justification for change.  From where
I'm standing, the hacker mindset is a wonderful and valuable thing
which should be preserved.

However, if that conflicts with other goals of our community, such as
reducing barrier to entry, then yes that is a valid concern.  In that
case we should examine in more detail the specific aspects of hacker
culture which are discouraging potential new contributors, and try to
fix those, rather than jumping to the assumption that we should
instead switch to commercial tools.  Given the community's "Four
Opens" philosophy and strong belief in the power of Open Source, it
would be inconsistent to abandon our preference for Open Source tools.

For example, proprietary tools such as Slack are not popular because
they are proprietary; they are popular because they have a very
intuitive interface and convenient features which people enjoy.  So
when examining the specific question "What can we do to make it easier
for OpenStack newbies to communicate with the existing community over
a public instant messaging system?", the first question should not be
"Should we switch to a proprietary tool?", but rather "Is there an
open source tool which provides enough of the functionality we need?"

And in fact in the case of instant messaging, I believe the answer is
yes, as I previously pointed out:

   http://lists.openstack.org/pipermail/openstack-sigs/2018-March/000332.html

Similarly, there are plenty of great Open Source solutions for voice
and video communications.

I'm all for changing with the times and adapting workflows to harness
the benefits of more modern tools, but I think it's wrong to
automatically assume that this can only be achieved via proprietary
solutions.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Jeremy Stanley]

On 2018-04-25 14:12:00 +0800 (+0800), Rico Lin wrote:
[...]
> I believe to combine API services into one service will be able to
> scale much easier. As we already starting from providing multiple
> services and binding with Apache(Also concern about Zane's
> comment), we can start this goal by saying providing unified API
> service architecture (or start with new oslo api service). If we
> reduce the difference between implementation from API service in
> each OpenStack services first, maybe will make it easier to manage
> or upgrade (since we unfied the package requirements) and even
> possible to accelerate APIs.
[...]

How do you see this as being either similar to or different from the
https://git.openstack.org/cgit/openstack/oaktree/tree/README.rst
effort which is currently underway?
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Rico Lin]

2018-04-25 0:04 GMT+08:00 Fox, Kevin M :
>
> Yeah, I agree k8s seems to have hit on a good model where interests are
separately grouped from the code bases. This has allowed architecture to
not to be too heavily influenced by the logical groups interest.
>
> I'll go ahead and propose it again since its been a little while. In
order to start breaking down the barriers between Projects and start
working more towards integration, should the TC come up with an
architecture group? Get folks from all the major projects involved in it
and sharing common infrastructure.
>
> One possible pie in the sky goal of that group could be the following:
>
> k8s has many controllers. But they compile almost all of them into one
service. the kube-apiserver. Architecturally they could break them out at
any point, but so far they have been able to scale just fine without doing
so. Having them combined has allowed much easier upgrade paths for users
though. This has spurred adoption and contribution. Adding a new controller
isn't a huge lift to an operator. they just upgrade to the newest version
which has the new controller built in.
>

I believe to combine API services into one service will be able to scale
much easier. As we already starting from providing multiple services and
binding with Apache(Also concern about Zane's comment), we can start this
goal by saying providing unified API service architecture (or start with
new oslo api service). If we reduce the difference between implementation
from API service in each OpenStack services first, maybe will make it
easier to manage or upgrade (since we unfied the package requirements) and
even possible to accelerate APIs.

> Could the major components, nova-api, neutron-server, glance-apiserver,
etc be built in a way to have 1 process for all of them, and combine the
upgrade steps such that there is also, one db-sync for the entire
constellation?
>

I like Zane's idea of combining services in Compute Node.

> The idea would be to take Constellations idea one step farther. That the
Projects would deliver python libraries(and a binary for stand alone
operation). Constilations would actually provide a code deliverable, not
just reference architecture, combining the libraries together into a single
usable entity. Operators most likely would consume the Constilations
version rather then the individual Project versions.
>
> What do you think?

It won't hurt when we providing unified OpenStack command (and it's
actually a great stuff), and it should not break anything for API. Maybe
just one more API service call OpenStack API service and it base on teams
to said providing plugin or not. I think we will eventually reach the goal
in this way.

>
> Thanks,
> Kevin--
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Zhipeng Huang]

I think many projects are now beginning to develop the sub-team structure
(e.g Nova, Ironic and Cyborg) and that might be part of the answer here.

Having a sub-team structure and also have volunteer as sub team leads could
also help people that are not good at code review to contribute
significantly and get recognized in another way.

On Tue, Apr 24, 2018 at 7:24 PM, Davanum Srinivas  wrote:

> Thierry,
>
> please see below:
>
> On Tue, Apr 24, 2018 at 6:24 AM, Thierry Carrez 
> wrote:
> > Fox, Kevin M wrote:
> >> OpenStack has created artificial walls between the various Projects. It
> shows up, for example, as holes in usability at a user level or extra
> difficulty for operators juggling around so many projects. Users and for
> the most part, Operators don't really care about project organization, or
> ptls, or cores or such.  OpenStack has made some progress this direction
> with stuff like the unified cli. But OpenStack is not very unified.
> >
> > I've been giving this some thought (in the context of a presentation I
> > was giving on hard lessons learned from 8 years of OpenStack). I think
> > that organizing development around project teams and components was the
> > best way to cope with the growth of OpenStack in 2011-1015 and get to a
> > working set of components. However it's not the best organization to
> > improve on the overall "product experience", or for a maintenance phase.
> >
> > While it can be confusing, I like the two-dimensional approach that
> > Kubernetes followed (code ownership in one dimension, SIGs in the
> > other). The introduction of SIGs in OpenStack, beyond providing a way to
> > build closer feedback loops around specific topics, can help us tackle
> > this "unified experience" problem you raised. The formation of the
> > upgrades SIG, or the self-healing SIG is a sign that times change. Maybe
> > we need to push in that direction even more aggressively and start
> > thinking about de-emphasizing project teams themselves.
>
> Big +1. Another thing to check into is how can we split some of the
> work the PTL does into multiple roles ... that are short term and is
> rotated around. Hoping that will help with the problem where we need
> folks to be totally available full time to do meaningful work in a
> project.
>
> > --
> > Thierry Carrez (ttx)
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Zane Bitter]

On 24/04/18 12:04, Fox, Kevin M wrote:

Yeah, I agree k8s seems to have hit on a good model where interests are 
separately grouped from the code bases. This has allowed architecture to not to 
be too heavily influenced by the logical groups interest.

I'll go ahead and propose it again since its been a little while. In order to 
start breaking down the barriers between Projects and start working more 
towards integration, should the TC come up with an architecture group? Get 
folks from all the major projects involved in it and sharing common 
infrastructure.

One possible pie in the sky goal of that group could be the following:

k8s has many controllers. But they compile almost all of them into one service. 
the kube-apiserver. Architecturally they could break them out at any point, but 
so far they have been able to scale just fine without doing so. Having them 
combined has allowed much easier upgrade paths for users though. This has 
spurred adoption and contribution. Adding a new controller isn't a huge lift to 
an operator. they just upgrade to the newest version which has the new 
controller built in.

Could the major components, nova-api, neutron-server, glance-apiserver, etc be 
built in a way to have 1 process for all of them, and combine the upgrade steps 
such that there is also, one db-sync for the entire constellation?


In the pre-containers era one of the most common complaints I heard from 
operators was that they were forced to upgrade stuff in lock-step 
(because of library version dependencies) when they really wanted to 
upgrade each service independently. So this definitely wouldn't work for 
everyone.


Another idea that has been floated on occasion is of combining all of 
the bits of services that run on a compute node (which include parts of 
Nova, Cinder, Neutron, Ceilometer, ) into a single... thing. I wonder 
if that wouldn't be a more interesting place to start.



The idea would be to take Constellations idea one step farther. That the 
Projects would deliver python libraries(and a binary for stand alone operation).


In the sense that we've switched most things with a REST API to running 
in Apache using wsgi, that's _technically_ what's happening already ;)



Constilations would actually provide a code deliverable, not just reference 
architecture, combining the libraries together into a single usable entity. 
Operators most likely would consume the Constilations version rather then the 
individual Project versions.


If I'm reading right, you're suggesting that users who just want a quick 
way to install a small cloud would use a turn-key controller node 
package, while those who need something more sophisticated could 
continue to install the individual services separately?


It's an interesting idea, but users of the first sort have a tendency to 
turn into users of the second sort, and they want a smooth upgrade path 
when that happens. I suspect that's why there aren't any deployment 
tools that use this model, even though there are probably no technical 
obstacles to it even today.



What do you think?


With respect to the db_sync specifically, I think the main problem is 
that it exists at all. You want to be able to do a simple rolling update 
where you start containers containing new versions of the code, and then 
shut down containers containing old versions of the code. Right now you 
have to somehow run db_sync with the new code but make sure it happens 
before starting the service with the new code - and in some cases you 
may have to shut down the old code first. (And as non-conducive as that 
is to orchestrated container deployments, it was 10 times worse 
pre-containers when it was virtually impossible to install the two 
versions of the code side-by-side.) But once your deployment tool has 
solved that horrible problem, it's not difficult for it to add a 
for-loop to do it for every service.


What would be a bigger win would be to get rid of db_sync altogether. It 
was born in an era when we did massive data migrations between versions. 
We've now adopted guidelines for rolling updates saying that we should 
only do fast operations like adding/dropping tables/columns during 
db_sync, and that deprecation periods must permit the DB to be upgraded 
while instances of the previous version of the service are still 
running. Once services comply with those guidelines is there any reason 
we can't just always update the DB schema during service start-up and 
ditch the separate `-manage db_sync` commands? Maybe that would 
be a good project-wide goal for an upcoming release.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Mathieu Gagné]

On Tue, Apr 24, 2018 at 3:51 PM, Fox, Kevin M  wrote:
> I support 12 factor. But 12 factor only works if you can commit to always 
> deploying on top of 12 factor tools. If OpenStack committed to only ever 
> deploying api services on k8s then my answer might be different. but so far 
> has been unable to do that. Barring that, I think simplifying the operators 
> life so you get more users/contributors has priority over pure 12 factor 
> ideals.
>
> It also is about getting Project folks working together to see how their 
> parts fit (or not) in the greater constilation. Just writing a document on 
> how you could fit things together doesn't show the kinds of suffering that 
> actually integrating it into a finished whole could show.
>
> Either way though, I think a unified db-sync would go a long way to making 
> OpenStack easier to maintain as an Operator.

Yes please. Or any task that's remotely similar.

--
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Fox, Kevin M]

I support 12 factor. But 12 factor only works if you can commit to always 
deploying on top of 12 factor tools. If OpenStack committed to only ever 
deploying api services on k8s then my answer might be different. but so far has 
been unable to do that. Barring that, I think simplifying the operators life so 
you get more users/contributors has priority over pure 12 factor ideals.

It also is about getting Project folks working together to see how their parts 
fit (or not) in the greater constilation. Just writing a document on how you 
could fit things together doesn't show the kinds of suffering that actually 
integrating it into a finished whole could show.

Either way though, I think a unified db-sync would go a long way to making 
OpenStack easier to maintain as an Operator.

Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Tuesday, April 24, 2018 9:13 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] campaign question: How can we make 
contributing to OpenStack easier?

On 04/24/2018 12:04 PM, Fox, Kevin M wrote:
> Could the major components, nova-api, neutron-server, glance-apiserver, etc 
> be built in a way to have 1 process for all of them, and combine the upgrade 
> steps such that there is also, one db-sync for the entire constellation?

So, basically the exact opposite of the 12-factor app design that
"cloud-native" people espouse?

-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Jay Pipes]

On 04/24/2018 12:04 PM, Fox, Kevin M wrote:

Could the major components, nova-api, neutron-server, glance-apiserver, etc be 
built in a way to have 1 process for all of them, and combine the upgrade steps 
such that there is also, one db-sync for the entire constellation?


So, basically the exact opposite of the 12-factor app design that 
"cloud-native" people espouse?


-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Fox, Kevin M]

Yeah, I agree k8s seems to have hit on a good model where interests are 
separately grouped from the code bases. This has allowed architecture to not to 
be too heavily influenced by the logical groups interest.

I'll go ahead and propose it again since its been a little while. In order to 
start breaking down the barriers between Projects and start working more 
towards integration, should the TC come up with an architecture group? Get 
folks from all the major projects involved in it and sharing common 
infrastructure.

One possible pie in the sky goal of that group could be the following:

k8s has many controllers. But they compile almost all of them into one service. 
the kube-apiserver. Architecturally they could break them out at any point, but 
so far they have been able to scale just fine without doing so. Having them 
combined has allowed much easier upgrade paths for users though. This has 
spurred adoption and contribution. Adding a new controller isn't a huge lift to 
an operator. they just upgrade to the newest version which has the new 
controller built in.

Could the major components, nova-api, neutron-server, glance-apiserver, etc be 
built in a way to have 1 process for all of them, and combine the upgrade steps 
such that there is also, one db-sync for the entire constellation?

The idea would be to take Constellations idea one step farther. That the 
Projects would deliver python libraries(and a binary for stand alone 
operation). Constilations would actually provide a code deliverable, not just 
reference architecture, combining the libraries together into a single usable 
entity. Operators most likely would consume the Constilations version rather 
then the individual Project versions.

What do you think?

Thanks,
Kevin


From: Thierry Carrez [thie...@openstack.org]
Sent: Tuesday, April 24, 2018 3:24 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] campaign question: How can we make 
contributing to OpenStack easier?

Fox, Kevin M wrote:
> OpenStack has created artificial walls between the various Projects. It shows 
> up, for example, as holes in usability at a user level or extra difficulty 
> for operators juggling around so many projects. Users and for the most part, 
> Operators don't really care about project organization, or ptls, or cores or 
> such.  OpenStack has made some progress this direction with stuff like the 
> unified cli. But OpenStack is not very unified.

I've been giving this some thought (in the context of a presentation I
was giving on hard lessons learned from 8 years of OpenStack). I think
that organizing development around project teams and components was the
best way to cope with the growth of OpenStack in 2011-1015 and get to a
working set of components. However it's not the best organization to
improve on the overall "product experience", or for a maintenance phase.

While it can be confusing, I like the two-dimensional approach that
Kubernetes followed (code ownership in one dimension, SIGs in the
other). The introduction of SIGs in OpenStack, beyond providing a way to
build closer feedback loops around specific topics, can help us tackle
this "unified experience" problem you raised. The formation of the
upgrades SIG, or the self-healing SIG is a sign that times change. Maybe
we need to push in that direction even more aggressively and start
thinking about de-emphasizing project teams themselves.

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Davanum Srinivas]

Thierry,

please see below:

On Tue, Apr 24, 2018 at 6:24 AM, Thierry Carrez  wrote:
> Fox, Kevin M wrote:
>> OpenStack has created artificial walls between the various Projects. It 
>> shows up, for example, as holes in usability at a user level or extra 
>> difficulty for operators juggling around so many projects. Users and for the 
>> most part, Operators don't really care about project organization, or ptls, 
>> or cores or such.  OpenStack has made some progress this direction with 
>> stuff like the unified cli. But OpenStack is not very unified.
>
> I've been giving this some thought (in the context of a presentation I
> was giving on hard lessons learned from 8 years of OpenStack). I think
> that organizing development around project teams and components was the
> best way to cope with the growth of OpenStack in 2011-1015 and get to a
> working set of components. However it's not the best organization to
> improve on the overall "product experience", or for a maintenance phase.
>
> While it can be confusing, I like the two-dimensional approach that
> Kubernetes followed (code ownership in one dimension, SIGs in the
> other). The introduction of SIGs in OpenStack, beyond providing a way to
> build closer feedback loops around specific topics, can help us tackle
> this "unified experience" problem you raised. The formation of the
> upgrades SIG, or the self-healing SIG is a sign that times change. Maybe
> we need to push in that direction even more aggressively and start
> thinking about de-emphasizing project teams themselves.

Big +1. Another thing to check into is how can we split some of the
work the PTL does into multiple roles ... that are short term and is
rotated around. Hoping that will help with the problem where we need
folks to be totally available full time to do meaningful work in a
project.

> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Thierry Carrez]

Fox, Kevin M wrote:
> OpenStack has created artificial walls between the various Projects. It shows 
> up, for example, as holes in usability at a user level or extra difficulty 
> for operators juggling around so many projects. Users and for the most part, 
> Operators don't really care about project organization, or ptls, or cores or 
> such.  OpenStack has made some progress this direction with stuff like the 
> unified cli. But OpenStack is not very unified.

I've been giving this some thought (in the context of a presentation I
was giving on hard lessons learned from 8 years of OpenStack). I think
that organizing development around project teams and components was the
best way to cope with the growth of OpenStack in 2011-1015 and get to a
working set of components. However it's not the best organization to
improve on the overall "product experience", or for a maintenance phase.

While it can be confusing, I like the two-dimensional approach that
Kubernetes followed (code ownership in one dimension, SIGs in the
other). The introduction of SIGs in OpenStack, beyond providing a way to
build closer feedback loops around specific topics, can help us tackle
this "unified experience" problem you raised. The formation of the
upgrades SIG, or the self-healing SIG is a sign that times change. Maybe
we need to push in that direction even more aggressively and start
thinking about de-emphasizing project teams themselves.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Rochelle Grober]

Doug Hellmann wrote:
> I would like for us to collect some more data about what efforts teams are
> making with encouraging new contributors, and what seems to be working or
> not. In the past we've done pretty well at finding new techniques by
> experimenting within one team and then adapting the results to scale them
> out to other teams.
> 
> Does anyone have any examples of things that we ought to be trying more
> of?
> 

Okay, here I am sticking my foot in it after reading all the other excellent 
replies.  Lots of good suggestions.  Matt, Zane, Chris, Rico, etc.  Here are is 
another one:

I've noticed that as the projects mature, they have developed some new 
processes that are regular, but not daily.  Some are baked into the schedule, 
others are scheduled on a semi recurring basis but not "official.  One that 
I've seen a few times is the "bug swat day".  Some projects are scheduling 
triage and fix days throughout the cycle.  One project just decided to make it 
monthly.  This is great.  Invite Ops and users to participate.  Invite the 
folks who filed the bugs you might fix to participate.  Use IRC, paste and 
etherpad to develop the fixes and show the symptoms.  Maybe to develop the test 
to demonstrate the fix works, too.  If an operator really wants to see a bug 
fixed, they let the project know and let them know when she will turn up in IRC 
to help.  If they help enough, add them as co-owner of the patch.  Don't make 
them get all the accounts (if that's possible with Gerrit), just put their name 
on it.  They'll be overjoyed to both have the bug fixed *and* get some credit 
for stepping up.  This get devs, users and ops all on the same IRC page, 
focusing on enduser problems and collaborating on solutions in a regularly 
scheduled day(time) slot.  And the "needs more info" problem for bugs gets 
solved.

You can also invite everyone to Spec review days, or test writing days, or 
documentation days.  And you can invites students, academicians, etc.  If 
people know to show up, and they know *if* they show up *and* they are willing 
to discuss symptoms, ask questions, provide logs, whatever, that some pain in 
their butt will be closer to getting fixed, some will show up.  You give them 
credit and they'll feel even better showing up.

Not quite drive-by contributors, but it means pain points get addressed based 
on participation and existing contributors partner with the people who know the 
pain points to solve them.  On a regularly scheduled basis.  Oh, and you can 
put these days on the OpenStack event schedule, too.

--Rocky
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Fox, Kevin M]

One more I'll add which is touched on a little below. Contributors spawn from a 
healthy Userbase/Operatorbase. If their needs are not met, then they go 
elsewhere and the contributor base shrinks. OpenStack has created artificial 
walls between the various Projects. It shows up, for example, as holes in 
usability at a user level or extra difficulty for operators juggling around so 
many projects. Users and for the most part, Operators don't really care about 
project organization, or ptls, or cores or such.  OpenStack has made some 
progress this direction with stuff like the unified cli. But OpenStack is not 
very unified. I think OpenStack, as a whole, needs to look at ways to minimize 
how its archetecture impacts Users/Operators so they don't continue to migrate 
to platforms that do minimize the stuff they have the operator/user deal with. 
One goes to a cloud so you don't have to deal so much with the details.

Thanks,
Kevin

_
___
From: Zane Bitter [zbit...@redhat.com]
Sent: Monday, April 23, 2018 1:47 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] campaign question: How can we make 
contributing to OpenStack easier?

On 23/04/18 10:06, Doug Hellmann wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
>
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
>
> Which of those would you change, and how?

There's probably two separate groups we need to consider. The first is
operators and users of OpenStack. We want those folks to contribute when
they see a problem or an opportunity to improve, and their feedback is
extremely valuable because they know the product best. We need to
encourage new contributors in this group and retain existing ones by:

* Reducing barriers to contributing, like having to register for
multiple services, sign a CLA  We're mostly aware of the problems in
this area and have been making incremental progress on them over a long
period of time.

* Encouraging people to get involved. Low-hanging-fruit bug lists are
useful. Even something like a link on every docs page indicating where
to edit the source would help encourage people to take that first step.
(Technically we have this when you click the 'bug' link - but it's not
obvious, and you need to sign up for a Launchpad account to use it...
see above.) Once people have done the initial setup work for a first
patch, they're more likely to contribute again. The First Contact SIG is
doing great work in this area.

* The most important one: provide prompt, actionable feedback on
changes. Nothing kills contributor motivation like having your changes
ignored for months. Unfortunately this is also the hardest one to deal
with; the situation is different in every project, and much depends on
the amount of time available from the existing contributors. Adding more
core reviewers helps; finding ways to limit the proportion of the code
base that a core reviewer is responsible for (either by splitting up
repos or giving cores a specific area of responsibility in a repo) would
be one way to train them quicker.

Another way, which I already alluded to in my candidacy message, is to
expand the pool of OpenStack users. One of my goals is to make OpenStack
an attractive cloud platform to write applications against, and not
merely somewhere to get a VM to run your application in. If we can
achieve that we'll increase the market for OpenStack and hence the
number of users and thus potential contributors. But those new users
would be more motivated than anyone to find and fix bugs, and they're
already developers so they'd be disproportionately more likely to
contribute code in addition to documentation or bug reports (which are
also important contributions).


The second group is those who are paid specifically to spend a portion
of their time on upstream contribution, which brings us to...

> Where else should we be looking for contributors?

Companies who are making money from OpenStack! It's their responsibility
to maintain the commons and, collectively speaking at least, their
problem if they don't.

For a start, we need to convince anybody who is ma

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Sean McGinnis]

> 
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
> 
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
> 
> Which of those would you change, and how?
> 

Comparing OpenStack contribution to other open source projects, the biggest and
most obvious thing coming in to it is our use of gerrit vs GitHub pull
requests. For those used to contributing to other current large scale projects,
this can be a non-intuitive thing for them to learn. Luckily, I think we have a
lot of guidance documented on how our workflow works. And having worked with
both types of projects, I definitely would not propose or support moving away
from Gerrit, even with it's warts.

One of the bigger challenges I see for new or casual contributors is the
tendency for a lot of projects to only accept perfection. I don't know if this
is a side effect of the explosive growth years, something we have indirectly
encouraged with the way we do code reviews, or some other factor, but I have
seen plenty of patches proposed that are clear improvements, but get downvoted
for comment spelling, preferred variable naming, or other minor things that
either are not ultimately too important or would be easy to clean up with a
later patch.

I do think it's important we have high standards for new code accepted into our
projects. We need to make sure we are delivering high quality services and
tools. But for things that do not end up changing the end user or operator
experience of using OpenStack, I feel we need to be more relaxed. This can
easily change things for a new or casual contributor. They might get excited to
find something they can quickly change in the code to improve things, but then
get discouraged and leave and never come back if we make it look like we are
more concerned about grammatically correct code comments than functioning code.

I would also love to see more of our existing members spend time helping new
contributors. But I don't know how we can really change any policies to make
this more likely to happen. Speaking from experience, even for full time
contributors (or maybe especially for full time contributors?) we are usually
already busy with several other things that make it hard to carve out the time
to work with someone new. But I do feel it is an important way to welcome new
contributors and make sure it is not always the same folks overloaded on trying
to address several issues at the same time.

We do have some great work done with our onboarding documentation and our
regular events with the Upstream Institute. We just need to make some effort to
help consumers of those resources move on past that point.

Which makes me think of some of the discussion we've had about getting people
to core. I am actually not sure if this is the right focus. I do think it would
be great to have a lot of core members or potential candidates, but I think
there are plenty of contributors that would like to be involved and would be
able really help out projects without necessarily wanting or needing to be
cores to do so. I would like to see more focus on helping people contribute
without needing to commit to taking on more responsibilities.

> Where else should we be looking for contributors?
> 

Universities are a good one. And being an open source project in a relatively
easy to learn programming language, I think we could do more to encourage
formal programs with CS schools as something students could do. I've brought up
the idea of "internships" in the past. It would be great if we could work with
schools to set up some sort of program where we are able to help someone new
through accomplishing a discrete set up tasks that can benefit all involved.

I do think the majority of our resources will be through commercial interests
though, with vendors using or benefitting from OpenStack contributing
development, infrastructure, or testing to help the project continue to meet
their customers' needs. NFV is a big area now where I think there are some
resistant to changes being driven to meet their use cases, but I think it's
important that we are open to those types of changes in order for OpenStack to
be able to meet their needs.

Sean

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Zane Bitter]

On 23/04/18 10:06, Doug Hellmann wrote:

[This is meant to be one of (I hope) several conversation-provoking
questions directed at prospective TC members to help the community
understand their positions before considering how to vote in the
ongoing election.]

Over the last year we have seen some contraction in the number of
companies and individuals contributing to OpenStack. At the same
time we have started seeing contributions from other companies and
individuals. To some degree this contraction and shift in contributor
base is a natural outcome of changes in OpenStack itself along with
the rest of the technology industry, but as with any change it
raises questions about how and whether we can ensure a smooth
transition to a new steady state.

What aspects of our policies or culture make contributing to OpenStack
more difficult than contributing to other open source projects?

Which of those would you change, and how?


There's probably two separate groups we need to consider. The first is 
operators and users of OpenStack. We want those folks to contribute when 
they see a problem or an opportunity to improve, and their feedback is 
extremely valuable because they know the product best. We need to 
encourage new contributors in this group and retain existing ones by:


* Reducing barriers to contributing, like having to register for 
multiple services, sign a CLA  We're mostly aware of the problems in 
this area and have been making incremental progress on them over a long 
period of time.


* Encouraging people to get involved. Low-hanging-fruit bug lists are 
useful. Even something like a link on every docs page indicating where 
to edit the source would help encourage people to take that first step. 
(Technically we have this when you click the 'bug' link - but it's not 
obvious, and you need to sign up for a Launchpad account to use it... 
see above.) Once people have done the initial setup work for a first 
patch, they're more likely to contribute again. The First Contact SIG is 
doing great work in this area.


* The most important one: provide prompt, actionable feedback on 
changes. Nothing kills contributor motivation like having your changes 
ignored for months. Unfortunately this is also the hardest one to deal 
with; the situation is different in every project, and much depends on 
the amount of time available from the existing contributors. Adding more 
core reviewers helps; finding ways to limit the proportion of the code 
base that a core reviewer is responsible for (either by splitting up 
repos or giving cores a specific area of responsibility in a repo) would 
be one way to train them quicker.


Another way, which I already alluded to in my candidacy message, is to 
expand the pool of OpenStack users. One of my goals is to make OpenStack 
an attractive cloud platform to write applications against, and not 
merely somewhere to get a VM to run your application in. If we can 
achieve that we'll increase the market for OpenStack and hence the 
number of users and thus potential contributors. But those new users 
would be more motivated than anyone to find and fix bugs, and they're 
already developers so they'd be disproportionately more likely to 
contribute code in addition to documentation or bug reports (which are 
also important contributions).



The second group is those who are paid specifically to spend a portion 
of their time on upstream contribution, which brings us to...



Where else should we be looking for contributors?


Companies who are making money from OpenStack! It's their responsibility 
to maintain the commons and, collectively speaking at least, their 
problem if they don't.


For a start, we need to convince anybody who is maintaining a fork of 
OpenStack to do something more useful with their money. Like, for 
example, building it into a big pile and setting fire to it to keep warm.


Maybe education is something that can help here. For a lot of folks, 
OpenStack is their first direct contact with an open source community. 
If we could help them to learn why contributing is in their best 
interest, and how to do it effectively, then we could make some 
progress. It's pretty remarkable that there are Foundation board members 
still asking the TC to direct employees of other companies to work on 
the stuff they want them to for free.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Mohammed Naser]

On Mon, Apr 23, 2018 at 10:06 AM, Doug Hellmann  wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
>
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
>
> Which of those would you change, and how?
>
> Where else should we be looking for contributors?

I think that for the most part, the most vocal audience is the one
that contributes the most is
mostly very comfortable with the tools and processes that we have in
place today.  However,
I think we may have become 'blind' to the viewpoint of new
contributors and forgot some of
our habits might be very difficult pain points for other users.

## Communication

There is a significant amount of communication and work that happens
over IRC.  I'll admit,
it's one of my most preferable ways of communicating.  However, it's
not something that
is common for newer contributors to use.  Our developer manual lists
it before anything:

https://docs.openstack.org/infra/manual/developers.html#irc-account

There are a few other communities which are growing quickly and
they're using alternative
ways of communication.  I personally prefer  IRC, but maybe we should
put our preferences
aside and look at what's sustainable, because we have to be
progressive and move quickly.

Perhaps we should look into a OpenStack Slack community in combination
with an IRC
bridge?

 ## Tooling

The majority of long time OpenStack contributors are very comfortable
with the Gerrit
workflow.  They're also very comfortable with rebasing patches,
pushing them, setting
up dependencies, etc.

The newer developer might have some Gerrit experience but more than
likely, they might
probably have more of a GitHub workflow experience and that's the
easiest way that
the can submit code.

While my own preference is to use Gerrit, I think that perhaps looking
into opening up a
way for contributions via GitHub to be available could be an
interesting option.  Now, the
technical side of me can imagine all the challenges, but again, we
must keep things easy
and approachable.

If submitting a patch to the OpenStack community involves setting up
an account in the
Canonical "Ubuntu One" OpenID, creating a username in Gerrit
afterwards, sign the CLA,
which could get complicated depending on your organization, upload
your keys, setup
git-review before being able to push up a single patch (and then
there's Launchpad for
bugs and some projects are on Storyboard, etc)

That's a lot of extra work that we're putting on new potential
contributors.  I don't mind it,
but I think we have to collectively think about new potential
contributors rather than
our preferences.

I'm giving a lot of ideas that I might not have technical solutions in
place, but I think putting
them out might bring up some other ways that we can come to a
compromise and make it work
to make contributing to OpenStack easy.

>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Jeremy Stanley]

On 2018-04-23 16:28:13 + (+), Tim Bell wrote:
> One of the challenges in the academic sector is the time from
> lightbulb moment to code commit. Many of the academic resource
> opportunities are short term (e.g. PhDs, student projects,
> government funded projects) and there is a latency in current
> system to onboard, get the appropriate recognition in the
> community (such as by reviewing other changes) and then get the
> code committed. This is a particular problem for the larger
> projects where the patch is not in one of the project goal areas
> for that release.
[...]

Not to seem pessimistic (I'm not!) but I have hopes that with a
trend of decreasing full-time investment from companies
"productizing" OpenStack we'll see a corresponding decrease in
project velocity as well. I think that one of the primary scaling
challenges we have which translates to a negative experience for
casual contributors is the overall change volume in some of our
larger projects. We've optimized our processes for people who are
going to work on many things in parallel, so that the amount of time
any one of those things takes to land is less of a problem for their
effective personal throughput.

As the pace of development slows and the hype continues to cool,
this could at least partly self-correct. We'll be taking on changes
from users and other casual contributors out of necessity when
they're all we have. What we need to do is fill in the gaps in the
meantime and carefully manage the transition so that we increase
ease of contribution for them ahead of that curve rather than once
it's too late.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Matt Riedemann]

On 4/23/2018 1:24 PM, Jeremy Stanley wrote:

Some of us also urged existing leaders in various projects to record
videos encouraging contributors to get more involved by demystifying
processes like code review or bug triage. This could be as simple as
signing up for an available lightning talk slot at one of our
conferences and then performing what you consider to be mundane but
much-needed activities while narrating an explanation of what's
going on in your head. What we've failed to do, as far as I'm aware,
is aggregate links to these somewhere and promote that in ways that
the intended audience will find them.


This reminded me of something I linked into the nova contributor docs 
based on a presentation that stephenfin and bauzas gave in Sydney about 
bug triage:


https://docs.openstack.org/nova/latest/contributor/how-to-get-involved.html#how-to-do-great-bug-triage

Over time I've tried to link more and more relevant summit videos into 
the nova docs for things like Placement, Cells v2, and really anything 
that is specific to a domain of nova for new contributors.


We spend so much time working on these presentations that it's a shame 
when we don't actually link them back into our docs for people to find 
later when they are trying to learn.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Rico Lin]

2018-04-24 1:26 GMT+08:00 Doug Hellmann :
>
> Excerpts from Rico Lin's message of 2018-04-24 00:54:14 +0800:
> > ** What aspects of our policies or culture make contributing to
> > OpenStackmore difficult than contributing to other open source
projects?To
> > fully understand the map of OpenStack services is a huge challenge,
> > especially for new join developers. And for project teams, might not
>
> This is an interesting point that I haven't heard raised before.
> Typically the number of projects is used as an example of something
> that is confusing to users or deployers, but can you elaborate on
> how it is confusing to contributors?
Because in some cases, users provide contributors and when a user feature
jump in,
to clarify which projects to might be part of that feature will cause time
when they weren't in
OpenStack for long (as a contributor working on cross communities).
And usually,  when he/she send out an ML for such a cross-projects
usecase won't get much replied (really depends on teams).
For other cases, user rely on what developers' report to decides where they
should put resource on,
but developers just provides the first match (and seems usable) project he
can find in repositories.

>
> > provide new contributors guidelines to be quicker to become part of the
> > team. Finally, the format or WG/SIG/Team might confuse contributors.*
Which
>
> Do you mean because it isn't clear what sort of group to start in order
> to accomplish something?
exactly
>
> > of those would you change, and how?IMO to provides clear landscape will
> > help on give people better view on the whole map and might get the
better
> > idea on how to fit in their plan without spending too much time on
finding
> > where to contribute. Also, we need provides better ways to communicate
to
> > new contributors to at least make them feel welcome. Which maybe we can
try
> > to add in PTL/TC's (or other possible position) duty and to provide
better
> > guidelines to new join contributors who seems got no clue on what's the
> > project been working on or where the project needs help. Only people we
>
> What role do you think the First Contact SIG might play in that?

I think in this specific scenario, First Contact SIG can help define the
scope and suggest
the guideline. Because new developers always reach to SIG/project team
directly, and if it's
not working,  they might just try to work around issues and skip the
chances to join
OpenStack community.
>
> > really understand that project can provide such judgment, and it seems
like
> > a duty to provide guidelines to others (Aka help people working with
you).
> > Finally, I personally think it's a good idea to have SIG in OpenStack,
but
> > I think we need to provide technical guidelines to SIGs, so they can
make a
> > clear decision on what's their mission, where are the resources they can
> > use, and how they might be able to use it. A clear vision makes clear
> > actions.* Where else should we be looking for contributors?IMO we
actually
> > got a bunch new contributors around OpenStack (mostly for nova and
neutron
> > of course) and trying to figure out what they can/should do. Also
possibly
> > from other projects which might be doing overlapping jobs. Also to form
SIG
> > might be a more productive way to collect contributors.*
> >
> >
> >
> > May The Force of OpenStack Be With You,
> >
> > *Rico Lin*irc: ricolin
> >
> > 2018-04-23 22:06 GMT+08:00 Doug Hellmann :
> >
> > > [This is meant to be one of (I hope) several conversation-provoking
> > > questions directed at prospective TC members to help the community
> > > understand their positions before considering how to vote in the
> > > ongoing election.]
> > >
> > > Over the last year we have seen some contraction in the number of
> > > companies and individuals contributing to OpenStack. At the same
> > > time we have started seeing contributions from other companies and
> > > individuals. To some degree this contraction and shift in contributor
> > > base is a natural outcome of changes in OpenStack itself along with
> > > the rest of the technology industry, but as with any change it
> > > raises questions about how and whether we can ensure a smooth
> > > transition to a new steady state.
> > >
> > > What aspects of our policies or culture make contributing to OpenStack
> > > more difficult than contributing to other open source projects?
> > >
> > > Which of those would you change, and how?
> > >
> > > Where else should we be looking for contributors?
> > >
> > > Doug
> > >
> > >
__
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
>
> __
> OpenStack 

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Jeremy Stanley]

On 2018-04-23 13:18:22 -0400 (-0400), Doug Hellmann wrote:
[...]
> I would like for us to collect some more data about what efforts
> teams are making with encouraging new contributors, and what seems
> to be working or not. In the past we've done pretty well at finding
> new techniques by experimenting within one team and then adapting
> the results to scale them out to other teams.
> 
> Does anyone have any examples of things that we ought to be trying
> more of?

A while back (and I'm sorry I seem to be failing at finding the
right keywords to locate any of it) it was pointed out that the
Kolla team has a handbook for how to become a core reviewer for
their deliverables with a process that contributors interested in
getting more involved that way can follow. While perhaps not
necessarily applicable everywhere, and certainly would be extremely
team-specific, it sounded like an intriguing solution. I'd be
curious to follow up and find out whether that model has continued
to work out for them.

Some of us also urged existing leaders in various projects to record
videos encouraging contributors to get more involved by demystifying
processes like code review or bug triage. This could be as simple as
signing up for an available lightning talk slot at one of our
conferences and then performing what you consider to be mundane but
much-needed activities while narrating an explanation of what's
going on in your head. What we've failed to do, as far as I'm aware,
is aggregate links to these somewhere and promote that in ways that
the intended audience will find them.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2018-04-23 12:35:07 -0500:
> On 4/23/2018 12:18 PM, Doug Hellmann wrote:
> > I would like for us to collect some more data about what efforts
> > teams are making with encouraging new contributors, and what seems
> > to be working or not. In the past we've done pretty well at finding
> > new techniques by experimenting within one team and then adapting
> > the results to scale them out to other teams.
> > 
> > Does anyone have any examples of things that we ought to be trying more
> > of?
> 
> The nova team is now trying runways [1] for trying to focus reviews on 
> blueprints which are ready but otherwise don't get the focus from the 
> core team.
> 
> The certificate validation stuff in there for the John Hopkins team is a 
> prime example of how this is putting focus on something that has 
> otherwise been getting deferred since at least the Ocata summit.
> 
> [1] https://etherpad.openstack.org/p/nova-runways-rocky
> 

Great example. It sounds like it's helping, and I look forward to
hearing the retrospective at the end of the cycle.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Matt Riedemann]

On 4/23/2018 12:18 PM, Doug Hellmann wrote:

I would like for us to collect some more data about what efforts
teams are making with encouraging new contributors, and what seems
to be working or not. In the past we've done pretty well at finding
new techniques by experimenting within one team and then adapting
the results to scale them out to other teams.

Does anyone have any examples of things that we ought to be trying more
of?


The nova team is now trying runways [1] for trying to focus reviews on 
blueprints which are ready but otherwise don't get the focus from the 
core team.


The certificate validation stuff in there for the John Hopkins team is a 
prime example of how this is putting focus on something that has 
otherwise been getting deferred since at least the Ocata summit.


[1] https://etherpad.openstack.org/p/nova-runways-rocky

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Doug Hellmann]

Excerpts from Rico Lin's message of 2018-04-24 00:54:14 +0800:
> ** What aspects of our policies or culture make contributing to
> OpenStackmore difficult than contributing to other open source projects?To
> fully understand the map of OpenStack services is a huge challenge,
> especially for new join developers. And for project teams, might not

This is an interesting point that I haven't heard raised before.
Typically the number of projects is used as an example of something
that is confusing to users or deployers, but can you elaborate on
how it is confusing to contributors?

> provide new contributors guidelines to be quicker to become part of the
> team. Finally, the format or WG/SIG/Team might confuse contributors.* Which

Do you mean because it isn't clear what sort of group to start in order
to accomplish something?

> of those would you change, and how?IMO to provides clear landscape will
> help on give people better view on the whole map and might get the better
> idea on how to fit in their plan without spending too much time on finding
> where to contribute. Also, we need provides better ways to communicate to
> new contributors to at least make them feel welcome. Which maybe we can try
> to add in PTL/TC's (or other possible position) duty and to provide better
> guidelines to new join contributors who seems got no clue on what's the
> project been working on or where the project needs help. Only people we

What role do you think the First Contact SIG might play in that?

> really understand that project can provide such judgment, and it seems like
> a duty to provide guidelines to others (Aka help people working with you).
> Finally, I personally think it's a good idea to have SIG in OpenStack, but
> I think we need to provide technical guidelines to SIGs, so they can make a
> clear decision on what's their mission, where are the resources they can
> use, and how they might be able to use it. A clear vision makes clear
> actions.* Where else should we be looking for contributors?IMO we actually
> got a bunch new contributors around OpenStack (mostly for nova and neutron
> of course) and trying to figure out what they can/should do. Also possibly
> from other projects which might be doing overlapping jobs. Also to form SIG
> might be a more productive way to collect contributors.*
> 
> 
> 
> May The Force of OpenStack Be With You,
> 
> *Rico Lin*irc: ricolin
> 
> 2018-04-23 22:06 GMT+08:00 Doug Hellmann :
> 
> > [This is meant to be one of (I hope) several conversation-provoking
> > questions directed at prospective TC members to help the community
> > understand their positions before considering how to vote in the
> > ongoing election.]
> >
> > Over the last year we have seen some contraction in the number of
> > companies and individuals contributing to OpenStack. At the same
> > time we have started seeing contributions from other companies and
> > individuals. To some degree this contraction and shift in contributor
> > base is a natural outcome of changes in OpenStack itself along with
> > the rest of the technology industry, but as with any change it
> > raises questions about how and whether we can ensure a smooth
> > transition to a new steady state.
> >
> > What aspects of our policies or culture make contributing to OpenStack
> > more difficult than contributing to other open source projects?
> >
> > Which of those would you change, and how?
> >
> > Where else should we be looking for contributors?
> >
> > Doug
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Doug Hellmann]

Excerpts from Chris Dent's message of 2018-04-23 17:50:31 +0100:
> On Mon, 23 Apr 2018, Tim Bell wrote:
> 
> > One of the challenges in the academic sector is the time from
> > lightbulb moment to code commit. Many of the academic resource
> > opportunities are short term (e.g. PhDs, student projects,
> > government funded projects) and there is a latency in current
> > system to onboard, get the appropriate recognition in the
> > community (such as by reviewing other changes) and then get the
> > code committed.  This is a particular problem for the larger
> > projects where the patch is not in one of the project goal areas
> > for that release.
> 
> This. Many times over this.
> 
> The latency that a casual contributor may experience when
> interacting with one of the larger OpenStack projects is
> discouraging and a significant impedance mismatch for the
> contributor.
> 
> One thing that might help is what I implied in one of my responses
> elsewhere in Doug's collection of questions: Professional OpenStack
> developers could be oriented towards enabling and attending to
> casual contributors more than addressing feature development. This
> is a large shift in how OpenStack is done, but makes sense in a
> world where we are trying to maintain an existing and fairly mature
> thing: We need maintainers.

I would like for us to collect some more data about what efforts
teams are making with encouraging new contributors, and what seems
to be working or not. In the past we've done pretty well at finding
new techniques by experimenting within one team and then adapting
the results to scale them out to other teams.

Does anyone have any examples of things that we ought to be trying more
of?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Rico Lin]

** What aspects of our policies or culture make contributing to
OpenStackmore difficult than contributing to other open source projects?To
fully understand the map of OpenStack services is a huge challenge,
especially for new join developers. And for project teams, might not
provide new contributors guidelines to be quicker to become part of the
team. Finally, the format or WG/SIG/Team might confuse contributors.* Which
of those would you change, and how?IMO to provides clear landscape will
help on give people better view on the whole map and might get the better
idea on how to fit in their plan without spending too much time on finding
where to contribute. Also, we need provides better ways to communicate to
new contributors to at least make them feel welcome. Which maybe we can try
to add in PTL/TC's (or other possible position) duty and to provide better
guidelines to new join contributors who seems got no clue on what's the
project been working on or where the project needs help. Only people we
really understand that project can provide such judgment, and it seems like
a duty to provide guidelines to others (Aka help people working with you).
Finally, I personally think it's a good idea to have SIG in OpenStack, but
I think we need to provide technical guidelines to SIGs, so they can make a
clear decision on what's their mission, where are the resources they can
use, and how they might be able to use it. A clear vision makes clear
actions.* Where else should we be looking for contributors?IMO we actually
got a bunch new contributors around OpenStack (mostly for nova and neutron
of course) and trying to figure out what they can/should do. Also possibly
from other projects which might be doing overlapping jobs. Also to form SIG
might be a more productive way to collect contributors.*



May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin



2018-04-23 22:06 GMT+08:00 Doug Hellmann :

> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
>
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
>
> Which of those would you change, and how?
>
> Where else should we be looking for contributors?
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Chris Dent]

On Mon, 23 Apr 2018, Tim Bell wrote:


One of the challenges in the academic sector is the time from
lightbulb moment to code commit. Many of the academic resource
opportunities are short term (e.g. PhDs, student projects,
government funded projects) and there is a latency in current
system to onboard, get the appropriate recognition in the
community (such as by reviewing other changes) and then get the
code committed.  This is a particular problem for the larger
projects where the patch is not in one of the project goal areas
for that release.


This. Many times over this.

The latency that a casual contributor may experience when
interacting with one of the larger OpenStack projects is
discouraging and a significant impedance mismatch for the
contributor.

One thing that might help is what I implied in one of my responses
elsewhere in Doug's collection of questions: Professional OpenStack
developers could be oriented towards enabling and attending to
casual contributors more than addressing feature development. This
is a large shift in how OpenStack is done, but makes sense in a
world where we are trying to maintain an existing and fairly mature
thing: We need maintainers.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Chris Dent]

On Mon, 23 Apr 2018, Doug Hellmann wrote:


What aspects of our policies or culture make contributing to OpenStack
more difficult than contributing to other open source projects?


Size, isolation, and perfectionism.

Size in at least three dimensions:

* the entire community
* individual projects in terms of humans and scope
* individual projects in terms of lines of code (per repo and per
  file)

Isolation in at least two dimensions:

* For someone who is not "of OpenStack", OpenStack is kind of "over
  there, doing its own thing". Non-OpenStack colleagues wonder about
  the tempestuous teapot I'm in.

* Individual members of project teams sometimes self-identify as
  members of that that team, not of OpenStack.

Perfectionism:

* In at least some teams project teams (see, look at me
  identifying and isolating project teams) proposed specs and code
  can be nitpicked to death and forward progress delayed while every
  edge case is considered. We should strive to iterate more.

* At the same time there is too strong and attachment to master
  needing to be perfect. A bug on master is an invitation addressed
  to a potential new contributor.


Which of those would you change, and how?


I think we've started making a more conscious effort on all three of
these areas. We talk more often about incomplete bug fixes being
adopted experienced contributors. Decomposing repositories to harden
contractual and social boundaries is increasingly common. Actively
working with other communities (notably Kubernetes) is on the rise.

But there is plenty more to do in each of these areas.


Where else should we be looking for contributors?


I agree with Thierry that academia is a good place to look and that
we made a mistake when we highlighted and enforced an artificial
boundary between developers and operators. Ideally many features and
bug fixes would come from people who _use_ OpenStack as their day
job. The people who think of _developing_ OpenStack as their day job
should be most focused on enabling those other people and cleaning
up and refining what already exists.

I also think that we need to figure out, if possible, some way to
make OpenStack relevant and interesting to individuals who are
technically curious enough to want to try playing with their own
mini cloud at home. If we can make OpenStack accessible to amateurs
(not amateurish!) there's a big world of good input to come.
Something as one stop, integrated in the documentation and official
seeming as minikube is for Kubernetes.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Tim Bell]

One of the challenges in the academic sector is the time from lightbulb moment 
to code commit. Many of the academic resource opportunities are short term 
(e.g. PhDs, student projects, government funded projects) and there is a 
latency in current system to onboard, get the appropriate recognition in the 
community (such as by reviewing other changes) and then get the code committed. 
 This is a particular problem for the larger projects where the patch is not in 
one of the project goal areas for that release.

Not sure what the solution is but I would agree that there is a significant 
opportunity.

Tim

-Original Message-
From: Thierry Carrez <thie...@openstack.org>
Organization: OpenStack
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Monday, 23 April 2018 at 18:11
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc] campaign question: How can we make 
contributing to OpenStack easier?

> Where else should we be looking for contributors?

Like other large open source projects, OpenStack has a lot of visibility
in the academic sector. I feel like we are less successful than others
in attracting contributions from there, and we could do a lot better by
engaging with them more directly.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Thierry Carrez]

Doug Hellmann wrote:
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
> 
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
> 
> Which of those would you change, and how?

Our focus for the past 7 years was on handling the enormous growth of
the OpenStack project. If you asked me in 2010 how many total code
contributors we'd have by 2018, my answer would probably have been
closer to 700 than to 7000. We've built systems and processes to sustain
that growth, and we were very successful at it.

The issue is that systems and processes designed to sustain times of
inflation do not work so well in a deflation period, or even a
stagnation period. It's urgent now to have a critical look at them, see
what is useful and what is a scale optimization we could do away with.

Our largest reserve of potential contributors lies in the vast number of
users we have. In my opinion, one of the mistakes we made was to create
an "operators" community separate from the "developers" community,
almost in reaction to it. That makes it more difficult to smoothly
transition users into contributors and ultimately into code
contributions. Melvin and I have been busy over the past two cycles
fixing that in various ways, but there is still a lot of work to do.

> Where else should we be looking for contributors?

Like other large open source projects, OpenStack has a lot of visibility
in the academic sector. I feel like we are less successful than others
in attracting contributions from there, and we could do a lot better by
engaging with them more directly.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Graham Hayes]

On 23/04/18 15:06, Doug Hellmann wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
> 
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
> 
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?

Our scale.

To get a large feature merged can require get code
prioritised by 2 or 3 different teams, and merged into any number of
repositories.

To get a small feature merged on some projects can take some time as
well, purely from the amount of code that is submitted for review to
these projects.

> Which of those would you change, and how?

Well, I definitely wouldn't change our scale. What I think we need to is
start breaking down some of the gigantic mono repos we have, so that
reviewing a small feature does not need large amounts of contextual
knowledge. I think this is happening organically in some teams already
with a few teams completely plugin based and distributed (like the docs
team).

When code can be reviewed in isolation without the fear of breaking
something 2 projects away, it helps both review time, and new
contributor experience.

> Where else should we be looking for contributors?

Honestly, I don't know. The kind of work that our contributors do, does
require a certain level of equipment, and "upstream time" that makes any
serious feature development hard for a casual weekend contributor.

> Doug
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Zhipeng Huang]

Culture wise, being too IRC-centric is definitely not helping, from my own
experience getting new Cyborg developer joining our weekly meeting from
China. Well we could always argue it is part of a open source/hacker
culture and preferable to commercial solutions that have the constant risk
of suddenly being shut down someday. But as OpenStack becomes more
commercialized and widely adopted, we should be aware that more and more
(potential) contributors will come from the groups who are used to
non-strictly open source environment, such as product develop team which
relies on a lot of "closed source" but easy to use softwares.

The change ? Use more video conferences, and more commercial tools that
preferred in certain region. Stop being allergic to non-open source
softwares and bring more capable but not hacker culture inclined
contributors to the community.

I know this is not a super welcomed stance in the open source hacker
culture. But if we want OpenStack to be able to sustain more developers and
not have a mid-life crisis then got fringed, we need to start changing the
hacker mindset.

Another important thing, as I stated in the previous email, is that
OpenStack should keep explore new technology directions and TC should take
the lead position on it. No matter how good we could facilitate the
contributors, a stale community cannot win more contributors. I'm against
hype like any other, but reluctant or lazy on innovation is another thing
and will cost the community to lose more and more existing and potential
contributors.



On Mon, Apr 23, 2018 at 10:06 PM, Doug Hellmann 
wrote:

> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
>
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
>
> Which of those would you change, and how?
>
> Where else should we be looking for contributors?
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Doug Hellmann]

[This is meant to be one of (I hope) several conversation-provoking
questions directed at prospective TC members to help the community
understand their positions before considering how to vote in the
ongoing election.]

Over the last year we have seen some contraction in the number of
companies and individuals contributing to OpenStack. At the same
time we have started seeing contributions from other companies and
individuals. To some degree this contraction and shift in contributor
base is a natural outcome of changes in OpenStack itself along with
the rest of the technology industry, but as with any change it
raises questions about how and whether we can ensure a smooth
transition to a new steady state.

What aspects of our policies or culture make contributing to OpenStack
more difficult than contributing to other open source projects?

Which of those would you change, and how?

Where else should we be looking for contributors?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev