Re: [openstack-dev] [election] [tc] TC Candidacy

[Kristi Nikolla]

Thanks for the question Matt,

I have to agree that that is not a good use of time, which is why I’m really 
interested in the Constellations initiative. There doesn’t have to be a very 
specifically defined “what OpenStack is” answer, but instead we can focus on 
multiple answers based on the features we offer and the multitude of problems 
that we solve. Furthermore, I think that constellations will help weaken the 
silos between teams by increasing cross-project collaboration and integration 
towards a common goal. Ultimately, to me, what OpenStack is, first and 
foremost, is a community.

Additionally, I would like to be much more involved with the process of 
welcoming and mentoring new contributors, and the various groups formed around 
that. Working in academia, gives me access to a large pool of students, 
especially during the cloud computing course that we offer in two universities 
of the Boston area. Many of our previous alums (me included) end up becoming 
regular contributors and continuing their work in OpenStack and other open 
source communities.

Ultimately, this list isn’t exclusive and I’d love to hear your and other 
people's opinions about what you think the I should focus on.

Kristi Nikolla

> On Sep 7, 2018, at 7:26 AM, Matt Riedemann  wrote:
> 
> On 9/5/2018 1:20 PM, Kristi Nikolla wrote:
>> I’m really excited to have the opportunity to take part in the discussion 
>> with
>> regards to the technical vision for OpenStack. Regardless of election 
>> outcome,
>> this is the first step towards a larger involvement from me in the important
>> discussions (no more shying away from the important mailing list threads.)
> 
> I'm not trying to pick on you Kristi, but personally I'm tired of the TC 
> vision question that's been going on for years now and would like the people 
> I vote for to spend less time talking about OpenStack and what it is or what 
> it isn't (because that changes based on the person you talk to and on what 
> day you ask them), and spend more time figuring out how to move cross-project 
> initiatives forward. So whether or not OpenStack is a toolkit for 
> private/public/edge clouds, or a product, or something else, there are likely 
> common themes within OpenStack that we can generally agree on across projects 
> and need people to work on them, rather than just talk about doing them. Are 
> there specific cross-project initiatives you are interested in working on?
> 
> -- 
> 
> 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


__
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] [election] [tc] TC candidacy

[Ben Nemec]

On 09/07/2018 11:19 AM, Samuel Cassiba wrote:

On Fri, Sep 7, 2018 at 8:55 AM, Samuel Cassiba  wrote:

On Fri, Sep 7, 2018 at 6:22 AM, Matt Riedemann  wrote:

On 9/5/2018 2:49 PM, Samuel Cassiba wrote:


Though my hands-on experience goes back several releases, I still view
things from the outside-looking-in perspective. Having the outsider
lens is crucial in the long-term for any consensus-driven group,
regardless of that consensus.

Regardless of the election outcome, this is me taking steps to having a
larger involvement in the overall conversations that drive so much of
our daily lives. At the end of the day, we're all just groups of people
trying to do our jobs. I view this as an opportunity to give back to a
community that has given me so much.



Are there specific initiatives you plan on pushing forward if on the TC? I'm
thinking about stuff from the laundry list here:

https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Other_Initiatives



Excellent question!

It's not in my nature to push specific agendas. That said, being in
the deploy space, constellations is something that does have a
specific gravity that would, no doubt, draw me in, whether or not I am
part of the TC. I've viewed projects in the deploy space, such aq

Furthering the adoption of secret management is another thing that
hits close to home


...and that would be where an unintended keyboard-seeking Odin attack
preemptively initiates a half-thought thought. It's hard to get upset
at this face, though. https://i.imgur.com/c7tktmO.jpg

To that point, projects like Chef have made use of encrypted secrets
since more or less the dawn of time, but not at all in a portable way.
Continuing the work to bring secrets under a single focus is something
that I would also be a part of, with or without being on the TC.


Just want to note that there is work underway in Oslo to address this. 
The base framework for it merged in Rocky and we plan to have 
integration with Castellan in Stein.


https://review.openstack.org/#/c/474304/



In both of these efforts, I envision having some manner of involvement
no matter what. At the strategic level, working to ensure the
disparate efforts are in alignment is where I would gravitate to.

Best,
Samuel

__
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] [election] [tc] TC candidacy

[Samuel Cassiba]

On Fri, Sep 7, 2018 at 8:55 AM, Samuel Cassiba  wrote:
> On Fri, Sep 7, 2018 at 6:22 AM, Matt Riedemann  wrote:
>> On 9/5/2018 2:49 PM, Samuel Cassiba wrote:
>>>
>>> Though my hands-on experience goes back several releases, I still view
>>> things from the outside-looking-in perspective. Having the outsider
>>> lens is crucial in the long-term for any consensus-driven group,
>>> regardless of that consensus.
>>>
>>> Regardless of the election outcome, this is me taking steps to having a
>>> larger involvement in the overall conversations that drive so much of
>>> our daily lives. At the end of the day, we're all just groups of people
>>> trying to do our jobs. I view this as an opportunity to give back to a
>>> community that has given me so much.
>>
>>
>> Are there specific initiatives you plan on pushing forward if on the TC? I'm
>> thinking about stuff from the laundry list here:
>>
>> https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Other_Initiatives
>>
>
> Excellent question!
>
> It's not in my nature to push specific agendas. That said, being in
> the deploy space, constellations is something that does have a
> specific gravity that would, no doubt, draw me in, whether or not I am
> part of the TC. I've viewed projects in the deploy space, such aq
>
> Furthering the adoption of secret management is another thing that
> hits close to home

...and that would be where an unintended keyboard-seeking Odin attack
preemptively initiates a half-thought thought. It's hard to get upset
at this face, though. https://i.imgur.com/c7tktmO.jpg

To that point, projects like Chef have made use of encrypted secrets
since more or less the dawn of time, but not at all in a portable way.
Continuing the work to bring secrets under a single focus is something
that I would also be a part of, with or without being on the TC.

In both of these efforts, I envision having some manner of involvement
no matter what. At the strategic level, working to ensure the
disparate efforts are in alignment is where I would gravitate to.

Best,
Samuel

__
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] [election] [tc] TC candidacy

[Samuel Cassiba]

On Fri, Sep 7, 2018 at 6:22 AM, Matt Riedemann  wrote:
> On 9/5/2018 2:49 PM, Samuel Cassiba wrote:
>>
>> Though my hands-on experience goes back several releases, I still view
>> things from the outside-looking-in perspective. Having the outsider
>> lens is crucial in the long-term for any consensus-driven group,
>> regardless of that consensus.
>>
>> Regardless of the election outcome, this is me taking steps to having a
>> larger involvement in the overall conversations that drive so much of
>> our daily lives. At the end of the day, we're all just groups of people
>> trying to do our jobs. I view this as an opportunity to give back to a
>> community that has given me so much.
>
>
> Are there specific initiatives you plan on pushing forward if on the TC? I'm
> thinking about stuff from the laundry list here:
>
> https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Other_Initiatives
>

Excellent question!

It's not in my nature to push specific agendas. That said, being in
the deploy space, constellations is something that does have a
specific gravity that would, no doubt, draw me in, whether or not I am
part of the TC. I've viewed projects in the deploy space, such aq

Furthering the adoption of secret management is another thing that
hits close to home

__
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] [election] [tc] TC candidacy

[Zhipeng Huang]

Well nova-cyborg is surely on the top-priority for OpenStack cross-project
collaboration. The two initiatives I mentioned is more in the field of
cross-community.

I think I didn't elaborate on how the TC role fit in this picture. For TC I
think it is important to be able to help on the cross community
collaboration, one community is intimidating enough, let alone venture into
totally different communities.

With that said, other than the two directions that I will personally
involve myself with, I will also help other cross community
ideas/initiatives to build relationship and get work done. I guess it is
more convincing when you as a TC member have actually skin in the game in
cross-community development.

So yes individual team will probably the best ones to drive such
collaborations, but it would also be nice to have TC lend a hand when there
is need :)

On Fri, Sep 7, 2018 at 10:17 PM Matt Riedemann  wrote:

> On 9/7/2018 8:54 AM, Zhipeng Huang wrote:
> > One is related to the cyborg project where the team is working to build
> > the open heterogenous resource mgmt platform. I would like to extend
> > this mission over to kubernetes, which currently lack of such component
> > and could benefit hugely from our work here in OpenStack. There are also
> > other communities like OPNFV where the edge cloud project, the C-RAN
> > project and Rocket project will be integrating and testing cyborg, as
> > well as ONNX where AI models will meet the resource models we defined in
> > Cyborg for NPUs and GPUs and FPGAs and whatever hardware should be
> chosen.
>
> I'd like to actually see some progress made on cyborg/nova integration
> before we get our hopes up about cyborg/something completely outside of
> openstack integration, but that's my biased view on it from being a nova
> person. See [1] for context from a discussion yesterday. I don't really
> know how the TC drives this more than the cyborg team themselves, but OK.
>
> [1]
>
> http://eavesdrop.openstack.org/meetings/nova/2018/nova.2018-09-06-14.00.log.html#l-120
>
> --
>
> 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
>


-- 
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] [election] [tc] TC candidacy

[Matt Riedemann]

On 9/7/2018 8:54 AM, Zhipeng Huang wrote:
One is related to the cyborg project where the team is working to build 
the open heterogenous resource mgmt platform. I would like to extend 
this mission over to kubernetes, which currently lack of such component 
and could benefit hugely from our work here in OpenStack. There are also 
other communities like OPNFV where the edge cloud project, the C-RAN 
project and Rocket project will be integrating and testing cyborg, as 
well as ONNX where AI models will meet the resource models we defined in 
Cyborg for NPUs and GPUs and FPGAs and whatever hardware should be chosen.


I'd like to actually see some progress made on cyborg/nova integration 
before we get our hopes up about cyborg/something completely outside of 
openstack integration, but that's my biased view on it from being a nova 
person. See [1] for context from a discussion yesterday. I don't really 
know how the TC drives this more than the cyborg team themselves, but OK.


[1] 
http://eavesdrop.openstack.org/meetings/nova/2018/nova.2018-09-06-14.00.log.html#l-120


--

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] [election] [tc] TC candidacy

[Zhipeng Huang]

Thx Matt,

I think as I described in the candidacy patch, there two specific areas
that I would like to do the cross-community collaboration.

One is related to the cyborg project where the team is working to build the
open heterogenous resource mgmt platform. I would like to extend this
mission over to kubernetes, which currently lack of such component and
could benefit hugely from our work here in OpenStack. There are also other
communities like OPNFV where the edge cloud project, the C-RAN project and
Rocket project will be integrating and testing cyborg, as well as ONNX
where AI models will meet the resource models we defined in Cyborg for NPUs
and GPUs and FPGAs and whatever hardware should be chosen.

The other one is policy which related to the Kubernetes Policy WG I'm
leading and the CNCF Security WG which is under voting from ToC to take
shape. We have great policy in code implementation in Keystone and I'm keen
on investigating on how should that impact Kubernetes or Istio or SPIFEE
when we stack them up.

Of course there are other areas that i'm also working on which bridges
communities, one such example is the cloud ledger idea proposed for public
cloud wg involves collaboration with Ethereum Classic community, and
hopefully Hyperledger and others in the near future. However this is a long
term effort compared to the above mentioned two aspects.

Hope that answers the question :)

On Fri, Sep 7, 2018 at 9:34 PM Matt Riedemann  wrote:

> On 9/5/2018 6:49 PM, Zhipeng Huang wrote:
> > I found that most of my statement for my last ran is still valid today
> > [0][1]. I want to build strong cross-community collaboration, best
> > practices for project level governance and more innovations for
> OpenStack.
>
> As I asked Rico, are there specific cross-community initiatives or
> deliverables you plan on working on, or just having open dialog? Because
> the latter doesn't mean much to me personally. If the former, can you
> point some out?
>
> --
>
> 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
>


-- 
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] [election] [tc] TC candidacy

[Matt Riedemann]

On 9/5/2018 6:49 PM, Zhipeng Huang wrote:
I found that most of my statement for my last ran is still valid today 
[0][1]. I want to build strong cross-community collaboration, best 
practices for project level governance and more innovations for OpenStack.


As I asked Rico, are there specific cross-community initiatives or 
deliverables you plan on working on, or just having open dialog? Because 
the latter doesn't mean much to me personally. If the former, can you 
point some out?


--

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] [election] [tc] TC Candidacy

[Matt Riedemann]

On 9/5/2018 1:20 PM, Kristi Nikolla wrote:

I’m really excited to have the opportunity to take part in the discussion with
regards to the technical vision for OpenStack. Regardless of election outcome,
this is the first step towards a larger involvement from me in the important
discussions (no more shying away from the important mailing list threads.)


I'm not trying to pick on you Kristi, but personally I'm tired of the TC 
vision question that's been going on for years now and would like the 
people I vote for to spend less time talking about OpenStack and what it 
is or what it isn't (because that changes based on the person you talk 
to and on what day you ask them), and spend more time figuring out how 
to move cross-project initiatives forward. So whether or not OpenStack 
is a toolkit for private/public/edge clouds, or a product, or something 
else, there are likely common themes within OpenStack that we can 
generally agree on across projects and need people to work on them, 
rather than just talk about doing them. Are there specific cross-project 
initiatives you are interested in working on?


--

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] [election] [tc] TC candidacy

[Matt Riedemann]

On 9/5/2018 2:49 PM, Samuel Cassiba wrote:

Though my hands-on experience goes back several releases, I still view
things from the outside-looking-in perspective. Having the outsider
lens is crucial in the long-term for any consensus-driven group,
regardless of that consensus.

Regardless of the election outcome, this is me taking steps to having a
larger involvement in the overall conversations that drive so much of
our daily lives. At the end of the day, we're all just groups of people
trying to do our jobs. I view this as an opportunity to give back to a
community that has given me so much.


Are there specific initiatives you plan on pushing forward if on the TC? 
I'm thinking about stuff from the laundry list here:


https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Other_Initiatives

--

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] [election][tc] TC Candidacy

[Matt Riedemann]

On 9/6/2018 2:59 AM, Ghanshyam Mann wrote:

* Share Project teams work for Common Goals:  Every cycle we have TC goals and 
some future direction where all the projects needs to start working. Projects 
try to do their best in that but big challenge for them is resource bandwidth. 
In Current situation, It is very hard for projects teams to accommodate those 
work by themselves. Project team are shrinking and key members are overloaded. 
My Idea is to form a temporary team of contributors under Goal champion and 
finish those common area work during starting of cycle (so that we can make 
sure to finish the work well on time and test throughout the cycle). That 
temporary team can be formed with volunteers from any project team or new part 
time contributors with help of OUI or FirstContact SIG etc.


This is a good idea and something I personally would like to see the TC 
doing to move actual positive technical changes forward across OpenStack.


--

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

[openstack-dev] [election][tc] TC Candidacy

[Ghanshyam Mann]

Hi All,

I’d like to announce my candidacy for OpenStack Technical Committee position. 

I am glad to work in OpenStack community and would like to thank all the 
contributors/leaders who supported me to explore new things which brings out my 
best for the community.

Let me introduce myself, briefly. I have joined the OpenStack community since 
2012 as operator and started as full time upstream contributor since 2014 
during mid of Ice-House release. Currently, I am PTL for the QA Program since 
the Rocky cycle and active contributor in QA projects and Nova. Also I have 
been randomly contributing in many other projects specially on Tempest plugins 
for bug fix and tempest compatibility changes. 
Along with that, I am actively involved in programs helping new contributors in 
OpenStack. 1. As mentor in the Upstream Institute Training since Barcelona 
Summit (Oct 2016)[1] 2. FirstContact SIG [2] to help new contributors to 
onboard in OpenStack. It's always a great experience to introduce OpenStack 
upstream workflow to new contributors and encourage them to start contribution. 
I feel that is very much needed in OpenStack because of current movement of 
experience contributors. 

TC direction has always been valuable and result oriented in technical debt or 
efforts towards Diversity of community. This kind of work/position never been 
easy task specially in such a big community like OpenStack. By observing the TC 
work from past couple of years, I am very much motivated to help in this 
direction in order to contribute more towards cross projects and collaboration 
among projects or people.   

Below are the areas I would like to Focus as TC:

* Share Project teams work for Common Goals:  Every cycle we have TC goals and 
some future direction where all the projects needs to start working. Projects 
try to do their best in that but big challenge for them is resource bandwidth. 
In Current situation, It is very hard for projects teams to accommodate those 
work by themselves. Project team are shrinking and key members are overloaded. 
My Idea is to form a temporary team of contributors under Goal champion and 
finish those common area work during starting of cycle (so that we can make 
sure to finish the work well on time and test throughout the cycle). That 
temporary team can be formed with volunteers from any project team or new part 
time contributors with help of OUI or FirstContact SIG etc. 
 
* Cross-project and cross-community testing: I would like to work more on 
collaboration of testing effort across projects and community. We have plugins 
approach for testing in OpenStack and I agree that which is not perfect at this 
stage. I would like to work on more collaboration and guidelines to improve 
that area.  From QA team point of view, I would like QA team to do more 
collaborative work for all the projects for their proper testing.  And further, 
extend the testing collaboration among adjacent communities. 

* Encourage new leaders:  new contributors and so new leaders are much required 
in community. Some internal or external leadership program etc can be very 
helpful.  

Regardless of the results of this election I will work hard towards above 
directions and help community at my best. 

Thank you for your reading and consideration.

- Ghanshyam Mann (gmann)

* Review:  
http://stackalytics.com/?release=all=marks_id=ghanshyammann_type=all
 
* Commit:   
http://stackalytics.com/?release=all=commits_id=ghanshyammann_type=all
 
* Foundation Profile: https://www.openstack.org/community/members/profile/6461 
* Website: https://ghanshyammann.com 
* IRC (Freenode): gmann

[1] https://wiki.openstack.org/wiki/OpenStack_Upstream_Institute_Occasions 
  https://wiki.openstack.org/wiki/OpenStack_Upstream_Institute 
[2] https://wiki.openstack.org/wiki/First_Contact_SIG 






__
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] [election][tc] TC Candidacy

[Tony Breeds]

On Thu, Sep 06, 2018 at 09:24:39AM +1000, Tony Breeds wrote:

> Hi JP,
>I don't see a review in openstack/election from you.  Are you able to
> upload one befoer the deadline?
> 
> Please see: 
> https://governance.openstack.org/election/#how-to-submit-a-candidacy
> for more information.

I really should have checked my email for merged changes before
sending this sorry all.  

Yours Tony.


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

[openstack-dev] [election] [tc] TC candidacy

[Zhipeng Huang]

Hi all,

I ran for TC in the last cycle and I guess you can find out more
information on the candidacy patch [0], so I won't copy and paste that long
article here again :)

I found that most of my statement for my last ran is still valid today
[0][1]. I want to build strong cross-community collaboration, best
practices for project level governance and more innovations for OpenStack.

Hopefully second time is a charm and I could bring something fresh and
diverse thinking to the group :)

[0] https://review.openstack.org/#/c/600279/
[1] https://hannibalhuang.github.io/2018/04/16/i-didn't-build-it/
-- 
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] [election][tc] TC Candidacy

[Tony Breeds]

On Wed, Sep 05, 2018 at 01:04:09PM +0200, jean-phili...@evrard.me wrote:
> Hello everyone,
> 
> I am hereby announcing my candidacy for a position on the OpenStack Technical 
> Committee (TC).

Hi JP,
   I don't see a review in openstack/election from you.  Are you able to
upload one befoer the deadline?

Please see: https://governance.openstack.org/election/#how-to-submit-a-candidacy
for more information.

Yours Tony.


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

[openstack-dev] [election] [tc] TC candidacy

[Samuel Cassiba]

Hello everybody,

I am announcing my candidacy to be a member of the OpenStack Technical
Committee (TC).

I have been involved in open source since I was a brash youth on the
Internet in the late 1990s, which amounts to over half my life at this
point. I am a self-taught individual, cutting my teeth on BSDs of the
period. I operated in that area for a number of years, becoming a
'shadow' maintainer under various pseudonyms. As time progressed, I
became comfortable attributing my work to my personal identity. o/

My direct involvement with OpenStack began during the Folsom release, as
an operator and deployer. I focused my efforts on automation, eventually
falling in with a crowd that likes puns and cooking references. In my
professional life, I have served as developer, operator, user, and
architect, which extends back to the birthplace of OpenStack.

I am a founding member of Chef OpenStack[0], where I have dutifully
served as PTL for five releases. My community involvement also extends
outside the OpenStack ecosystem, where I serve as a member of Sous
Chefs[1], a group dedicated to the long-term care of critical Chef
community resources.

Though my hands-on experience goes back several releases, I still view
things from the outside-looking-in perspective. Having the outsider
lens is crucial in the long-term for any consensus-driven group,
regardless of that consensus.

Regardless of the election outcome, this is me taking steps to having a
larger involvement in the overall conversations that drive so much of
our daily lives. At the end of the day, we're all just groups of people
trying to do our jobs. I view this as an opportunity to give back to a
community that has given me so much.

Thank you for your attention and consideration,
Samuel Cassiba (scas)

[0] https://docs.openstack.org/openstack-chef/latest/
[1] https://sous-chefs.org/

__
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] [election] [tc] TC Candidacy

[Kristi Nikolla]

Hi all,

I’m stepping out of the comfort zone and submitting my candidacy for a seat on
the OpenStack Technical Committee.

I’m a software architect at the Mass Open Cloud[0], a collaboration between
the five major universities of the Boston area to create and operate a
public cloud based on the Open Cloud eXchange model[1]. I’ve been involved
with OpenStack for the past three years as a user, operator and developer.
My main area of focus is in identity and federation. I’m a core reviewer for
the Keystone project and the lead for MixMatch[2][3][4], which aims to enable
resource federation among multiple OpenStack deployments.

I believe my affiliation with academia and research will bring a different
voice to the technical committee from a mostly underrepresented group.
Furthermore, my experience with federation and operating a cloud with a
diverse set of offerings not limited to OpenStack, but including other
important pieces of a cloud provider’s toolbox will prove really valuable,
especially with the vision dilemmas that OpenStack is facing today.

I’m really excited to have the opportunity to take part in the discussion with
regards to the technical vision for OpenStack. Regardless of election outcome,
this is the first step towards a larger involvement from me in the important
discussions (no more shying away from the important mailing list threads.)

I have a lot yet to learn, and consider it a big privilege to be surrounded by
so many kind people who have mentored me and continue to mentor me while I
walk and stumble. I strongly believe in servant leadership, and I will devote
myself in helping the community and mentoring the next wave of OpenStack
contributors. I have found OpenStack to be one of the most welcoming online
communities, and am very proud to be a part of this big family and for a
chance to give back.

Thank you for your time and attention,
Kristi Nikolla (knikolla)

[0]. https://massopen.cloud
[1]. http://www.cs.bu.edu/fac/best/res/papers/ic14.pdf
[2]. https://mixmatch.readthedocs.io
[3]. https://github.com/openstack/mixmatch
[4]. https://youtu.be/O0euqskJJ_8



signature.asc
Description: Message signed with OpenPGP
__
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] [election][tc] TC Candidacy

[jean-philippe]

Hello everyone,

I am hereby announcing my candidacy for a position on the OpenStack Technical 
Committee (TC).

I believe that Open Source software is not only about code, but also a way to 
bring
people together in order to find a solution to business problems.

Many people find me an easy person to talk with, due to my open mindset and my 
"facilitator"
spirit.

Those qualities helped me build solutions in the past. I hope they will be 
helpful to the TC: While OpenStack is becoming more mature everyday, it is 
facing (and will face)
new challenges in terms of community, or identity.

I have been following the OpenStack ecosystem since Kilo.
I went through multiple companies and multiple hats (A cloud end-user, an 
OpenStack advocate in meetups
and at FOSDEM, a product owner of the cloud strategy, architect of a community 
cloud, a deployer,
a developer, a team lead), which gives me a unique view on OpenStack and other
adjacent communities. I am now working full time on OpenStack for SUSE,
focusing on deployment tooling.

That growing involvement inspires me to be a TC candidate. I would like to help 
shape what
the future of OpenStack could be.

Even if my experience spans quite a few cycles, I consider myself as an
OpenStack newcomer. I like to see things with fresh eyes, and I do not hesitate 
to question
the status quo. It usually gives me a different perspective to explore new 
conversations
or find new solutions.

I also think this freshness makes me very approachable to new community members,
new users, or external communities. Listening to those inputs is very important 
to me:
good software can only exist with proper requirements!

I would like to focus my time at the TC with a general simplification of 
OpenStack.
Simplification would first *reduce the barrier of entry for new contributors*,
make community goals more easily reachable, and help connecting adjacent
communities. In this matter, I consider the technical 'python3-first' project 
will open
the door to many positive improvements and simplifications, but setting up a 
good
knowledge transfer platform and best practices/recommendations for projects
could be a positive improvement.

Talking about best practices and simplification, I would like to help PTLs at
their duties, as I consider TC members should be more supportive of the day to 
day
work of the PTL and projects. I would love to see the TC as provider of 
toolkits helping
maintain and grow the community of each of the official projects.
These could be the tools that projects do not have time to develop and grow.
The code would be common to OpenStack, and therefore reducing the overall 
complexity of
projects which were carrying those tools, the same way as the Release or 
OpenStack-Infra
team are providing tools for the community.

I have a few other ideas for simplifications but instead of carrying on, I 
would prefer
hearing from you, and hearing from your ideas. So, please, contact me!

Long story short: I would like to be there to help shaping the community 
together, with your help.
Thank you for your consideration,

Jean-Philippe Evrard (evrardjp)


__
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] [election][tc] TC Candidacy for gong yongsheng

[龚永生]

Hi,


I am announcing my candidacy for a member of the Technical Committee.


Now I am CTO of 99cloud Inc., China. After discussing with my Team (My CEO, COO
and R department), I made up my mind. This means my company will continue
devoting itself into the OpenStack community, help the OpenStack to meet
customer’s needs and promote OpenStack to a new high.


I was previously a Neutron Core member and am the PTL of Tacker project.
Besides this, I am also making contribution to OpenCord project, which is the
edge platform for telecom central office. OpenCord project is using OpenStack
as the platform to instantiate the VNFs. One more open project I am leading my
company R to is akraino edge stack, a Linux Foundation project in formation,
which will create an open source software stack to improve the state of edge
cloud infrastructure for carrier, provider, and IoT networks. I think
OpenStack can play a good role in OpenCord and akraino as the infrastructure
manager.


I agree to Thierry Carrez with the concept of “Constellations” (representation
of groups of OpenStack components that answer a specific use case).
For example, in the case of MANO system, we need to improve Tacker with
OpenStack as NFVI. For DEVOPS, the ZUUL and the whole OpenStack’s CI
infrastructure is great, we can also introduce kubernetes into this
constellation so that we can meet the DEVOPS needs of container-based or
VM-based applications.


I am new to TC governance and have the passion to join TC. I am a technical
guy and hope I can help to glue the OpenStack projects and keep my eye on
their development. As a member of management team, I like to make others
succeed and then enjoy their success. So, I will support OpenStack project
teams to make OpenStack great again.


Thank you for your consideration.
Best Regards,


Gong Yongsheng (gongysh)


[1] 
http://stackalytics.com/?metric=commits=99cloud_id=gongysh=all
[2] http://stackalytics.com/?metric=commits=99cloud=all
[3] https://www.akraino.org/



__
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] [election][tc] TC Candidacy for Graham Hayes

[Graham Hayes]

Hi,

I am submitting my candidacy for the OpenStack Technical Committee.

I have been contributing to OpenStack since the Havana cycle [1][2],
mainly in
Designate. I have also been involved with the TC, and its meetings since
Designate applied for incubation all the way back in Atlanta (the first time
we were there).

Over the last 6 months I have become more involved in the TC, and have been
an active contributor to TC discussions (both on IRC and in person) and
governance [3].

I have been PTL for Designate for Mitaka, Newton, Ocata, Queens and Rocky
cycles, and a core for a longer period. I believe my experience working in a
younger, smaller project within OpenStack is a benefit. Along with the
experience of working on software as an end user of OpenStack I can help us
ensure the Technical Committee is mindful of the unique challenges these
projects and users can face.

With the broadening of the scope of the OpenStack Foundation, I believe that
it is an important part of the TC's role to have robust, and frank
discussions
with the Board of Directors and I believe that I have done a reasonable
job of
summarizing [4][5] what happens at the Board of Directors meetings to the
community over the last 6 months.

The need for the candid discussions is not restricted to the Foundation
and the
board - the new strategic focus areas that the foundation is expanding into
need our technical leadership to engage with them and ensure that we are all
working towards the overall goal of the foundation and promoting open
infrastructure. We need to make collaborating, and sharing resources and
expertise where it makes sense a priority.

What it does not mean is changing what OpenStack is nor changing
OpenStack to
cater for a single use case. This is a situation where better education
of how
OpenStack and it components can be used and orchestrated is needed, and
a lot
of this work should be directed by the TC. I don't think the TC will
always (or
even most of the time) be the correct people to engage, but I think we
should
lead the way by finding the correct people with the knowledge and
experience,
and helping support them and provide them with a platform to provide
guidance
to these groups.

When it comes to pushing forward the TC vision[6] I think the community has
made great steps forward to realizing it, on all but one section. We engage
with groups like the CNCF, and specifically Kubernetes and help drive
OpenStack
adoption with first class support for the OpenStack Cloud Provider, the
Cinder
Container Storage Interface and other projects. We still need to find a
way to
show the world what a top tier private open source infrastructure of
components
like OpenStack, Kubernetes, Cloud Foundry or OpenShift looks like, and
helping
companies understand why this is the way forward for their infrastructure.

Unfortunately, helping users, deployers and C(T|I)Os understand this
would be
easier with well written and and clearly documented "constellations" - I
have
always found talking in the abstract is a lot more difficult than discussing
something tangible. For the last 5 years I have worked on product teams
building products based on OpenStack, Kubernetes and Cloud Foundry, and
I think
this experience will be a great asset in developing our first generation of
constellations, which is something I think we need to focus on for the next
term of the TC.

I think that having constellations will also help us solve the perennial
question of what OpenStack is. By having sets of projects, we can show that
OpenStack is extremely flexible - and that there are projects for
different use
cases. Far too much time is spent circling back to the "What is OpenStack" -
which I foresee getting even more complex as the OpenStack Foundation grows
beyond the OpenStack Project, and having a solid, stable answer to what
we are
is going to be vital.

I would like to thank you for taking the time to read my thoughts - and ask
you to consider me for your vote. If elected I will strive to be vocal
for the
community that I have gotten so much from. I want to give some more back to
them ensure that the OpenStack Project continues to be the go to
software for
Infrastructure as a Service.

Thanks again,

 - Graham


1 - http://stackalytics.com/?release=all=commits_id=grahamhayes
2 - https://www.openstack.org/community/members/profile/12766/graham-hayes
3 -
https://review.openstack.org/#/q/project:openstack/governance+(commentby:%22Graham+Hayes+%253Cgr%2540ham.ie%253E%22+OR+reviewedby:%22Graham+Hayes+%253Cgr%2540ham.ie%253E%22++OR+owner:%22Graham+Hayes+%253Cgr%2540ham.ie%253E%22)
4 -
http://graham.hayes.ie/posts/dublin-ptg-summary/#board-of-directors-meeting
5 -
http://graham.hayes.ie/posts/sydney-openstack-summit/#sunday-board-joint-leadership-meeting
6 -
https://governance.openstack.org/tc/resolutions/20170404-vision-2019.html



signature.asc
Description: OpenPGP digital signature

[openstack-dev] [election][tc]TC candidacy

[Zhipeng Huang]

Hi all,

I'm announcing my candidacy for the OpenStack Technical Committee.

I started following OpenStack community since Portland Summit in 2013, and
has been an integral part of it from then on. I'm currently serving as the
PTL for the Cyborg project [0] which provides general management framework
for accelerators. I'm also serving as the co-chair of the Public Cloud WG
[1], active member of the First Contact SIG [2] and had been a contributor
for the Interop WG throughout the year 2017 [3]. Outside of OpenStack, I'm
one of the founding co-leads for the Kubernetes Policy WG [4], the
ecosystem lead for OpenSDS community [5], and also served as the PTL of
OPNFV Parser project from 2014 to 2016 [6]. I've also been involved with
Open Service Broker API and SPDK community where my team members are
working on.

I would like to think my strength are in the areas like cross-community
collaboration, community team building, and non-stop innovation. I believe
these are also the areas that my future work on the Technical Committee
should continue to bring forth.

** Cross Community Collaboration **

For those of you who are familiar with my work, you would know that I've
always been taking a full stack approach for open source community work and
strongly believed the value of collaboration. From the very start building
of the *Cyborg project*, we collaborated with the OPNFV community and also
had a concrete plan on working with communities like Kubernetes, Linaro,
ONNX and so forth. With my work in *OpenSDS*, I've repeatedly emphasize the
importance of the capability of working with OpenStack and Kubernetes but
not drop something and claim it would be better to replace the existing
module which has been built by a lot of community work. During our
discussions in the *Kubernetes Policy WG* on multi-tenancy I've also
introduced what the Keystone team has greatly done and try to build a
synergy there.

Hence if I were to be elected on the technical committee, I would like to
pushing further on the community collaborations within but not limited to
the following areas:
*- Data model alignment regarding accelerator between OpenStack and
Kubernetes via Cyborg project and the Resource Management SIG.*
*- Alignment regarding Policy architecture between OpenStack and Kubernetes
via Kubernetes Policy WG as well as Keystone team.*


** Community Team Building **

With currently busting the hype bubble, I've seen many commentaries on how
OpenStack "is getting outdated" and not "technically cool" any more. Set
aside the absurdity on the technical aspects, I think one of the core
things people will learn in the OpenStack community is the governance, the
way how we work here.

Take *Cyborg* for example, from day one I've been strictly following the
four opens principle and trying to build a good team structure by learning
from great teams like Nova, Cinder, Neutron, etc. The Cyborg project was
started from basically zero and I intentionally avoided any code dumping as
we've seen in many open source projects. We designed the specs from open
discussion, wrote the codes with public reviews and continue on. When few
people believe even this could work, we make it happen. The reward we are
having is awesome, for example on nova-cyborg collaboration, by not
mandating certain design philosophy, we have great Nova developers joining
our project meeting from time to time, providing valuable comments on how
we better design the interaction, and help reviewing the specs. I think for
a new project I dare say we've got the best and logical architecture design
with regarding to nova interaction.

With that said, the community team building will be another important theme
for my future work on TC:
*- Leveraging First Contact SIG, to try to incubate or help more project
that knows how to build their team in a community way instead of a
corporate way.*
*- Continue on the Cyborg team structure building, enable reasonable
sub-team work and encourage more developers to join and contribute.*
*- Enabling more collaboration between projects and WG/SIGs. We have some
good experience on Cyborg working with Scientific SIG as well as Public
Cloud WG working with Nova/Keystone team, and I think we could make further
progress on it*

** Non Stop Innovation **

OpenStack offers the ultimate open source cloud computing infrastructure
and there are just so many exciting new things we could do with it. I've
experimenting the ideas of *how Cyborg could better support AI application,
and also the possibility of utilizing blockchain for the Passport Program
[7]*. I plan to keep bring new things like these forward when given the
opportunity to serve on the  technical committee to make OpenStack's edge
keep cutting as sharp as ever :)

Thank you for your time to read such a long letter and please vote for me
and any other candidate that you see value in. A great community could not
exist without your important voice.

[openstack-dev] [election] [tc] TC candidacy for cdent

[Chris Dent]

Hi,

I'm announcing my candidacy to continue as a member of the Technical Committee.
When I ran a year ago, one of my goals was to foster more, and more
transparent, communication among the many parts of the OpenStack community. The
TC has made progress by being more overt and intentional in reaching out to
others and sharing information in an active way. I helped, with my weekly TC
Reports and other writing related to the TC [1], but there is plenty more to
do, especially as the infrastructure as a service community grows and mutates
to include CI/CD, Edge and container-related activities. Enough left to do that
I would like to continue for another term.

The growth of projects under the OpenStack Foundation umbrella will present
opportunities and challenges. We'll be able to deal with those most effectively
by having good communication hygiene: over communicating in a written and
discoverable fashion.

Changes in the shape of the community will impact the role of the TC and its
members. The TC has been something of a high-level judiciary within the
OpenStack technical community but increasingly will need to take on a role as a
representative of the community that develops what has traditionally been known
as "OpenStack" to the other nearby communities that are also now "OpenStack".

My candidacy note from last year [2] remains relevant and a good expression of
my opinions about governance and the overarching themes that concern me:
communication, openness, lowering boundaries between people and platforms,
maintaining developer sanity [3].

If I'm elected again I intend to encourage engagement by continuing with the
TC Report, making sure that we include the right people when making decisions,
and using media that is accessible to people of many languages and time zones.

I will also actively drive discussion and policy that leads to people who are
users of OpenStack in the broadest sense finding it easier to be regularly
active contributors to the open source projects which create OpenStack. We are
making progress with this, but much of OpenStack is still the domain of (often
overburdened) "professionals". Breaking into those domains needs to be simpler
and encouraged for the benefit of all concerned.

If you would like to look at my past voting record on governance changes that
can be found here:

https://review.openstack.org/#/q/project:openstack/governance+reviewedby:%22Chris+Dent+%253Ccdent%2540anticdent.org%253E%22

If you would like me to continue, please vote for me in the upcoming elections.
If you would like someone else, please vote for them. If you would like to
give it a try yourself, then please run; you have until the end of the (UTC)
day of April 17th to submit your candidacy. See the following for details:

https://governance.openstack.org/election/#how-to-submit-a-candidacy

Thanks for reading and your consideration.

[1] https://anticdent.org/tag/tc.html
[2] 
https://git.openstack.org/cgit/openstack/election/plain/candidates/pike/TC/cdent.txt
[3] https://anticdent.org/openstack-developer-satisfaction.html

--
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

[openstack-dev] [election] [tc] TC candidacy (but not for chair)

[Thierry Carrez]

Hi everyone,

Growing new leaders has been a focus of the Technical Committee over the
last year: first discussed at the leadership workshop with Board members
in March 2017, then included in the TC "vision for 2019"[1] adopted in June.

As part of this objective, we actively looked for new stewards in our
community, provided opportunities to step up, and rotated key roles to
develop a deeper bench of ready leaders. But we never applied those
ideas for the TC chair position itself: I have been the only candidate
and holding that position since the creation of that governance body in
2012. The main reason for it is that tracking everything that's
happening is a significant commitment, and the Foundation is happy with
me investing that time in. That said, it's not ideal to have a role that
only one person can fill, so it's time for a change.

I am announcing my candidacy for a position on the OpenStack Technical
Committee in the upcoming election. However, if I'm elected I won't be a
candidate to the chair position for the upcoming TC session. To ensure a
seamless transition I will actively support the person who will be
chosen by the TC members. In all cases I'll be as involved with the TC
activities as I've always been.

In my opinion our vision for 2019[1] is still current. We have a lot of
work ahead of us to fully implement it, especially around the concept of
"Constellations" (representation of groups of OpenStack components that
answer a specific use case). Beyond that, our main challenge is to
continue to adapt OpenStack governance to the evolving needs of the
project. Most of our processes and structures come from back when we
doubled activity every year, when our main focus was to survive that
meteoritic growth. With OpenStack getting more mature and having more
adoption, we need to rethink those processes and structures with
long-term sustainability in mind. Finally, we need to navigate a
transition where everything produced by our community will no longer
necessarily be called "OpenStack", starting with Zuul being given its
own separate branding.

If you're passionate about open source project governance and interested
in tackling those challenges, please consider running for the Technical
Committee ! Several of the current members won't be running for
re-election, so seats are up for grabs.  We track current proposed
changes on a Tracker[2], track work items on StoryBoard[3], and usually
meet in person at Summits and PTGs. You can read past weekly "TC status
update" emails to get a better idea of the type of things we cover. I
would say the time commitment is between 2 and 6 hours a week. Join us !

[1]
https://governance.openstack.org/tc/resolutions/20170404-vision-2019.html
[2] https://wiki.openstack.org/wiki/Technical_Committee_Tracker
[3] https://storyboard.openstack.org/#!/project/923

-- 
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-dev] [election][tc] TC Candidacy - Swapnil Kulkarni (coolsvap)

[Swapnil Kulkarni (coolsvap)]

OpenStackers,

I am Swapnil Kulkarni(coolsvap), I have been a ATC since Icehouse and I wish
take this opportunity to throw my hat for election to the OpenStack Technical
Committee this election cycle. I started contributing to OpenStack with
introduction at a community event and since then I have always utilized every
opportunity I had to contribute to OpenStack. I am a core reviewer at kolla
and requirements groups. I have also been active in activities to improve the
overall participation in OpenStack, through meetups, mentorship, outreach to
educational institions to name a few.

My focus of work during TC would be to make it easier for people to get
involved in, participate, and contribute to OpenStack, to build the community.
I have had a few hickups in the recent past for community engagement and
contribution activities but my current employment gives me the flexibilty
every ATC needs and I would like to take full advantage of it and increse
the level of contribution.

Please consider this my application and thank you for your consideration.

[1] https://www.openstack.org/community/members/profile/7314/swapnil-kulkarni
[2] http://stackalytics.com/report/users/coolsvap
[3] https://review.openstack.org/510402

-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap
me at coolsvap dot net

__
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] [election] [tc] TC Candidacy

[ChangBo Guo]

Hi everyone,

I'm announcing my candidacy for a position on the OpenStack Technical
Committee.

I'm ChangBo Guo(AKA gcb)[1], currently working for EasyStack, leading
developers' upstream contribution on OpenStack in the company. I have been
working on the OpenStack since 2012, firstly focused on Nova and then focus
on Oslo, also contributed to several other projects[2]. I've been serving
as the PTL of Oslo (OpenStack Common libraries) for Pike and Queens.

During the last 5 years, as a developer I have the chance to talk with
users/operators, meeting users/operators' requirements and making
OpenStack more useful are important, that's the key factor to make OpenStack
successful. OpenStack has huge potential customers though some companies
adjust their investment on OpenStack. We have some progress on shortening
the feedback loop like building SIG(Special Interest Group) to involve more
users. Not all the users can raise their requirements easily due to the
barrier like language. TC may need work with UC to find more ways to collect
users/operators' requirements like we have 'Top 5 help wanted list' in
development cycle.

OpenStack is the first open source project I contributed, I've learned a lot
from community leaders in the past 5 years and guided some new contributors
how to work with other world wide contributors. It's not a easy to be
productive for a new contributor especially for whom without open source
experience. In last several cycles some key contributors changed their work,
not focus on OpenStack, in the other side, some new contributors couldn't
find
'the right way' to contribute, posting trivial repeated patches, we're
facing
the challenge! Though we have program 'OpenStack Upstream Institute' to
training
new contributors, that's not enough for new contributor, because not all new
contributors can attend the the OpenStack Summit. TC may host more online
events
to invite community leaders to communicate with new contributors, and help
new
contributors to contribute in 'the right way'.

As a TC member I want to focus on shortening the feedback loop and guiding
new
contributors. Thank you for your consideration!

ChangBo Guo(gcb)


[1] https://www.openstack.org/community/members/profile/14945/changbo-guo
[2] http://stackalytics.com/report/users/glongwave
__
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] [election] [tc] TC Candidacy

[Amrith Kumar]

I wish to submit my candidacy for election to the OpenStack Technical
Committee. I have never been elected to the Technical Committee before
but, I have never believed that being elected is a requirement to
participate in the deliberations. I have therefore been a frequent
participant and a consistent follower of the activities of the TC.

My focus on the TC would be (consistent with prior candidacies for the
TC) to make it easier for people to deploy and use OpenStack, and make
it easier for people to get involved in, participate, and contribute
to OpenStack.

I have been an active technical contributor to OpenStack for about
four years[1], involved in Trove for that entire period of time. I have
been the PTL for Trove for three cycles (Newton, Ocata and Pike). I
was reelected for Queen but at the PTG that position was transitioned
over to another member of the team[2] as I move my focus to a new DBaaS
implementation for OpenStack (tenantively named Hoard).

During these four years, I have been involved in a number of the
initiatives of the TC including most significantly the Stewardship
Working Group which began the process of writing the TC Vision
document. I attended the first of the Stewardship training sessions in
Michigan where the idea of the cross-project goals was conceived of
(by Doug Hellmann and others), an initiative that I am strongly
supportive of.

I have also been active in activities to improve the overall
participation in OpenStack, through mentorship, outreach to
educational institions. This is a key aspect of my current role,
employed at Verizon Wireless in the team that has built, and operates
one of the largest OpenStack deployments around. The team now includes
Brian Rosmaita, and Graham Hayes, and we are actively hiring more
contributors to the team.

I thank you for reading, and appreciate your vote.

[1] http://stackalytics.com/?release=all=commits_id=amrith
[2] http://openstack.markmail.org/thread/txurdd5bhbzsebtq

-amrith

__
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] [election] [tc] TC Candidacy (smcginnis)

[Sean McGinnis]

Hello everyone,

I would like to put my name in for the TC election.

For those of you that don't know me, my name is Sean McGinnis and I have been
the Cinder PTL since the Mitaka release. I have been an operator, consumer,
and developer of infrastructure related services since the late 90's.

I think the role of the TC is more important now than ever. OpenStack is
evolving changing, and the decisions we make now will have a big impact on
where we are a year or more down the road. I would love to be a part of that
and provide my perspective to help shape these decisions.

I've been asked by several people over the last few months for my perspective
on some large companies pulling away from OpenStack or reallocating their
resources elsewhere. While this certainly has an impact on some of the things
we can accomplish, my opinion is that this is actually a good thing. For quite
a while we had some big names dropping a lot of money into the community, with
little return on that investment.

While the loss of some really amazing folks has certainly been felt across the
board, I think this is actually a good thing and something that needed to come
sooner or later. The hype has certainly moved on to other things, but I feel
OpenStack is probably more relevant and useful than ever. With our community
shrinking, this is forcing us to look at what we really need to focus on and
make sure we have a good solid core. I do believe that in the long run,
OpenStack will end up better after going through our current growing pains.

Related to that, I think we do need to start getting a little more opinionated
about some things in the interest of keeping things simple and focused. We
should make it clear what is a core part of OpenStack, and what is a part of
the broader ecosystem.

At the same time, we need to balance encouraging that ecosystem to grow and
thrive. It doesn't matter how well Cinder can create volumes and Nova can spin
up instances if it is too difficult to use build broader solutions on top of.

I'm also a big proponent of closing the loop between those using OpenStack and
those of us building it and setting its direction. I've made it a point to
attend the Operator Midcycles in order to increase this communication. Our
communication between users, operators, and devs is key in making sure we are
focusing those limited resources on addressing the features and issues with
the greatest impact.

Finally, I think education and documentation is a very important component to
all we do. Things like the Upstream University to help new developers get on
board and contributing will be a focus for me going forward. And it doesn't
matter how good of features we implement, if there is no documentation or other
means of educating users about them and how to use them.

So my main thoughts could probably be distilled to:

* Keep things simple as much as possible
* Encourage expansion and interoperability to a wider ecosystem
* Increase communication across all aspects of the community
* Spread knowledge wherever possible

I think mostly we are on the right track for all of these, and I would love to
be part of the TC to be another voice to encourage and direct where we go.

Thank you for considering me for this role!

Sean McGinnis (smcginnis)

__
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] [election] [tc] TC Candidacy

[Adrian Otto]

I am announcing my candidacy [1] for a seat on the OpenStack Technical 
Committee. I've had the honor of working on and with OpenStack since it was 
conceived. Since our first Design Summit on July 13-16 2010, I have been 
thrilled to be a part of our movement together. We have come a long way since 
then, from a hopeful open source project with our friends at Rackspace and NASA 
to a thriving global community that has set the definitive standard for cloud 
software.

Over the past seven years, I have viewed OpenStack as my primary pursuit. I 
love our community, and the way we embrace the “four opens”. Along this 
journey, I have done my very best to push the limits of our innovative spirit, 
and pursue new and exciting ways of using software defined systems to make 
possible what we could have only imagined when we started. I have served our 
community as an innovator and as a PTL for the good part of the past 5 years. I 
served as the founding PTL of OpenStack Solum, and pivoted to become the 
founding PTL of OpenStack Magnum. I currently serve in this role today. Each of 
these project pursuits were aimed at making OpenStack technology more easily 
automated, more efficient, and combining it with cutting edge new technologies.

I am now ready to embark on a wider mission. I’m prepared to transition 
leadership of Magnum to my esteemed team members, and pursue a role with the 
OpenStack TC to have an even more profound impact on our future success. I have 
a unique perspective on OpenStack governance, by repeatedly using our various 
processes and applying our rules, guidelines, and values as they have evolved 
to I deeply respect the OpenStack community, our TC, and their respective 
membership. I look forward to serving in an expanded role, and helping to make 
OpenStack even better than it is today.

I will support efforts to:

1) Make OpenStack a leading platform for running the next generation of cloud 
native applications. This means making sensible and secure ways of allowing our 
data plane and control plane systems to integrate. For example, OpenStack 
should be just as good at running container workloads as it is for running bare 
metal and virtualized ones. Our applications should be able to self heal, 
scale, and dynamically interact with our clouds in a way that’s
safe and effective.

2) Expand our support for languages beyond Python. Over the past year, our TC 
has taken productive steps in this direction, and I would like to further 
advance this work so that we can introduce software written in other languages, 
such as Golang, in a way that’s supportable and appropriate for our community’s 
growing needs.

3) Advocate for inclusivity and diversity, not only for software languages but 
for contributors from all corners of the Earth. I feel it’s important to 
consider perspectives from various geographies, cultures, and of course from 
each gender. I want to maintain a welcoming destination where both novice and 
veteran contributors will thrive.

4) Continue our current work on our “One Platform” pursuit, and help to refine 
which of our teams should remain in openstack, and which should not. I will 
also work to contribute to documenting our culture and systems and clearly 
defining “how we work”. For an example of this, see how we recently did this 
within the Magnum team [2]. We can borrow from these ideas and re-use the ones 
that are generally useful. This reference should give you a sense of what we 
can accomplish together.

I respectfully ask for your vote and support to pursue this next ambition, and 
I look forward to the honor of serving you well.

Thanks,

Adrian Otto

[1] https://review.openstack.org/454908
[2] https://docs.openstack.org/developer/magnum/policies.html
__
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] [election][tc] TC candidacy

[Ed Leafe]

Hello! I am once again announcing my candidacy for a position on the OpenStack 
Technical Committee.

For those who do not know me, I'm easy to find. My name is Ed Leafe; I'm 
'edleafe' on IRC, and @edleafe on Twitter. I have been involved with OpenStack 
since the very beginning, when I was working for Rackspace as a core member of 
the Nova team. An internal job change took me away from active development 
after Essex, but since being hired by IBM, I've been back in the OpenStack 
universe since Kilo. As a result of this long involvement, I have always had a 
strong interest in helping to shape the direction of OpenStack, and if there is 
one thing people will agree about me, is that I'm never shy about voicing my 
opinion, whether the majority agree with me or not (they usually don't!). I now 
spend most of my time working on Nova and the new Placement service. I also 
spend a good deal of time arguing over obscure HTTP issues with the API Working 
Group, and sometimes blog about them [0].

You'd think that with this long involvement, I'd be happy to see OpenStack 
continue on the course it's been on, and for the most part, you'd be right. 
What we've gotten right is the way we work together, focusing on community over 
corporate interests - that is essential for any project like OpenStack. What we 
really could improve, though, is how we focus our efforts, and how we set 
ourselves up for the future.

The Big Tent change was important for making this feel like an inclusive 
community, and for allowing for some competition among differing approaches. 
Where I think it's been problematic is that while the notion that "we're all 
OpenStack" is wonderful, this egalitarian approach has made it somewhat 
confusing, not only to the outside markets, but to the way we govern ourselves. 
I think that it's important to recognize that OpenStack can be divided into two 
parts: Infrastructure as a Service (IaaS), and everything else. Monty Taylor 
first outlined this split back in 2014 [1], and while there is still some room 
to debate which projects fall into which group, I think it's a more important 
distinction than ever. The "Layer 1" projects have a strong dependency on each 
other, and need to have a common way of doing things. But for all the other 
projects that build on top of this core, that sort of conformity is not 
critical. In fact, it can be a hindrance. So I believe that different technical 
rules should apply to these two groups.

The recent discussions on the approval of Golang and other languages into the 
OpenStack ecosystem [2] highlighted the need for this division. For the core 
IaaS projects, there should be a very, very high bar for using !Python. But for 
the others, I'd prefer to let them make their own choices. If they choose a 
language that is difficult to deploy and maintain, or that doesn't create logs 
like the rest of OpenStack, it's going to wither and die unless the benefits it 
brings is great enough to make that increased burden.

To my mind, this is the only way to make OpenStack better: focus on making the 
IaaS core as rock-solid and dependable as possible, but then open things up for 
experimentation everywhere else. As long as a project follows the Four Opens 
[3], let them make the decisions on the trade-offs. As an API wonk, that's what 
the benefit of consistent APIs offers: the ability of any app to interact, not 
just those written in the same language.

This ties in with my other main concern: the narrowing-but-still-wide 
separation between OpenStack developers and operators. We've made a lot of 
progress over the last few cycles, but we still need to get a lot better. In my 
former life in the construction industry, there were always architects who 
designed very interesting things, but which were a complete pain to build. 
Inevitably this was the result of the architect having little practical 
experience in the field getting their hands dirty building things. Many of the 
comments I've heard from OpenStack operators have a similar aspect to them. I 
know that I have never run a large cloud, so when an operator tells me about an 
issue, I listen. I'd like to see the TC continue to encourage more 
opportunities for OpenStack developers to be able to listen and work with 
OpenStack operators.

So if you're still reading up to this point, perhaps you might want to consider 
voting for me for the TC. But either way, please ask questions of the 
candidates. That's the only way to know that the people you choose share your 
concerns, and that will help to ensure that the TC represents your interests.

[0] https://blog.leafe.com
[1] 
http://superuser.openstack.org/articles/openstack-as-layers-but-also-a-big-tent-but-also-a-bunch-of-cats/
[2] 
https://github.com/openstack/governance/blob/master/reference/new-language-requirements.rst
[3] https://governance.openstack.org/tc/reference/opens.html

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP

[openstack-dev] [election] [tc] TC candidacy (dims)

[Davanum Srinivas]

Team,

Please consider my candidacy for another term on the OpenStack Technical
Committee. In my previous candidacy statement[1], i had mentioned the following
challenges - "balance stability/innovation, fostering new talent, target our
limited resources to make OpenStack even better". This is as true as it was
a year ago given the challenges we face today as a foundation. As a group, the
TC has made good progress in helping with those challenges. Some
highlights include:

* Recent Board/TC workshop where we identified 4 critical areas and setup up
work groups to come up with actionable items that we can do in the
short term [2].
* Technical Committee Vision for 2019 [2]

Since the following were my previous goals from [1]:
- Cross Project issues, increasing collaboration between projects
- Backwards compatibility issues and testing
- Evangelizing great ideas from different projects

In addition to spending time on the Release and requirements teams, Here are
some ways i helped on the last year
* Helped setup the python3 support in various projects and infrastructure and
  get several projects to setup CI jobs with functional tests
* Spent time in the Kubernetes community to figure out how to work better
  between the two communities, the areas of overlap etc.
* Started the go-and-containers initiative[4] to help advance golang as a choice
  for projects and increase areas of collaboration with Docker, Kubernetes.
* Actively or passively nudged several projects including Zun, OpenStack-Helm
  and Loci. Please look them up and participate!

In addition to challenges and goals from before, we have some new ones that i
would like to work on:
- We need to draw boundaries around what we do well so we can talk better to
  others in the larger open source eco systems (adjacent communities) about how
  end users can compose and customize what they need for their environments
- Some projects need help since cores have moved to work on other
things or their
  employers have moved away from supporting those projects. We need to
figure out
  how to help, not just from a maintenance point of view, but how to convert
  folks who are part timers or operators to help actively to keep things going.
- Folks who are just getting started in OpenStack do not know how to advance in
  the community (contributor->core, core for multiple projects, cross project
  collaboration etc), so we should setup programs and processes (Ladder program
  in vision statement) to help with this situation.

I love being part of the OpenStack community and learning from all the great
talented people is what keeps me going. Thanks for the opportunity to serve
on the TC last year and would love to do so for another term.

[1] 
https://git.openstack.org/cgit/openstack/election/tree/candidates/newton/TC/Davanum_Srinivas.txt
[2] 
https://crustyblaa.com/march-8-2017-openstack-foundation-strategic-planning-workshop.html
[3] 
http://docs-draft.openstack.org/62/453262/3/check/gate-governance-docs-ubuntu-xenial/e13854f//doc/build/html/reference/technical-committee-vision-2019.html
[4] https://etherpad.openstack.org/p/go-and-containers


-- 
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

[openstack-dev] [election] [tc] TC candidacy

[Chris Dent]

Hi, I'm Chris Dent, cdent on IRC.

I'm once again nominating myself to be your representative on the
Technical Committee. I've been around OpenStack for about three
years, most recently visible as the guy who writes those weekly
updates about the placement API service and talks about the
API-WG.

In the past several months we've seen the TC starting to take a more
active role in describing and shaping the technical and cultural
environment of OpenStack. Initiatives like release goals, TC and
OpenStack vision exercises, discussions on how to reasonably
constrain growth and increased attention to writing things down are
all positives.

Meanwhile the economic environment for cloud technology and for
technical contributors has been a roller coaster. Lots of things are
changing in the world of OpenStack.

OpenStack must adapt. Doing so without losing the progress that's
been made will be hard and requires input from a diversity of
voices; people who are willing and able to critique and investigate
the status quo but also understand the importance of consensus and
value of compromise.

Voting for the TC is weird: people nominate themselves and then a
small segment of the electorate places their votes based on some
combination of "have I heard of this person before", "have I
witnessed some of their work and liked it", and, sometimes,
discussion that happens as a result of these candidacy statements. I
hope you'll ask me some questions in the week before the election,
but in an effort to illustrate the biases and concerns I would bring
to the TC here are some opinions I have related to governance:

* Telling stories that explain what and why are more useful in the
  long run than listing rules of how because they lead to a more
  complete understanding.

* It is always better to over communicate than under communicate and
  it is best to do so in a written and discoverable fashion. Not just
  because this helps to keep everyone already involved up to date
  but because it also enables connections with new people and other
  communities.

* The OpenStack ecosystem needs to open up to allow and encourage
  those connections. Open ecosystems can evolve and benefit from
  exchange of ideas. So yes, of course, we should use some golang.
  Of course we should party with kubernetes and trade ideas with
  them.

* OpenStack is better when its people and its projects have opinions
  about lots of things, share those opinions widely, and use them to
  make better stuff and make better decisions.

* There are too many boundaries (some real, some perceived) between
  developers _of_ OpenStack, developers _using_ OpenStack, users,
  and operators. We're all in this together. All of those people
  should be encouraged and able to be contributors and all of those
  people should be users.

* OpenStack can and should do a lot of complicated stuff for big
  enterprises (things like NFV and high performance VMs) but the
  changes required to satisfy those use cases must always be
  balanced and measured against providing a useful and usable cloud
  for individual humans.

* As we move forward on the idea of OpenStack as one platform made
  with many pieces, we have an opportunity to re-evaluate and
  refactor our architecture and project structure to make it easier
  for improvement to happen. We need to ask ourselves if the
  boundaries we currently maintain, technical and social, are the
  right ones, and change the ones that are not.

* For a lot of people, contributing to OpenStack is a job. Working
  on OpenStack should be a good experience for everyone. I think
  of being a TC member as something akin to a union representative:
  striving to keep things sane and positive for the individual
  contributor in the face of change and conflict.

With the TC positioning itself to take a more active role, these
elections could be more important than you've come to expect.  The
people you choose, the attitudes they have, will shape that new
activism. If you feel like I'm talking some sense above, I'd
appreciate your vote. If you need some clarification, please ask me
some questions. After that, if you're still not convinced, please
vote for someone else. But please vote.

--
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

[openstack-dev] [election][tc] TC candidacy

[Dean Troyer]

I am Dean Troyer and would like to nominate myself as a candidate for
re-election to the Technical Committee.

I have been around OpenStack for a long time, primarily working on
DevStack, Grenade and OpenStackClient.

OpenStack has been going through the maturation process in the last
year or two and the explosive growth we experienced in our early years
has subsided.  As a community, we threw a lot of things against the
wall to see what would stick, and those answers are continuing to
become evident.  In come cases we can re-affirm the direction taken,
in others it has been time wrap up and move on.  All of which is a
long-winded way to say we have already begun making some hard
decisions about projects and future and direction.

The TC has begun a process of defining a vision[0] of where we want to
be by describing the OpenStack world as we see it in two years.  One
big part of that vision involved how we operate in the world around
us, ie, other related-but-not-OpenStack projects in the Open Source
cloud world.  We have already seen a good amount of time and effort
expended by OpenStack community members getting involved with other
projects such as Kubernetes and vendor-related products like
OpenShift.  It is imperative that we position ourselves to complement
and not compete with others in our greater community.

And yes, I am going exactly where most of you thought I was with this.
In recent months the TC has taken steps to define how languages that
are not Python might be used in OpenStack projects.  The language
addition process[1] was approved, the first use case analysis to use
Golang team was approved[2], a golang test inteface (CTI) has been
approved[3] and work is underway for implementing the required support
in our CI to test golang projects at the scale we need.

The world around us has changed and OpenStack needs to continue to
grow and adapt with it.  This is an important priority for me, having
written and prototyped the golang CTI.  OpenStack does not need to own
and control everything about building and deploying clouds, but there
are some critical things that we do need to keep close tabs on for the
sake of our deployers and users.  I am excited about some of the
things the OpenStack Foundation staff are working on with regards to
our external relationships, some of which is already visible in the
Boston Summit promotion.

I would be honored to continue serving the community on the Technical Committee.

Thank you
dt


[0] The first draft that came out of our session last month:
https://review.openstack.org/453262
[1] 
https://governance.openstack.org/tc/reference/new-language-requirements.html#step-1-use-case-analysis
[2] 
https://governance.openstack.org/tc/resolutions/20170329-golang-use-case.html
[3] https://governance.openstack.org/tc/reference/cti/golang_cti.html

-- 

Dean Troyer
dtro...@gmail.com

__
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] [election][tc] TC candidacy

[Matthew Treinish]

Hi Everyone,

I'd like to submit my candidacy for another term on the OpenStack Technical
Committee.

In my candidacy platform last year I outlined that if elected to the TC I wanted
to bring more technical oversight to the TC, and also to work on improving the
messaging around OpenStack, to make it clearer. I think in the past year we've
made lots of progress on both fronts, but there is still more work to do. Over
the next year I'd like to see the TC continue to make progress on both fronts.

The introduction of community wide goals was a good start in having the TC
setting a more concrete technical direction for projects. I see a lot of
potential with it and am eager to see it grow it over time. It was also just a
start and long term I'd like to see the TC take on more difficult technical
discussions and making decisions. For example, the recent discussion about
being opinionated about our RDBMS is an example of the kind of discussions I'd
like to see the TC have more of in the future.

For making the messaging around OpenStack clearer I think we've also been
making improvements. Over the last year, we've added and improved a few tags,
added the OpenStack principles document, and more recently we've worked on a TC
vision for the next 2 years. Over the past year we've also started taking
a more aggressive stance towards removing projects. Moving into the future I'd
like to see more progress on clearly documenting what OpenStack is and how it
can be used. I'm optimistic some of the efforts we're working on will continue
to make this better over time.

For the next year in addition to continuing progress on the items I outlined
before the other priority I see for the TC is working on improving the health
of the contributor base in the community. It's no secret that there has been
a recent contraction in the community and a lot of long time contributors and
community leaders are no longer actively contributing. I think we need to take
more proactive steps about this if we want OpenStack to continue to thrive.

I think there are 2 key areas we'll need to address on this front. The first
is I'd like to see the TC taking a more hands on approach for both building up
the mentorship pipeline to enable growing the contributor base and leadership in
the community. Most of of existing efforts in this area tend to be concentrated
on on-boarding new contributors which is good, but there isn't anything to
help bridge the gap into becoming a community leader. This is somewhere I can
see the TC taking a more active role to help people work towards taking
on leadership roles in the community.

The other aspect is I think we need to working towards making our community
more accessible for casual and/or part time contributors. Right now our
community process for contribution is heavily weighted towards full time and
corporate sponsored contribution. Over the next year I'd like to work towards
easing this burden and growing the number of casual and/or independent
contributors.

I think this will take 2 forms, the first is decreasing the barrier to entry on
our tooling. Things like the CLA and the multi-step process involving creating
multiple account just to get access to pushing proposed changes is very
off-putting, especially if you're not familiar with the systems. The other
aspect I think is more social. To a certain degree a lot of processes around
contribution or interaction assume that people are constant contributors and
always active (or connected). For example, how often do people push a patch
up for review and then bug a bunch of cores on IRC about it. That's not really
an option if you only can contribute for an 1 hr or 2 on the weekends. This is
an area where I'd like to see the TC start driving more active change to improve
the situation so we can hopefully start to grow the number of casual
contributors we have to the project.

Thanks for reading, I hope this outlines where my focus and priorities would be
if I'm lucky enough to be elected for another term.

Thanks,

Matthew Treinish

IRC: mtreinish
Review history: 
https://review.openstack.org/#/q/reviewer:mtreinish%2540kortar.org
Commit history: https://review.openstack.org/#/q/owner:mtreinish%2540kortar.org
Blog: http://blog.kortar.org/


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

[openstack-dev] [election] [tc] TC candidacy

[Thierry Carrez]

Hi everyone,

I am announcing my candidacy for a position on the OpenStack Technical
Committee. For those who don't know me yet, I work for the OpenStack
Foundation, and I've been serving on the Technical Committee as its
chair since it was created. Beyond coordinating the TC activities,
upstream my focus is mainly on Release Management.

I'd like to use my candidacy email to explain the role of the Technical
Committee, what we did over the past year and what would be my focus if
you'd have me for one more year. The Technical Committee fills a number
of tasks:

1. Serving its constituency

The Technical Committee handles communications and interactions with
other parts of OpenStack community and governance, like the Board of
Directors or the User Committee. It also acts as a governance safety
valve, providing a final decision-making mechanism for upstream
development. Finally, it is responsible for ensuring we have an
inclusive and welcoming environment for open collaboration.

I think we made great improvements over the last year in this area. The
relationships with the Board and User Committee improved a lot, and we
are collaborating on strategic improvements for OpenStack in common
workgroups now. Also the TC was not used that much over the last year to
make final calls or resolve disputes, which is a good thing and shows
that our governance model works. We have a number of challenges ahead in
terms of inclusivity, in particular to better support part-time
contributors and Asian contributors, where timezones, language and
cultural difference might get in the way. If elected, I intend to work
to evolve how we operate to be more welcoming of those groups.

2. Defining which teams are part of OpenStack and which are not

Another big part of what the Technical Committee does is to define the
list of "official" project teams whose deliverables are considered a
component of "OpenStack". That means evaluating new team applications as
they come, but also refining the limit between "in" and "out" of
OpenStack official projects. That includes interesting discussions about
how far up the stack we should go, but also more difficult discussions
about removing dead efforts or cutting down areas that hurt us
strategically. We also constantly need to balance our community's
integrity/principles with reality: in terms of supporting new
programming languages like Golang, but also in terms of open
collaboration (should driver teams be considered as official or
3rd-party teams ?).

Over the last year we managed to tackle a large number of those
questions. We refined the process for adding programming languages,
finally opening the door for Golang projects in OpenStack. We more
aggressively removed projects, and just started the discussion on our
first "strategic" removal (the Community App Catalog). Significant
change takes time, so most of those discussions are still in progress.
If elected, I look forward to completing those discussions, and together
with the Board and User Committee produce maps of the OpenStack universe
that will make it clearer what OpenStack is (an open infrastructure
framework that you can deploy in various ways) and what it is not.

3. Considering OpenStack as "one platform" and influencing its direction

An increasingly important task of the Technical Committee is to take a
step back and look at OpenStack as a whole. While it is made up of
several components, OpenStack is "one platform" for open infrastructure.
We should make sure that OpenStack components are easy to operate
together, and behave in a consistent way as much as possible. We should
/also/ make sure that it is easy to plug other infrastructure solutions
on an OpenStack base, or to integrate OpenStack components in other
software stacks where they make sense.

Over the past year we introduced "release goals" as a means to make
progress in the same direction together, and as a means to reach base
levels of functionality and consistency across the stack. I personally
participated in the Architecture workgroup, and pushed the idea of "base
services" (which all components can assume will always be present in an
"OpenStack" installation, and therefore can depend on them being
present). This should hopefully help us reach the next step in terms of
scaling and performance, by adopting mature external solutions rather
than forcing us to reinvent the wheel locally. If I'm elected, I intend
to pursue those initiatives.

4. Documenting existing culture and systems

The final task of the Technical Committee is to produce clear
documentation about what we mean by "the OpenStack Way" or "being one of
us". There is a lot of unwritten shared understandings in OpenStack, but
without anyone to write it down, it's hard for new members of our
community to absorb that culture and internalize it.

This was a major focus for the Technical Committee over the past year.
In particular we documented the "OpenStack principles", and started
creating a clear 

[openstack-dev] [election][tc] tc candidacy

[gordon chung]

hi folks,

i'd like to announce my candidacy for the OpenStack Technical Committee.

as a quick introduction, i've been a contributor in OpenStack for the 
past few years, focused primarily on various Telemetry and Oslo related 
projects. i was recently the Project Team Liaison for the Telemetry 
project, and currently, i'm an engineer at Huawei Technologies Canada 
where i work with a team of developers that contribute to the OpenStack 
community.

my views on what the next steps for OpenStack are are not unique. i 
share the idea: OpenStack needs to refine its mission. this is not to 
dissuade developers from continuing to build upon and extend the 
existing projects but i think OpenStack should concern itself with the 
core story first before worrying about extended use cases.

Also, i believe that the existing projects in OpenStack are too siloed. 
coming from a project that interacts with all other services, it's quite 
apparent that projects are focused solely on their own offerings and 
ignoring how it works globally. tighter collaboration between projects i 
believe will help make integration easier and more efficient. similar to 
how services within a project just work together, projects should just 
work together.

in many ways i see the Technical Committee as the Cross Project Liaisons 
some of us are searching for. rather than act as Guardians of "what is 
OpenStack", i think the TC should take a more active role in the 
projects and work together with the PTLs to ensure that the "Cloud" 
story makes sense. PTLs and TC members should work side by side to 
identify gaps in the story rather than the current interaction agreement 
of "you're in. we'll talk if stuff hits the fan".

understandably the "Cloud" story is different to many people so i'll 
employ the strategy i've used previously: listen to others, share the 
decision, share the blame, and claim the success.

thanks for your time.

-- 
gord
__
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] [election][tc] TC Candidacy

[Morgan Fainberg]

Friends, Colleagues, and Fellow Community Members, lend me your ears (or
eyes
as the case may be).

I am pleased to submit for your consideration my candidacy for the technical
committee (TC).

You may know me from such projects as Keystone, and the “From Camera to
Couch”
segment of Jonathan Bryce’s opening keynote at the Vancouver OpenStack
Summit.
I have been an active contributor to OpenStack and have served in a
leadership
role since August of 2013 (as core contributor for Keystone and PTL for two
cycles). During my time contributing to OpenStack I have been focused on
improving the interoperability between clouds, improving the cross
communication between projects, and collecting (both direct and indirect)
feedback from the many deployers and users of OpenStack.

With some distance from being PTL of Keystone, I feel that it is time to
refocus my contributions to OpenStack and work to improve the community in a
different but also very important manner.

The most important thing we can do as a community is to continue to improve
the feedback loop from those who are actively using OpenStack. This means
that we need to continue to clearly hear the deployers and improve the story
around running OpenStack (at small, medium and large scales). We also need
to
improve the voice of the end user (those who are utilizing the actual APIs
themselves on a daily basis); as a community we continually improve our
ability to hear feedback on the projects in the Big Tent, but we must also
be mindful that the demand for OpenStack (especially by the end users) is
what makes it more compelling. The TC provides an overarching vision and
encourages the continued inclusion of the many different facets of our
community.

I believe that with the initiatives like the API Working Group and the
Product Working group, we can make OpenStack significant better and more
compelling. I hope to see the TC continue to encourage cross project
communication, move the “recommendations” provided from the API Working
Group from advisory towards a stronger “tenants of OpenStack API design”,
and work towards codifying a slightly more opinionated OpenStack. These
changes will serve the project for a long time to come.

So in short here is what aim to do as a member of the TC:

* Encourage a strong vision for OpenStack as a whole, ensuring new projects
and old are at home in the “Big Tent”; this includes help in eliminating
bureaucratic red tape for inclusion in OpenStack as possible while making
sure OpenStack still feels like a cohesive ecosystem

* Continue to encourage and drive solid interoperability between deployments
(via defcore and working to drive the API working group recommendations to
something more firm).

* Provide mentorship (both directly and through reaching out to the
community) to new contributors. As a member of the TC it is important to
lead by example especially when it comes to bringing in new members to the
community (developer,

* Continue to be an advocate for both the deployers and the end users and
working to continue to improve the feedback loop between this part of our
community and the developers.

* Work with the rest of the TC, the Foundation, and the Board to continue
solidifying the “what is OpenStack” and how it fits into the needs of the
many consumers of “cloud” technologies.

Finally, I look forward to continuing to be part of this amazing Open Source
community for many more development cycles.

Thanks for your time, consideration, and contributions to this community.

Cheers,
Morgan Fainberg

IRC: "morgan" (or "notmorgan")
Review History:
https://review.openstack.org/#/q/reviewer:morgan.fainberg%2540gmail.com
Commit History:
https://review.openstack.org/#/q/owner:morgan.fainberg%2540gmail.com
__
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] [election] [tc] TC candidacy

[Anita Kuno]

Please accept my candidacy for election to the technical committee.

Election season is both a time of intense activity as well as
(hopefully) a time to self-evaluate and commit or recommit to a personal
vision of OpenStack. OpenStack is exactly as we define it and I hope
many folks are taking a bit of time to consider their vision as well as
the meaning of one's personal work and efforts in that vision.

I'd like to share some of my vision as well as what I find meaningful in
my daily activities.

Vision: creating cloud software that our users can use
That's a paraphrase of the OpenStack mission statement (both in its
present form and in the form that is undergoing amendment currently).
The vision that gets me up everyday (or middle of the night if it is
Tuesday and I'm chairing a third party meeting) is that I'm engaged in
creating software that makes clouds and that our users are using. Now
many of my activities may seem far removed from the creation of software
parts some days but that is the motivation that drives my actions.

Some of my daily activities: answering questions in -infra, helping
folks debug logs, reviewing project-config patches and discussing design
of project-config related concerns, attending weekly meetings of other
teams, chairing two third party meetings per week

That might not seem like much, and I used to be able to do more things
that I could list, but some days it is all I can do to read backscroll
and keep up with the conversation in channel at the same time. Our
incredible growth has put us in a position of having to be in
fire-fighting mode in what used to be a few times per release, to being
in fire fighting mode once a week, to being in fire fighting mode all
the time. I'm concerned that our wonderful, incredible growth as an
entity is causing some teams to not have the time they need to
communicate with each other.

I'll add in here a quote I came across the other day from Viktor Frankl,
Austrian psychiatrist:
"Freedom, however, is not the last word. Freedom is only part of the
story and half of the truth. Freedom is but the negative aspect of the
whole phenomenon whose positive aspect is responsibleness. In fact,
freedom is in danger of degenerating into mere arbitrariness unless it
is lived in terms of responsibleness." Now Viktor goes on to say he
thinks the United States should build another statue, I'm not going to
hold my breath on that but I do agree with Viktor in as much as the
portion I have quoted here.

I think we as a community need to start taking a look at our
responsibilities, to ourselves as people, to our co-workers and team
members and to others in the community as well. Businesses don't decide
how we treat each other, only we can decide that. We are putting an
awful lot of pressure on each other and we don't seem to be allowing for
a pause.

Folks who are able to be effective in these circumstances have all
undertaken personal choices about how much input they can address at any
given time. Yes we need new contributors and those willing to teach and
mentor them are appreciated for their actions, but we also need to start
valuing each other again on a daily basis, some days for just continuing
to show up and do our best.

Good jazz musicians know the basic patterns of jazz but the most
important quality they have is to listen. To play with the intent of
pausing and letting someone else take centrestage for 8 or 16 bars, then
taking a turn themselves. Jazz works because of the ability to pause and
listen. I'm concerned we as a  group have lost our ability to pause, and
by extension to listen.

I don't have solutions, I do have some observations. I also am effective
at leading and moderating discussions. Any solution our group finds
needs to come from the group. It is hard to have a group discussion any
more, we have moved to talking points in order to get things done and
that is sad for me to witness, as I see listening as a group as a
strength. I also consider solutions coming from the group as a strength
as well.

One last point I will make is that operators are becoming more effective
at communicating their needs, to each other and also to developers. I
think there are some good structures in place to foster that
communication and I see that as a huge benefit to OpenStack.

Thanks for reading.

Please read all the candidate platforms and please vote.

Anita Kuno. (anteaya)

__
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] [election][tc] TC Candidacy for Carol Barrett

[Barrett, Carol L]

Hi - I am announcing my candidacy for the OpenStack Technical Committee for the 
upcoming term.



Currently, I am a Data Center Software Planner at Intel. I have been an active 
member in the community since 2013, working with Community teams to understand 
market needs and bring that information to the Community (in the form of specs, 
blueprints, prototypes and user stories) and developing materials to speed 
planning for, and adoption of OpenStack (multi-release roadmaps, Reference 
Architectures, Customer Testimonials, Evaluation and Deployment guides, etc).



As a TC member, I will work to support our success by utilizing my areas of 
expertise. Specifically, you can expect me to:

1) Collaborate to more tightly integrate requirements from our Markets into the 
Specification, Design and Development processes across projects.

2) Establish a mechanism for tracking the implementation of specifications and 
communicating progress and plans to our Markets and ecosystem.

3) Foster discussion on the future direction for our Community and our 
software. What's the vision of the Data Center of the Future? What is needed to 
realize that? How do we make sure that OpenStack is the preferred Cloud 
Platform in this future environment?

4) Work to ensure we have a thriving community that welcomes all comers and 
supports them to become contributing members and leaders.



We have a lot of opportunity for growth and success. I would like to join the 
TC to help our Community realize this potential.



Thank you for your consideration

Carol Barrett



__
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] [election] [tc] TC Candidacy

[David Lyle]

I would like to announce my candidacy for election to the Technical Committee.

You may know me from being the Horizon PTL for the past five releases and a
member of the OpenStack community since 2012 as an operator, contributor and
PTL. Over my tenure, I helped guide the Horizon team through growth that has
paralleled the growth of OpenStack. During this time, I have become sensitized
to the issues that are facing OpenStack at large and specifically from a
horizontal project perspective. I decided to step away from the PTL role this
cycle as I want to focus my efforts toward addressing these issues. The main
issues I want to see progress on in Newton and Ocata are:

1) Setting and driving technical direction and project vision

I think the Technical Committee should take a more active role in driving the
direction of OpenStack. OpenStack now contains many, many projects. The
unified guiding technical direction for those projects is missing. The
OpenStack mission statement reads:

"to produce the ubiquitous Open Source Cloud Computing platform that will
meet the needs of public and private clouds regardless of size, by being
simple to implement and massively scalable"

I will argue that without a unified direction, OpenStack will be many cloudy
things that, with considerable effort, can be used to deliver a cloud computing
solution. That delivers more toward the first half of the mission, than the
latter half. But the technical direction from the TC needs to be more than make
the mission statement reality. While that is enough for projects to make
progress, it is insufficient for end users and operators.

The current cross-project model is broken. The idea of cross-project
initiatives and specs is correct, the problem arises in getting projects to
a) participate in that process
b) actually have that initiative put items on their roadmap
c) actually implement the change

There is no motivation, carrot or stick at this point for projects on
cross-project initiatives. Currently, any cross-project initiative can
effectively be pocket vetoed by a project in OpenStack that does not find it a
priority. Additionally, the cross-project priorities vary per project. Making
progress currently relies on a few individuals doing the work in all effected
projects. With 54 projects, 36 of which are service related, this can be
a prohibitive task. I commend all those who are driving these efforts.

I propose the Technical Committee, working with the user committee and project
teams define some core objectives per release that define the release goals and
track to those. With 54 projects in OpenStack, there is not another way to move
these efforts forward without a lead time of years. One could argue that this
is the purview of the cross-project liaisons, but the TC is the elected
technical governing body in OpenStack and the only one actually defined in the
OpenStack Bylaws.


2) Addressing Big Tent ramifications

Having moved away from a relatively narrow and focused scope for OpenStack,
it is imperative that we improve at functioning as one project. Looking across
OpenStack, since the big tenting, I see a few issues. First and foremost, the
problem of maintaining consistency across projects went from bad to worse.
Previously, consistency problems were centered on APIs, logging, message
content and structure. Now, we have added items like end user documentation and
the forced proliferation of plugin formats. The large number and variety of
projects also makes it difficult to maintain an overall project vision. I think
that may be the current goal. But if we view OpenStack as a merely a kit, we
will again be pushing undo burden on end users and operators. The TC should
formally state whether OpenStack is meant to be a product or a kit,
understanding that a product can have optional and swappable parts.


3) Growth and organization

Many projects are big and unwieldy including the one I lead. The large scope
of projects and the corresponding number of contributors make these projects
sluggish and makes contributing difficult. Contributions are being shoved
through a narrow funnel where priorities are a strange mix of new feature
development and addressing operator needs. I think we need to reevaluate
project scope and governance. This is one area that the big tent provides some
relief, rather than forcing the franken-projects of yore. Breaking out
separable pieces from larger projects should be a high priority. We started
doing this work in Horizon. The consequences of not breaking the monoliths is
that we continue to frustrate new and old developers alike, drown reviewers and
make little relative forward progress. I believe the TC can help design and
drive this restructuring effort.

I still believe OpenStack has the potential to deliver on our mission
statement. And, I think that diverse views being included in the TC is to
everyone's advantage.

Thank you for your consideration,
David Lyle

[openstack-dev] [election][tc] TC Candidacy for Shamail Tahir

[Shamail Tahir]

Hi everyone,

I would like to announce my candidacy for OpenStack Technical Committee
member for the upcoming term.

I am currently an offering manager for OpenStack initiatives at IBM and I
have been involved in the OpenStack community since 2013.  I spend most of
my time[1] in our working groups including the Product, Enterprise,
Application Ecosystem, and Operator Tags team..  I have also spent a lot of
time talking with OpenStack users and organizations that are new to
open-source and OpenStack in order to help them with their journey into
becoming community members.  The OpenStack project continues to gain
adoption while also expanding in scope with new projects and
functionality.  These changes continue to make considering operator and
user experience in strategic and architectural decisions ever more
critical.  Furthermore, the TC itself is involved in a set of broad topics
lately (such as changing the mission statement, diversity, and mentoring to
name a few) and additional perspectives will be good for these discussions.

If elected to be a TC, I would like to focus/highlight on the topics
outlined below:

   * Revisit big-tent workflow for new projects.

- The big tent initiative has promoted faster and broader
innovation inside the OpenStack community and I believe we should reflect
on its first year to build a new set of best practices for both acceptance
and on-boarding new projects along with mechanisms to validate that new
projects are continuing to follow the four opens.  What worked? What
didn't?  Should there be additional criteria based on overall fit/need? And
how can we improve this further?



  * Promote a systems architecture point-of-view of the OpenStack cloud
platform

- There are several initiatives under-way (with more to come) that
can benefit multiple OpenStack projects.  Cross project specifications
allow us to build best practices and guidelines but they are currently
treated as recommendations.  If we could develop a way to make some of the
more critical needs a requirement vs. recommendation then we could have a
way to ensure that we have a way inside the community to drive
architectural changes, as necessary, for better system stability, user
experience, or performance.  The other benefit would be to agree on common
needs (e.g. the quota service discussion happening right now, the online
schema migration work that has taken place in a lot of projects) and guide
new projects through adopting the changes as they start development rather
than retrofit.

   * Increase user and technical committee exchanges

   - I would like to propose a regular cadence to discussions between
the technical and user committee members so that technical direction, and
decision points, can be shared and we could strengthen/expedite feedback
from our user community into process as needed.  I have seen both parties
appreciate the dialogue and find it valuable, therefore I think anything
that can strengthen this feedback loop is a positive thing.

   * Building an ecosystem for next-generation platforms

   - Over the last couple of years there have been multiple
complementary open-source projects/technologies that are catering to
similar application design patterns (Mesos, k8s, Cloud Foundry, etc,).  I
believe projects such as Kuryr are doing a good job in mapping OpenStack
technologies like neutron to other ecosystems (e.g Docker libnetwork) and
we should continue to solicit more projects/activity that will help
customers/users build an internal platform that meets their objectives as
they shift from traditional applications to newer applications.  In the
end, we are all trying to meet user needs and the answer probably lies in a
complementary view of adjacent technologies versus every need being
implemented by a single platform.  A successful approach to building an
ecosystem for OpenStack clouds could dramatically increase putting our code
to work through an even greater adoption rate and make OpenStack clouds
viable for additional workloads/use-cases.

My reason for focusing on these topics is based on my experience and
background in the OpenStack community.  I am a core member of the Product
working group[2], participate regularly in the ops-tags-team[3], help with
SuperuserTV[4], help with building the community-generated OpenStack
roadmap[5], and moderate sessions at ops-meetups.

I am passionate about the work our community produces and excited that it
has found relevance for so many people and organizations around the globe.
I would like to continue to do work that further strengthens the feedback
loop between the developers and consumers of our open-source cloud.  I
humbly ask for your vote to represent this need as a member of our
OpenStack Technical Committee.


[1] https://review.openstack.org/#/q/owner:ItzShamail%2540gmail.com

[2] https://wiki.openstack.org/wiki/ProductTeam

[3] https://review.openstack.org/#/q/project:openstack/ops-tags-team

[4] 

[openstack-dev] [election][TC] TC Candidacy

[Edward Leafe]

Greetings!

I am announcing my candidacy for the OpenStack Technical Committee. As a 
long-time developer, I have been part of projects that have succeeded and 
others that have not; in either event, I always learned something to apply to 
the next endeavor. I would like to use that experience to help guide OpenStack 
forward as part of the TC.

For those who may not know me, my name is Ed Leafe (edleafe on IRC), and I have 
been involved in OpenStack since the very beginning as part of the original 
Nova team. I am currently employed by IBM to work 100% of my time on upstream 
OpenStack, so I would have the freedom to devote as much time as needed to my 
TC duties. I have been participating in the TC meetings for over a year, and am 
familiar with the issues that come before it. I believe that I could contribute 
a lot more as a member of the TC, and that's why I'm asking for your vote.

Here are some of the issues that I would like to focus on:

* Adding clarity to the Big Tent

Opening up the OpenStack world to projects without having to go through the 
incubation and co-gating requirements was a huge step forward, but the feedback 
I've heard about the resulting mix is that it is confusing. A few months ago 
the TC added the 'starter-kit' tag to the baseline projects you would need to 
install to get OpenStack running; this was a good first step, but I think we 
need is a way to separate the "guts" of OpenStack from the parts that are built 
on top of that core. Is a project part of OpenStack itself? Or is it something 
that works on top of OpenStack (or any other cloud)? I'd like to see projects 
clearly separated into those that provide 'cloud' services, and those that work 
with those cloud pieces to make them easier to deploy/manage/report. Why is 
this distinction important? Because I feel that OpenStack should only have a 
single project for any particular service, and if someone has an idea for 
making it better, they need to work with the existing project, not compete. But 
in the world of projects built on top of OpenStack services, I say let's invite 
competition! There doesn't have to be a single "winner", as these will more 
likely tend to be solving particular use cases. Forcing these to be in a single 
project usually results in bloated, inefficient code.

* Improving the user experience

Part of my current job is mentoring fellow IBMers who are new to OpenStack in 
what it is, how to use it, etc. Have you ever tried to explain how to set up 
and configure OpenStack to anyone? Then you know just how difficult it is. 
That's one of the reasons I have been involved in groups such as the API 
working group, the Nova API team, and the Configuration Option cleanup efforts, 
as they represent places where OpenStack needs improvement. The recent efforts 
to open dialogs between ops and devs is a great start, and I'd certainly like 
to build on that. As a TC member, I would promote efforts to make all of 
OpenStack more manageable to deploy and maintain, since the coolest software in 
the world is useless if people can't get it running.

* Promoting consistency across OpenStack projects

There is some inconsistency within a single project like Nova, but when you 
work with multiple projects, the inconsistencies are glaring. And while the TC 
is not a strong-arm enforcer of standards, it does have considerable influence 
on how projects evolve, and I would like to see the TC push harder at 
establishing standards, as the API Working Group is doing, and then encouraging 
adoption of those standards across projects. The sanity of our operators is at 
stake!

In closing, I'd like to say that anyone who cares enough about OpenStack to 
want to be a part of the TC will certainly be worth your vote. I hope that I've 
presented enough to earn your vote.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [election][TC] TC Candidacy

[Chris Dent]

Hello,

A few weeks ago I made a [blog posting][1] in which I wrote about the
issues I would consider important to address if I were a member of the
Technical Committee. Several people encouraged me to act on my concerns
and actually run.

[1]: https://anticdent.org/if-i-were-on-the-openstack-tc.html

Therefore, I'd like to submit my candidacy for election to the Technical
Committee. I think the health of the TC and OpenStack in general is
dependent on a diversity of strong opinions from people who are willing
to be convinced they may be incorrect. I like to think I have plenty of
opinions. I am eager to have the interactions that will weaken some
opinions and strengthen others.

To summarize the blog posting linked above: I am concerned with not just
maintaining but increasing the quality of the OpenStack experience for
the people who install and use it and, critically, for the people who
build it. To achieve this we need to have a clear idea about what
OpenStack is and who it is for. Trying to be everything to all people
results in diffuse effort and difficulty making decisions when,
inevitably, compromises and sacrifices must be made in our resource
constrained world.

By being more clear to ourselves and others about what OpenStack is we
can be more effective about what we are doing and more useful when
building bridges with other communities.

In practical terms this will require determining the constraints on
the big tent. I expect this will be the major work of the TC in the
immediate future and I'd like to be a part of it as a representative of
the community.

If you have specific questions about my goals, my background or anything
else, please feel free to ask. I'm on IRC as cdent or send some email.
Thank you for your consideration.

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://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] [election] [tc] TC candidacy

[Thierry Carrez]

Monty Taylor wrote:

On 03/28/2016 06:09 PM, joehuang wrote:

One question about this  ' The transition to the "big tent" governance
model is now finished, with all the expected projects now officially
part of the OpenStack community. The big tent is all about community:
answering the "are you one of us" question.'.

Does it mean that no more project will be approved to be a big tent
project in the Newton and Ocata release?


No - I believe that Thierry was trying to say we've finished our
governance transition so that now we apply the new criteria when we add
projects to the Big Tent.


Right. My point was: initially there was a lot of catch-up to do, as a 
lot of projects previously in Stackforge qualified under the new 
criteria and had to apply and be processed. I think we are done with 
that backlog now, and back to normal frequency of project additions.


--
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-dev] [election][TC] TC Candidacy

[Davanum Srinivas]

Fellow Stackers,

I would like to announce my candidacy for the OpenStack Technical Committee
election.

Currently i am employed by Mirantis and take manage a couple teams, one working
primarily on Oslo/RabbitMQ/ZMQ and the other on Keystone. My other job is
contributing upstream where i can including several Oslo projects, Nova,
Requirements and Release team. I have served as PTL for Oslo for the last
two terms and am proud of our accomplishments including getting rid of the
oslo-incubator, building up our test matrix for better backwards compatibility
testing and increasing the number of people invested in different Oslo projects.

We have a lot of challenges including figuring out how to balance
stability/innovation, fostering new talent, target our limited resources
to make OpenStack even better than it is today. I would like to offer some
ideas as part of the technical committee based on my previous experiences
at ASF, a startup, working at Big Blue etc.

While working on Oslo as PTL, gave me a lot of insight into how different
projects go about their work. Being part of the Requirements and Release
team has helped me understand the day-to-day challenges of how we pull in
different directions but still end up moving forward. Spending time looking
at gate issues and setting up CI jobs has given me a lot of appreciation
around how many things there are we could work on and fix. As part of
the technical committee, i am hoping to help with:

- Cross Project issues, increasing collaboration between projects
- Backwards compatibility issues and testing
- Evangelizing great ideas from different projects

Starting with @markmc, @sdague, @dhellmann and a whole of of others i have
received a lot of support and guidance over the years. I would like to
pay it forward for the new set of folks who are coming, learning
our ways and becoming part of our community.

Thanks,
Dims

Review history: https://review.openstack.org/#/q/reviewer:dims-v,n,z
Commit history: https://review.openstack.org/#/q/owner:dims-v,n,z
Stackalytics: http://stackalytics.com/?user_id=dims-v
OpenHUB: https://www.openhub.net/accounts/davanum
Freenode: dims




-- 
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] [election] [tc] TC candidacy

[Monty Taylor]

On 03/28/2016 06:09 PM, joehuang wrote:

Hi, Thierry,

One question about this  ' The transition to the "big tent" governance model is now 
finished, with all the expected projects now officially part of the OpenStack community. The big 
tent is all about community: answering the "are you one of us" question.'.

Does it mean that no more project will be approved to be a big tent project in 
the Newton and Ocata release?


No - I believe that Thierry was trying to say we've finished our 
governance transition so that now we apply the new criteria when we add 
projects to the Big Tent.



Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org]
Sent: Monday, March 28, 2016 11:53 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [election] [tc] TC candidacy

(This was also submitted as https://review.openstack.org/#/c/298294)

Hi everyone,

I'd like to submit my candidacy for reelection on the Technical Committee. For those who 
don't know me yet, my name is Thierry Carrez, I use "ttx" as my IRC nickname. 
I'm currently employed by the OpenStack Foundation as its Director of Engineering, which 
basically means I'm running the team in charge of ensuring the long-term health of the 
upstream OpenStack open source project and its governance. Handling the Technical 
Committee is my primary activity: 6 months ago I left the PTL role for the Release 
Management Team in order to be able to focus as much as possible on the TC.

One year ago I ran for election with the goal of having the TC "step out of the way"[1]. 
The idea was to remove the TC from the critical path of getting things done, and encourage a 
"ask for forgiveness, rather than permission" attitude in our community. I like to think 
we were successful at this. Project teams can now more easily add git repositories as they need 
them, they also end up asserting some tags by themselves, and the TC has generally moved to being 
an appeals board in case of disputes, rather than a procedural barrier in getting things done.

Here are the three priorities for my upcoming mandate, if the electorate 
chooses to reelect me to the TC:

1/ Cleaning up the big tent

The transition to the "big tent" governance model is now finished, with all the expected projects 
now officially part of the OpenStack community. The big tent is all about community: answering the "are 
you one of us" question. Our approach there was to be inclusive and assume good faith, especially as we 
caught up on documenting what we meant by "the OpenStack Way". Over the past year we created the 
Project Team Guide[2], which clearly explains what is expected of official project teams. I think it's time 
for us to look back at all those projects we have in the tent, reach out to those who are lacking, and not 
hesitate to remove the ones that are not following our common community practices from the list of official 
project teams. Demoting a project used to be particularly painful, with costly git repository renames crating 
disruption on the demoted projects. But now that all projects hosted under our infrastructure (official and 
unofficial) use the same namespace, this cost and di

s
ruption are very limited, so cleaning up the big tent is now possible.


2/ Defining the limits of the big tent

The TC recently had two project team applications for which we had no good 
answer: Poppy and Tacker. Those resulted in close (and somewhat
arbitrary) votes as each TC member tried to interpret the mission statement words and 
what we stand for. In the case of Poppy, there was the question of whether a service that 
proxies to non-OpenStack commercial services could be considered part of 
"OpenStack", without an open source reference implementation to do end-to-end 
testing against.
In the case of Tacker, there was the question of a service standing on top of other OpenStack 
services to present a domain-specific API tailored to a specific use case or industry. Should that 
still be "OpenStack", or just something that consumes OpenStack ? I'd like the TC to take 
a step back and explore those two questions, without the pressure of a specific project team 
addition. Clarifying the rules may result in some official projects to be demoted to 
"unofficial" status as they would not fit the rules anymore.

3/ Launching the new separated event for project team members

We recently started the discussion[3] on splitting the "design summit"
into wider community feedback / requirements-gathering sessions (that would 
happen at the main Summit) and a specific event for project team members to 
gather in a co-located venue to come up with a plan and organize its execution. 
We still have a long way to go (and not that much time) to discuss the format 
and the timing of this new event, and I expect the Newt

Re: [openstack-dev] [election] [tc] TC candidacy

[joehuang]

Hi, Thierry,

One question about this  ' The transition to the "big tent" governance model is 
now finished, with all the expected projects now officially part of the 
OpenStack community. The big tent is all about community: answering the "are 
you one of us" question.'. 

Does it mean that no more project will be approved to be a big tent project in 
the Newton and Ocata release?

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org] 
Sent: Monday, March 28, 2016 11:53 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [election] [tc] TC candidacy

(This was also submitted as https://review.openstack.org/#/c/298294)

Hi everyone,

I'd like to submit my candidacy for reelection on the Technical Committee. For 
those who don't know me yet, my name is Thierry Carrez, I use "ttx" as my IRC 
nickname. I'm currently employed by the OpenStack Foundation as its Director of 
Engineering, which basically means I'm running the team in charge of ensuring 
the long-term health of the upstream OpenStack open source project and its 
governance. Handling the Technical Committee is my primary activity: 6 months 
ago I left the PTL role for the Release Management Team in order to be able to 
focus as much as possible on the TC.

One year ago I ran for election with the goal of having the TC "step out of the 
way"[1]. The idea was to remove the TC from the critical path of getting things 
done, and encourage a "ask for forgiveness, rather than permission" attitude in 
our community. I like to think we were successful at this. Project teams can 
now more easily add git repositories as they need them, they also end up 
asserting some tags by themselves, and the TC has generally moved to being an 
appeals board in case of disputes, rather than a procedural barrier in getting 
things done.

Here are the three priorities for my upcoming mandate, if the electorate 
chooses to reelect me to the TC:

1/ Cleaning up the big tent

The transition to the "big tent" governance model is now finished, with all the 
expected projects now officially part of the OpenStack community. The big tent 
is all about community: answering the "are you one of us" question. Our 
approach there was to be inclusive and assume good faith, especially as we 
caught up on documenting what we meant by "the OpenStack Way". Over the past 
year we created the Project Team Guide[2], which clearly explains what is 
expected of official project teams. I think it's time for us to look back at 
all those projects we have in the tent, reach out to those who are lacking, and 
not hesitate to remove the ones that are not following our common community 
practices from the list of official project teams. Demoting a project used to 
be particularly painful, with costly git repository renames crating disruption 
on the demoted projects. But now that all projects hosted under our 
infrastructure (official and unofficial) use the same namespace, this cost and 
disr
 uption are very limited, so cleaning up the big tent is now possible.

2/ Defining the limits of the big tent

The TC recently had two project team applications for which we had no good 
answer: Poppy and Tacker. Those resulted in close (and somewhat
arbitrary) votes as each TC member tried to interpret the mission statement 
words and what we stand for. In the case of Poppy, there was the question of 
whether a service that proxies to non-OpenStack commercial services could be 
considered part of "OpenStack", without an open source reference implementation 
to do end-to-end testing against. 
In the case of Tacker, there was the question of a service standing on top of 
other OpenStack services to present a domain-specific API tailored to a 
specific use case or industry. Should that still be "OpenStack", or just 
something that consumes OpenStack ? I'd like the TC to take a step back and 
explore those two questions, without the pressure of a specific project team 
addition. Clarifying the rules may result in some official projects to be 
demoted to "unofficial" status as they would not fit the rules anymore.

3/ Launching the new separated event for project team members

We recently started the discussion[3] on splitting the "design summit" 
into wider community feedback / requirements-gathering sessions (that would 
happen at the main Summit) and a specific event for project team members to 
gather in a co-located venue to come up with a plan and organize its execution. 
We still have a long way to go (and not that much time) to discuss the format 
and the timing of this new event, and I expect the Newton membership of the TC 
to help with taking quick decisions there. The next step here will be a 
cross-project workshop at the Design Summit in Austin to discuss the current 
plan and go deeper in the details.

[openstack-dev] [election] [tc] TC candidacy

[Thierry Carrez]

(This was also submitted as https://review.openstack.org/#/c/298294)

Hi everyone,

I'd like to submit my candidacy for reelection on the Technical 
Committee. For those who don't know me yet, my name is Thierry Carrez, I 
use "ttx" as my IRC nickname. I'm currently employed by the OpenStack 
Foundation as its Director of Engineering, which basically means I'm 
running the team in charge of ensuring the long-term health of the 
upstream OpenStack open source project and its governance. Handling the 
Technical Committee is my primary activity: 6 months ago I left the PTL 
role for the Release Management Team in order to be able to focus as 
much as possible on the TC.


One year ago I ran for election with the goal of having the TC "step out 
of the way"[1]. The idea was to remove the TC from the critical path of 
getting things done, and encourage a "ask for forgiveness, rather than 
permission" attitude in our community. I like to think we were 
successful at this. Project teams can now more easily add git 
repositories as they need them, they also end up asserting some tags by 
themselves, and the TC has generally moved to being an appeals board in 
case of disputes, rather than a procedural barrier in getting things done.


Here are the three priorities for my upcoming mandate, if the electorate
chooses to reelect me to the TC:

1/ Cleaning up the big tent

The transition to the "big tent" governance model is now finished, with 
all the expected projects now officially part of the OpenStack 
community. The big tent is all about community: answering the "are you 
one of us" question. Our approach there was to be inclusive and assume 
good faith, especially as we caught up on documenting what we meant by 
"the OpenStack Way". Over the past year we created the Project Team 
Guide[2], which clearly explains what is expected of official project 
teams. I think it's time for us to look back at all those projects we 
have in the tent, reach out to those who are lacking, and not hesitate 
to remove the ones that are not following our common community practices 
from the list of official project teams. Demoting a project used to be 
particularly painful, with costly git repository renames crating 
disruption on the demoted projects. But now that all projects hosted 
under our infrastructure (official and unofficial) use the same 
namespace, this cost and disruption are very limited, so cleaning up the 
big tent is now possible.


2/ Defining the limits of the big tent

The TC recently had two project team applications for which we had no 
good answer: Poppy and Tacker. Those resulted in close (and somewhat 
arbitrary) votes as each TC member tried to interpret the mission 
statement words and what we stand for. In the case of Poppy, there was 
the question of whether a service that proxies to non-OpenStack 
commercial services could be considered part of "OpenStack", without an 
open source reference implementation to do end-to-end testing against. 
In the case of Tacker, there was the question of a service standing on 
top of other OpenStack services to present a domain-specific API 
tailored to a specific use case or industry. Should that still be 
"OpenStack", or just something that consumes OpenStack ? I'd like the TC 
to take a step back and explore those two questions, without the 
pressure of a specific project team addition. Clarifying the rules may 
result in some official projects to be demoted to "unofficial" status as 
they would not fit the rules anymore.


3/ Launching the new separated event for project team members

We recently started the discussion[3] on splitting the "design summit" 
into wider community feedback / requirements-gathering sessions (that 
would happen at the main Summit) and a specific event for project team 
members to gather in a co-located venue to come up with a plan and 
organize its execution. We still have a long way to go (and not that 
much time) to discuss the format and the timing of this new event, and I 
expect the Newton membership of the TC to help with taking quick 
decisions there. The next step here will be a cross-project workshop at 
the Design Summit in Austin to discuss the current plan and go deeper in 
the details.


Those are my three priorities for Newton and Ocata, and this is what 
I'll push the Technical Committee towards if I'm elected.


Thank you all for your consideration !

[1] http://ttx.re/stepping-out-of-the-way.html
[2] http://docs.openstack.org/project-team-guide/
[3] http://ttx.re/splitting-out-design-summit.html

--
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] [election][TC] TC Candidacy

[Mike Perez]

On 09:29 Mar 25, Mike Perez wrote:
> Hi all!
> 
> I Mike Perez aka. thingee, am announcing my candidacy for a position in the
> OpenStack Technical Committee. You can find my submitted candidacy which is
> still under review here https://review.openstack.org/297748
> 
> I am employed by the OpenStack Foundation as a Developer Coordinator to help
> bring focus/support to cross-project initiatives via the cross-project
> specs, Def Core, The Product Working group, etc.
> 
> I feel the items below have enabled others across this project to strive for
> quality. If you would all have me as a member of the Technical Committee, you
> can help me to enable more quality work in OpenStack.
> 
> * I have been working in OpenStack since 2010. I spent a good amount of my 
> time
>   working on OpenStack in my free time before being paid full time to work on
>   it. It has been an important part of my life, and rewarding to see what we
>   have all achieved together.
> 
> * I was PTL for the Cinder project in the Kilo and Liberty releases.
> 
> * I led the effort in bringing third party continuous integration to the
>   Cinder project for more than 60 different drivers. [1]
>   * I removed 25 different storage drivers from Cinder to bring quality to the
> project to ensure what was in the Kilo release would work for operators.
> I did what I believed was right, regardless of whether it would cost me
> re-election for PTL [2].
>   * See epic thread on this once deadline happened [3]
>   * In my conversations with other projects, this has enabled others to want 
> to
> follow the same effort.
> - Ironic now has a road map for doing third-party CI. [4][5]
> 
> * I have attempted to help with diversity in our community, and I think it's
>   great to have people in the committee that views this as a priority.
>   - Helped lead our community to raise $17,403 for the Ada Initiative [6],
> which was helping address gender-diversity with a focus in open source.
>   - For the Vancouver summit, I helped bring in the ally skills workshops from
> the Ada Initiative, so that our community can continue to be a welcoming
> environment [4].
>   - I have assisted Emily Hugenbruch with the OpenStack mentor program [7].
>   - Based on some of the surveys the diversity working group has been doing,
> OpenStack's tool chain of IRC, gerrit, and git was expressed as being
> difficult to get started with. I started writing documentation to provide
> step-by-step with screen shots to help improve our on-boarding experience
> [8].
> 
> * I started the OpenStack Mailing List Digest, in order to enable others to
>   keep up with the dev list on important information. [9][10]
> 
> * When Open Core was being discussed by the TC, numerous times I spoke to the
>   TC about my disagreements with accepting projects in OpenStack's big tent if
>   testing is only possible with a commercial entity. [11][12] I believe
>   OpenStack service APIs should be based off an open source reference
>   implementation that we're able to do integration tests with in gate. Anyone
>   who begins to play with OpenStack should be able to run OpenStack with full
>   features without a commercial entity/driver.
>   - See my discussions with the TC in their meeting in raising quality and
> being able to fully test projects we're considering in accepting in the 
> big
> tent [13].
> 
> * I have properly established the cross-project team [14] as well as the
>   members that represent each OpenStack project [15].
> 
> 
> As a TC member I want to bring focus in some areas:
> 
> 1) Installation Documentation - I think all projects in the big tent should
>have installation documentation. In order for projects to gain adoption and
>gather better feedback, operators need to know how to install things. Today
>majority of projects in the big tent have no installation documentation,
>some which have existed for more than three years and still nothing. Where
>are these projects going? In addition I want to make all new projects
>entering the big tent come with clear documentation for installation. See
>the beginning discussions I'm starting here [16].
> 
> 2) As expressed in the earlier point, there are some projects in the big tent
>that seem to have no clear direction and are lacking adoption after 
> existing
>for years in the community. I'd like to work with these projects and see 
> how
>we can move things forward to gain maturity, and some to be accepted in 
> with
>Defcore and refstack. Otherwise I think these projects should be 
> reevaluated
>in the value they're bringing to the big tent. This won't be easy, but it
>needs to be done to make sure community focus and resources we use from the
>Infra team is spent well. See the TC discussing CI resources VS project
>growth [17].
> 
> 3) As expressed in the earlier point, Defcore plays a role in helping us 
> define

[openstack-dev] [election][TC] TC Candidacy

[Mike Perez]

Hi all!

I Mike Perez aka. thingee, am announcing my candidacy for a position in the
OpenStack Technical Committee. You can find my submitted candidacy which is
still under review here https://review.openstack.org/297748

I am employed by the OpenStack Foundation as a Developer Coordinator to help
bring focus/support to cross-project initiatives via the cross-project
specs, Def Core, The Product Working group, etc.

I feel the items below have enabled others across this project to strive for
quality. If you would all have me as a member of the Technical Committee, you
can help me to enable more quality work in OpenStack.

* I have been working in OpenStack since 2010. I spent a good amount of my time
  working on OpenStack in my free time before being paid full time to work on
  it. It has been an important part of my life, and rewarding to see what we
  have all achieved together.

* I was PTL for the Cinder project in the Kilo and Liberty releases.

* I led the effort in bringing third party continuous integration to the
  Cinder project for more than 60 different drivers. [1]
  * I removed 25 different storage drivers from Cinder to bring quality to the
project to ensure what was in the Kilo release would work for operators.
I did what I believed was right, regardless of whether it would cost me
re-election for PTL [2].
  * See epic thread on this once deadline happened [3]
  * In my conversations with other projects, this has enabled others to want to
follow the same effort.
- Ironic now has a road map for doing third-party CI. [4][5]

* I have attempted to help with diversity in our community, and I think it's
  great to have people in the committee that views this as a priority.
  - Helped lead our community to raise $17,403 for the Ada Initiative [6],
which was helping address gender-diversity with a focus in open source.
  - For the Vancouver summit, I helped bring in the ally skills workshops from
the Ada Initiative, so that our community can continue to be a welcoming
environment [4].
  - I have assisted Emily Hugenbruch with the OpenStack mentor program [7].
  - Based on some of the surveys the diversity working group has been doing,
OpenStack's tool chain of IRC, gerrit, and git was expressed as being
difficult to get started with. I started writing documentation to provide
step-by-step with screen shots to help improve our on-boarding experience
[8].

* I started the OpenStack Mailing List Digest, in order to enable others to
  keep up with the dev list on important information. [9][10]

* When Open Core was being discussed by the TC, numerous times I spoke to the
  TC about my disagreements with accepting projects in OpenStack's big tent if
  testing is only possible with a commercial entity. [11][12] I believe
  OpenStack service APIs should be based off an open source reference
  implementation that we're able to do integration tests with in gate. Anyone
  who begins to play with OpenStack should be able to run OpenStack with full
  features without a commercial entity/driver.
  - See my discussions with the TC in their meeting in raising quality and
being able to fully test projects we're considering in accepting in the big
tent [13].

* I have properly established the cross-project team [14] as well as the
  members that represent each OpenStack project [15].


As a TC member I want to bring focus in some areas:

1) Installation Documentation - I think all projects in the big tent should
   have installation documentation. In order for projects to gain adoption and
   gather better feedback, operators need to know how to install things. Today
   majority of projects in the big tent have no installation documentation,
   some which have existed for more than three years and still nothing. Where
   are these projects going? In addition I want to make all new projects
   entering the big tent come with clear documentation for installation. See
   the beginning discussions I'm starting here [16].

2) As expressed in the earlier point, there are some projects in the big tent
   that seem to have no clear direction and are lacking adoption after existing
   for years in the community. I'd like to work with these projects and see how
   we can move things forward to gain maturity, and some to be accepted in with
   Defcore and refstack. Otherwise I think these projects should be reevaluated
   in the value they're bringing to the big tent. This won't be easy, but it
   needs to be done to make sure community focus and resources we use from the
   Infra team is spent well. See the TC discussing CI resources VS project
   growth [17].

3) As expressed in the earlier point, Defcore plays a role in helping us define
   a set tests that will be ran against deployed OpenStack clouds interested in
   using the trademark. I'd like to continue working with both individual
   projects and Defcore/refstack in seeing if it's possible to make other
   

Re: [openstack-dev] [election][TC] TC Candidacy

[Barrett, Carol L]

Mike - Congrats on your new position! Looking forward to working with you.
Carol

-Original Message-
From: Mike Perez [mailto:thin...@gmail.com] 
Sent: Wednesday, September 30, 2015 1:55 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [election][TC] TC Candidacy

Hi all!

I'm announcing my candidacy for a position on the OpenStack Technical Committee.

On October 1st I will be employed by the OpenStack Foundation as a 
Cross-Project Developer Coordinator to help bring focus and support to 
cross-project initiatives within the cross-project specs, Def Core, The Product 
Working group, etc.

I feel the items below have enabled others across this project to strive for 
quality. If you would all have me as a member of the Technical Committee, you 
can help me to enable more quality work in OpenStack.

* I have been working in OpenStack since 2010. I spent a good amount of my time
  working on OpenStack in my free time before being paid full time to work on
  it. It has been an important part of my life, and rewarding to see what we
  have all achieved together.

* I was PTL for the Cinder project in the Kilo and Liberty releases for two
  cross-project reasons:
  * Third party continuous integration (CI).
  * Stop talking about rolling upgrades, and actually make it happen for
operators.

* I led the effort in bringing third party continuous integration to the
  Cinder project for more than 60 different drivers. [1]
  * I removed 25 different storage drivers from Cinder to bring quality to the
project to ensure what was in the Kilo release would work for operators.
I did what I believed was right, regardless of whether it would cost me
re-election for PTL [2].
  * In my conversations with other projects, this has enabled others to
follow the same effort. Continuing this trend of quality cross-project will
be my next focus.

* During my first term of PTL for Cinder, the team, and much respect to Thang
  Pham working on an effort to end the rolling upgrade problem, not just for
  Cinder, but for *all* projects.
  * First step was making databases independent from services via Oslo
versioned objects.
  * In Liberty we have a solution coming that helps with RPC versioned messages
to allow upgrading services independently.

* I have attempted to help with diversity in our community.
  * Helped lead our community to raise $17,403 for the Ada Initiative [3],
which was helping address gender-diversity with a focus in open source.
  * For the Vancouver summit, I helped bring in the ally skills workshops from
the Ada Initiative, so that our community can continue to be a welcoming
environment [4].

* Within the Cinder team, I have enabled all to provide good documentation for
  important items in our release notes in Kilo [5] and Liberty [6].
  * Other projects have reached out to me after Kilo feeling motivated for this
same effort. I've explained in the August 2015 Operators midcycle sprint
that I will make this a cross-project effort in order to provide better
communication to our operators and users.

* I started an OpenStack Dev List summary in the OpenStack Weekly Newsletter
  (What you need to know from the developer's list), in order to enable others
  to keep up with the dev list on important cross-project information. [7][8]

* I created the Cinder v2 API which has brought consistency in
  request/responses with other OpenStack projects.
  * I documented Cinder v1 and Cinder v2 API's. Later on I created the Cinder
API reference documentation content. The attempt here was to enable others
to have somewhere to start, to continue quality documentation with
continued developments.

Please help me to do more positive work in this project. It would be an honor 
to be member of your technical committee.


Thank you,
Mike Perez

Official Candidacy: https://review.openstack.org/#/c/229298/2
Review History: https://review.openstack.org/#/q/reviewer:170,n,z
Commit History: https://review.openstack.org/#/q/owner:170,n,z
Stackalytics: http://stackalytics.com/?user_id=thingee
Foundation: https://www.openstack.org/community/members/profile/4840
IRC Freenode: thingee
Website: http://thing.ee


[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054614.html
[2] - 
https://review.openstack.org/#/q/status:merged+project:openstack/cinder+branch:master+topic:cinder-driver-removals,n,z
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-October/047892.html
[4] - http://lists.openstack.org/pipermail/openstack-dev/2015-May/064156.html
[5] - 
https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#OpenStack_Block_Storage_.28Cinder.29
[6] - 
https://wiki.openstack.org/wiki/ReleaseNotes/Liberty#OpenStack_Block_Storage_.28Cinder.29
[7] - 
http://www.openstack.org/blog/2015/09/openstack-community-weekly-newsletter-sept-12-18/
[8] - 
http://www.openstack.org/blog/2015/09/openstack-weekly-community-newsletter-sept-19-25

[openstack-dev] [election][TC] TC Candidacy

[Joshua Harlow]

Hi folks,

I'd like to propose my candidacy for the technical committee
elections.

I've been involved in OpenStack for around ~four~ years now, working
to help integrate it into various Yahoo! systems and infrastructure.
I've been involved with integration and creation (and maturation) of
many projects (and libraries); for example rpm and venv packaging (via
anvil), cloud-init (a related tool), doc8 (a doc checking tool),
taskflow (an oslo library), tooz (an oslo library), automaton (an oslo
library), kazoo (a dependent library) and more.

As mentioned above, my contributions to OpenStack have been at the
project and library level. My experience in oslo (a group of
folks that specialize in cross-project libraries and reduction of
duplication across projects) has helped me grow and gain knowledge
about how to work across various projects. Now I would like to help
OpenStack projects become ~more~ excellent technically. I'd like to
be able  to leverage (and share) the experience I have gained at
Yahoo! to help make OpenStack that much better (we have tens of
thousands of VMs and thousands of hypervisors, tens of
thousands of baremetal instances split across many clusters with
varying network topology and layout).

I'd like to join the TC to aid some of the on-going work that helps
overhaul pieces of OpenStack to make them more scalable, more fault
tolerant, and in all honesty more ~modern~. I believe we (as a TC)
need to perform ~more~ outreach to projects and provide more advice
and guidance with respect to which technologies will help them scale
in the long term (for example instead of reinventing service discovery
solutions and/or distributed locking, use other open source solutions
that provide it already in a battle-hardened manner) proactively
instead of reactively.

I believe some of this can be solved by trying to make sure the TC is
on-top of: https://review.openstack.org/#/q/status:open+project:openstack
/openstack-specs,n,z and ensuring proposed/accepted cross-project
initiatives do not linger. (I'd personally rather have a cross-project
spec be reviewed and marked as not applicable vs. having a spec
linger.)

In summary, I would like to focus on helping this outreach and
involvement become better (and yes some of that outreach goes beyond
the OpenStack community), helping get OpenStack projects onto scalable
solutions (where applicable) and help make OpenStack become a cloud
solution that can work well for all (instead of work well for small
clouds and not work so well for large ones). Of course on-going
efforts need to conclude (tags for example) first but I hope that as a
TC member I can help promote work on OpenStack that helps the long
term technical sustainability (at small and megascale) of OpenStack
become better.

TLDR; work on getting TC to get more involved with the technical
outreach of OpenStack; reduce focus on approving projects and tags
and hopefully work to help the focus become on the long term technical
sustainability of OpenStack (at small and megascale); using my own
experiences to help in this process //

Thanks for considering me,

Joshua Harlow

--

Yahoo!

http://stackalytics.com/report/users/harlowja

Official submission @ https://review.openstack.org/229591

__
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] [election][TC] TC Candidacy

[Mike Perez]

Hi all!

I'm announcing my candidacy for a position on the OpenStack Technical
Committee.

On October 1st I will be employed by the OpenStack Foundation as
a Cross-Project Developer Coordinator to help bring focus and support to
cross-project initiatives within the cross-project specs, Def Core, The Product
Working group, etc.

I feel the items below have enabled others across this project to strive for
quality. If you would all have me as a member of the Technical Committee, you
can help me to enable more quality work in OpenStack.

* I have been working in OpenStack since 2010. I spent a good amount of my time
  working on OpenStack in my free time before being paid full time to work on
  it. It has been an important part of my life, and rewarding to see what we
  have all achieved together.

* I was PTL for the Cinder project in the Kilo and Liberty releases for two
  cross-project reasons:
  * Third party continuous integration (CI).
  * Stop talking about rolling upgrades, and actually make it happen for
operators.

* I led the effort in bringing third party continuous integration to the
  Cinder project for more than 60 different drivers. [1]
  * I removed 25 different storage drivers from Cinder to bring quality to the
project to ensure what was in the Kilo release would work for operators.
I did what I believed was right, regardless of whether it would cost me
re-election for PTL [2].
  * In my conversations with other projects, this has enabled others to
follow the same effort. Continuing this trend of quality cross-project will
be my next focus.

* During my first term of PTL for Cinder, the team, and much respect to Thang
  Pham working on an effort to end the rolling upgrade problem, not just for
  Cinder, but for *all* projects.
  * First step was making databases independent from services via Oslo
versioned objects.
  * In Liberty we have a solution coming that helps with RPC versioned messages
to allow upgrading services independently.

* I have attempted to help with diversity in our community.
  * Helped lead our community to raise $17,403 for the Ada Initiative [3],
which was helping address gender-diversity with a focus in open source.
  * For the Vancouver summit, I helped bring in the ally skills workshops from
the Ada Initiative, so that our community can continue to be a welcoming
environment [4].

* Within the Cinder team, I have enabled all to provide good documentation for
  important items in our release notes in Kilo [5] and Liberty [6].
  * Other projects have reached out to me after Kilo feeling motivated for this
same effort. I've explained in the August 2015 Operators midcycle sprint
that I will make this a cross-project effort in order to provide better
communication to our operators and users.

* I started an OpenStack Dev List summary in the OpenStack Weekly Newsletter
  (What you need to know from the developer's list), in order to enable others
  to keep up with the dev list on important cross-project information. [7][8]

* I created the Cinder v2 API which has brought consistency in
  request/responses with other OpenStack projects.
  * I documented Cinder v1 and Cinder v2 API's. Later on I created the Cinder
API reference documentation content. The attempt here was to enable others
to have somewhere to start, to continue quality documentation with
continued developments.

Please help me to do more positive work in this project. It would be an
honor to be member of your technical committee.


Thank you,
Mike Perez

Official Candidacy: https://review.openstack.org/#/c/229298/2
Review History: https://review.openstack.org/#/q/reviewer:170,n,z
Commit History: https://review.openstack.org/#/q/owner:170,n,z
Stackalytics: http://stackalytics.com/?user_id=thingee
Foundation: https://www.openstack.org/community/members/profile/4840
IRC Freenode: thingee
Website: http://thing.ee


[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054614.html
[2] - 
https://review.openstack.org/#/q/status:merged+project:openstack/cinder+branch:master+topic:cinder-driver-removals,n,z
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-October/047892.html
[4] - http://lists.openstack.org/pipermail/openstack-dev/2015-May/064156.html
[5] - 
https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#OpenStack_Block_Storage_.28Cinder.29
[6] - 
https://wiki.openstack.org/wiki/ReleaseNotes/Liberty#OpenStack_Block_Storage_.28Cinder.29
[7] - 
http://www.openstack.org/blog/2015/09/openstack-community-weekly-newsletter-sept-12-18/
[8] - 
http://www.openstack.org/blog/2015/09/openstack-weekly-community-newsletter-sept-19-25/

__
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] [election] [TC] TC Candidacy

[Edgar Magana]

Hello Developers and Community,

I would like to submit my candidacy for the TC election.

I have been involved in OpenStack activities since April 2011, when I became
part one of the founders of the networking project known as Quantum at that
time. I have been a core reviewer for Neutron since November 2011. I helped
to create the networking guide and contributed to multiple chapters. I have
spoken at many OpenStack summits, meet-ups and conferences. I have been very
active in the Operators meet-up moderating multiple sessions. In few words
"I love to evangelize OpenStack".

Last four years I have gained experience on project management and leadership
from different team perspectives like technology vendors, networking start-up
and over a year as OpenStack operator. This last one has been very interesting
compare with my previous ones because of my focus on a production ready
cloud powered by OpenStack. Running a high-scale production cloud is giving me
a different perspective on how the platform should be delivered as a product
ready to use and that is what I will be bringing to the TC and to all project
members and PTLs.

As a TC member my main focus will be to close any existing gap between the
development teams and their costumers who are the OpenStack users and operators
between others. In my operator role I have validated documentation and best
practices on OpenStack deployment and operations and I have been provided all
possible feedback and I want to do more on this area. I believe we can make
OpenStack better if we open the TC to members who have deployed pure OpenStack
with no vendor specific guidelines or any specific distribution influence.

I strongly believe we will make OpenStack more solid and integrated. I will
work as cross-project liaison in order to reach this goal. I will continue my
work of evangelizing the newest OpenStack projects and guide them to have the
best adoption process by the community and also I will help them to have the
best integration with any other open-source technologies.

No matter what is the result of the election I will continue my work on
OpenStack with passion and courage. This is the best project ever and it can
be even better. Let's inject some fresh ideas to the TC, let's keep making
this platform the de-facto cloud management system for all operators either
public, private or hybrid clouds.

Thank you so much for reading and considering my humble aspiration to the TC!

--
Edgar Magana
IRC: emagana
__
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] [election] [TC] TC Candidacy

[Kyle Mestery]

I'd like to announce my candidacy for the TC election.

A bit about me and my involvement with OpenStack: I've been
involved with OpenStack for a long time now in various capacities.
Most recently, I was the PTL for Neutron for the Juno, Kilo and
Liberty cycles. I've been a core reviewer on Neutron since July of
2013. I helped to write the Project Team Guide [1] by participating
in the sprint during it's creation. I founded and continue to lead
the Minnesota OpenStack Meetup [2]. I've spoken at many OpenStack
conferences and other Open Source conferences.

Given the "Big Tent" governance model we now find ourselves under,
my experience in leading Neutron as it adopted the "Neutron Stadium"
is very relevant to the current state of OpenStack. While leading
Neutron, the "Neutron Stadium" allowed many new project teams to
develop and grow. I hope to be able to work with new OpenStack
projects and guide them as they grow into OpenStack projects. I'd
also like to ensure the uniqueness which each projects brings to the
table isn't lost when it becomes an OpenStack project. While I
firmly believe each project must adopt the Four Opens [3] in order
to become an OpenStack project, it's important to not lose the
original spark which was lit to start these projects as they move
into the Big Tent.

If I'm elected, I will continue to dedicate time to work upstream
and help new and old projects. I'll work hard to assist anyone who
requests my help. And I'll continue to strive to do what I can
to ensure OpenStack's future success.

OpenStack has been an amazing community to be involved in. I am
fortunate to have been a part of this community for a long time now,
and should I be elected, I look forward to the chance to help guide
it while serving on the TC for the next two cycles!

Thank you!

--
Kyle Mestery
IRC: mestery

[1] http://docs.openstack.org/project-team-guide/
[2] http://www.meetup.com/Minnesota-OpenStack-Meetup/
[3]
http://docs.openstack.org/project-team-guide/introduction.html#the-four-opens
__
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] [Election] [TC} TC Candidacy

[Steven Dake (stdake)]

Hello Peers,


I would be pleased to serve on the Technical Committee with your vote.  I have 
a very relevant background to serving you in the Technical Committee in that I 
have done the following during OpenStack development:


  1.  Led the development, incubation, and integration of Heat for the first 
project to enter what would be a precursor to the Big Tent.
  2.  Wrote most of the initial commits and contributed heavily to the first 
Big Tent project Magnum.
  3.  Solving the most complex problem OpenStack faces, Deploying the Big Tent, 
by serving as PTL of Kolla which I have led from first commit through the Big 
Tent process.
  4.  Top 10 contributor by Person-day effort for Liberty.  Top 1% by 
Person-day effort  for Kilo.  Top 1% by Person-day effort for OpenStack project 
overall.


My experience with Heat, Magnum, and Kolla directly relate to the Technical 
Committee's charter which is to serve as technical oversight for the OpenStack 
project.  I am highly interested in growth management of my peers and the 
systems and people I involve myself with.  I believe it is one of the core 
responsibilities of the Technical Committee to provide effective growth 
management for the OpenStack ecosystem, in partnership with the OpenStack Board.


I can confirm that the original incubation track that Heat executed was highly 
painful and very challenging.  It was not very inclusive, not documented, and 
highly subjective.


The new Big Tent process is far improved.  It is almost completely objective 
and measurable which in my opinion leads to high growth in individuals and 
systems during their evaluation.


Most of the work the Technical Committee has done over the last year has been 
to make OpenStack more obecjtive and measureable by anyone.  I personally feel 
this change is fantastic and has unstuck the Technical Committeee.  This work 
facilitates the growth of OpenStack in general and new projects in particular.


I want to bring my experience creating new things for OpenStack to bear to 
create New Things for the Technical Committee to further acclerate growth.  I 
would happily accept your vote for the Technical Committee election.


Regards,

-steve
__
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] [election][TC] TC Candidacy

[Amrith Kumar]

Greetings,

I'm writing to submit my candidacy for election to the OpenStack
Technical Committee.

By way of introduction, my name is Amrith Kumar, I am the Chief
Technology Officer[1] at Tesora[2], a company focused on
Database-as-a-Service and the OpenStack Trove project.

As OpenStack evolves, so too should the Technical Committee. I believe
that the Technical Committee has a very high representation from the
core (nova, cinder, swift, glance, neutron, ...) projects, and there
needs to be more representation of the other projects in OpenStack
that are not part of this core (trove, sahara, ...). I believe that
the future success of OpenStack depends heavily on the successful
integration of these non-core projects, and the ease with which people
can deploy the core and non-core components of OpenStack.

If elected, I would bring a different perspective to the TC, one that
would broaden the representation the non-core projects on the
Technical Committee.

Here is a quick summary of what I do relative to OpenStack, and why I
believe that you should consider my candidacy for TC

   - active contributor and member of the core review team for Trove,
 and spend all of my time on upstream development activities
 related to OpenStack Trove. I am also a periodic contributor to
 Oslo and the Trove liaison to Oslo

   - authored the book on OpenStack Trove[3] along with Doug Shelley,
 a co-worker and contributor to the Trove project

   - OpenStack evangelism and outreach activities include

  - Frequent participant and speaker at a variety of technical
events where I have spoken about OpenStack in general, and
sometimes Trove in particular

  - Frequent participant in the Boston OpenStack Meetup,
presenter at a number of OpenStack Meetups all over the
country

  - Actively promoting an initiative called "OpenStack in the
Classroom" [4] that I shared on the mailing list several
months ago. I have had good luck promoting it to a number
of colleges in the Boston area

- chosen by the OpenStack Foundation to serve as part of a global
  committee of OpenStack experts developing a list of Domains and
  Tasks essential for OpenStack administration professionals.

I believe firmly that the long term success of OpenStack depends on
the ease with which users are able to deploy and bring a cloud into
production. The big tent proposal was a very important step in that
direction but much remains to be done.

It is essential that we make it easier for users to deploy and use
other projects that are not part of the "core", projects like Trove,
Sahara, Magnum, and so on.

A current example of the kind(s) of issues that I believe to exist
relates to the creation of protected 'service resources' that make it
possible for services to provision servers and storage in tenant
context while making it impossible for tenants to manipulate these
resources other than through the service that provisioned them
[5],[6].

This is an example of a specific initiative that I have been working
with members of the community to address.

This is a feature that will have to be provided by the core projects
and the beneficiaries are the non-core projects that request these
'service resources'.

I believe that it is imperative that the Technical Committee take a
leadership role in addressing these kinds of issues, as it did in the
big-tent approach.

The activities of the TC align closely with my own skills and past
experience which include architecting and implementing complex
computer architecture, with flexible and extensible API's and then
working with diverse teams to deliver the software that implements
these. I work very effectively as a facilitator of teams and in
helping groups of people work together.

I believe that I will be able to work with the rest of the team and
drive this kind of activity to successful completion. I am committed
to the success of OpenStack and would like to contribute further as a
member of the Technical Committee.

I look forward to your support in the upcoming election, and I thank
the outgoing members of the TC for their hard work and the solid
foundation that they have laid for future committees.

Here are some more links:

 Official Candidacy: https://review.openstack.org/#/c/229073/
 Review history: https://review.openstack.org/#/q/reviewer:9664,n,z
 Commit history: https://review.openstack.org/#/q/owner:9664,n,z
 Stackalytics: http://stackalytics.com/?user_id=amrith=all
 Foundation: http://www.openstack.org/community/members/profile/15733
 Freenode: amrith
 LinkedIn: http://www.linkedin.com/in/amrith

Thank you,

-amrith

[1] http://www.tesora.com/people/amrith-kumar/
[2] http://www.tesora.com/
[3] http://www.apress.com/9781484212226
[4] http://openstack.markmail.org/thread/ukckrielspbrjejp
[5] https://review.openstack.org/#/c/186357/
[6] 

Re: [openstack-dev] [election][TC] TC Candidacy

[Philip Schwartz]

+1

I also completely agree on the idea of re-thinking our mission. The key to 
OpenStack’s future will completely be about the users and supporting them in 
their effort to use the software at scale.

Philip

> On Sep 29, 2015, at 1:54 PM, Monty Taylor  wrote:
> 
> Hi!
> 
> I would like to continue serving on the TC, if you'll have me.
> 
> Although past performance is no guarantee of future profits, I think it's 
> worth noting that I've been doing this for a while now. I was on the 
> precursor to the TC, the Project Policy Board. Over the time I've been the 
> instigator or a key player in several major initiatives, such as Stackforge, 
> the Project Testing Interface and The Big Tent.
> 
> Thing is, that really doesn't matter, because while understanding the past is 
> important if you want to avoid re-learning the same lessons, we need to be 
> firmly focused on the future, and to be willing to make changes as needed to 
> accommodate the reality we find ourselves in.
> 
> I think it's time for the TC to take a more active position on technical
> design issues.
> 
> This past cycle, Sean and Anne wrote up a spec that came from the last summit 
> around standardization of the keystone catalog data. Doug dove in to issues 
> around Glance upload. Both are instances where clear technical leadership and 
> design was needed, and in both instances we understand that it goes hand in 
> hand with being clear to our deployers and end users about what it is that we 
> expect via interaction with DefCore.
> 
> I want to see more things like that, and I'd like to be involved with moving 
> the TC another step down the road from being a "policy board" to being a 
> "technical committee".
> 
> On the social side, I'd like to work with people on figuring out how to 
> expand our capacity for trust across the project. We set up all of our 
> systems and culture initially to protect against bad-faith and antagonistic 
> behavior - but we've been doing this long enough now that I think the 
> assumption of bad and protective behavior is counter productive. We're never 
> going to get the big issues fixed if we can't land hard patches.
> 
> Finally, I think we need to re-think our mission.
> 
>   The OpenStack Mission: to produce the ubiquitous Open Source Cloud
>   Computing platform that will meet the needs of public and private
>   clouds regardless of size, by being simple to implement and
>   massively scalable.
> 
> That mission is about clouds, and I think it has completely forgotten a key 
> ingredient - users. Focusing on meeting the needs of the clouds themselves 
> has gotten us to an amazing place, but in order to take the next step we have 
> to start putting the consumers of OpenStack Clouds front and center in our 
> thinking.
> 
> Thank you for the trust you've placed in me so far, and I hope I've lived up 
> to it well enough for you to keep me around.
> 
> Monty
> 
> __
> 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

[openstack-dev] [election] TC] TC Candidacy

[Barrett, Carol L]

I am writing to announce my candidacy a position on the TC.

I am not your typical candidate, which is one reason that I am asking for your 
vote. I have a technical background, with over a decade of software development 
experience. I have a marketing background, with over a decade of Technology, 
Product and Brand marketing experience. I have a business development 
background and have been an entrepreneur. I have been a product manager and a 
software planner. It's this combination of experiences that I have accumulated 
during my almost 35 years in the technology industry that I believe will enable 
me to provide unique value as a member of the TC.

I have been an active member in the community since 2013, working with 
Community teams to understand market-segment needs and/or barriers to their 
deployment of OpenStack and bringing that information to the Community in the 
form of specs, blueprints, prototypes and user stories (Win The Enterprise WG, 
Enterprise WG, Product WG). These teams have brought resources to develop these 
capabilities (one example is improving upgrade capabilities through versioned 
objects implementation) and have been able to close gaps resulting in expanding 
Enterprise deployments of OpenStack.

I believe that a diverse Community will enable us to develop more innovative 
software that will meet the needs of global markets. I work with both the 
Diversity Working Group and the Women of OpenStack to help strengthen the 
diversity of our Community.

As a TC member, I will work to support our success by utilizing my 
project/program management experience. Specifically, I will:
1)  Tap the collective market knowledge within our Community to identify 
innovative capabilities that will define the defacto cloud computing platform 
of the future.
2)  Work to bring projects together to define and implement cross-project 
capabilities and initiatives.
3)  Support the development of a multi-release roadmap definition and 
communication process.

As cross-project coordination needs expand and concepts like big tent stretch 
our capabilities, I believe that my skill-sets, experiences, and values align 
well with the emerging needs within our community.

I would appreciate the opportunity to further my contributions to our Community 
and thank you for your consideration.

Carol Barrett


__
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] [election][TC] TC Candidacy

[Monty Taylor]

Hi!

I would like to continue serving on the TC, if you'll have me.

Although past performance is no guarantee of future profits, I think 
it's worth noting that I've been doing this for a while now. I was on 
the precursor to the TC, the Project Policy Board. Over the time I've 
been the instigator or a key player in several major initiatives, such 
as Stackforge, the Project Testing Interface and The Big Tent.


Thing is, that really doesn't matter, because while understanding the 
past is important if you want to avoid re-learning the same lessons, we 
need to be firmly focused on the future, and to be willing to make 
changes as needed to accommodate the reality we find ourselves in.


I think it's time for the TC to take a more active position on technical
design issues.

This past cycle, Sean and Anne wrote up a spec that came from the last 
summit around standardization of the keystone catalog data. Doug dove in 
to issues around Glance upload. Both are instances where clear technical 
leadership and design was needed, and in both instances we understand 
that it goes hand in hand with being clear to our deployers and end 
users about what it is that we expect via interaction with DefCore.


I want to see more things like that, and I'd like to be involved with 
moving the TC another step down the road from being a "policy board" to 
being a "technical committee".


On the social side, I'd like to work with people on figuring out how to 
expand our capacity for trust across the project. We set up all of our 
systems and culture initially to protect against bad-faith and 
antagonistic behavior - but we've been doing this long enough now that I 
think the assumption of bad and protective behavior is counter 
productive. We're never going to get the big issues fixed if we can't 
land hard patches.


Finally, I think we need to re-think our mission.

   The OpenStack Mission: to produce the ubiquitous Open Source Cloud
   Computing platform that will meet the needs of public and private
   clouds regardless of size, by being simple to implement and
   massively scalable.

That mission is about clouds, and I think it has completely forgotten a 
key ingredient - users. Focusing on meeting the needs of the clouds 
themselves has gotten us to an amazing place, but in order to take the 
next step we have to start putting the consumers of OpenStack Clouds 
front and center in our thinking.


Thank you for the trust you've placed in me so far, and I hope I've 
lived up to it well enough for you to keep me around.


Monty

__
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] [Election] [TC] TC Candidacy

[Maish Saidel-Keesing]

Hello to you all.

I would like to propose myself as a candidate for the Technical 
Committee for

the upcoming term. The reasons for running in the last election [1]
are still relevant for this election of the TC.

Since the last election my involvement in OpenStack has increased with a
spotlight on the Operators aspect of the community:

- Focusing on the ops-tags-team[2] helping to create tags with the 
intent of

   creating information relevant to Operators.
- Helping to vet and review submissions to the OpenStack Planet[3] and
   contributing as a core in openstack-planet-core.
- Participating in the Item Writing Committee of the first Foundation
   initiative for the inaugural OpenStack Certification Exam Program.

As an OpenStack community we have made some huge steps in the right 
direction,

and are bringing more and more of the Operator and User community into our
midst. Operators and Users should also be represented in the
Technical Committee.

It is my hope that the electorate accept that there is a huge benefit,
and also a clear need, to have representation from all aspects of 
OpenStack, not

only from the developer community. When this happens - the disconnect (and
sometimes tension) that we have between these different parts will cease 
to be

an issue and we as a community will continue to thrive and grow.
In order to finally bridge this gap, it is time to open the ranks, bring an
Operator into the TC and to become truly inclusive.

I humbly ask for your selection so that I may represent Operators in the
Technical Committee for the next term.

Thank you for your consideration.

Some more information about me:
OpenStack profile: https://www.openstack.org/community/members/profile/15265
Reviews: 
https://review.openstack.org/#/q/reviewer:%22Maish+Saidel-Keesing%22,n,z

IRC: maishsk
Blog: http://technodrone.blogspot.com

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-April/062372.html
[2] 
https://review.openstack.org/#/q/status:open+project:stackforge/ops-tags-team,n,z

[3] https://wiki.openstack.org/wiki/AddingYourBlog

--
Best Regards,
Maish Saidel-Keesing

__
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] [election] [tc] TC candidacy -- Let's do this

[Clint Byrum]

Greetings Stackers,

Some of you I know, some of you I'm meeting for the first time.

Through the last 3 years, since I got involved with OpenStack, I've
seen it grow and mature, and I want to make sure it continues to as we
all raise the bar on what we expect from the not so little cloud engine
that could.

I've been involved with some controversial projects, and been pleased
to watch our community handle most of the controversy by simply choosing
to make our developers' actions uncontroversial with the big tent. I aim
to continue this trend of being inclusive and supportive of the efforts
of everyone who wants to throw their hat in as an OpenStack project.

I intend to put users first, and operators second, with our beloved
developers third. I consider myself "all of the above", and I think that
should bring useful perspective to the TC. This isn't an area I think
OpenStack has failed in, but I believe it requires constant vigilance.

I do have a specific agenda for all of OpenStack, and which I will use
my TC seat to advance whenever possible:

- Streamline everything. There are parts of OpenStack that scale to
the moon, and parts that don't. I think OpenStack should try hard for
everything with the OpenStack moniker on it to put performance and
stability above all else.

- Measure efficiency. We don't necessarily measure how efficient OpenStack
is, or how much each change is affecting its efficiency. We have blog
posts, and anecdotes, but I want to have actual graphs that belong to
the community and show us if we're living up to our goals.

- Resiliency. Once we're streaminling things, and measuring our progress,
we should be able to separate performance problems for reliability
problems, and make OpenStack more resilient in general. This serves
users and operators alike, but it may be hard for developers. That's ok,
we like hard stuff, right?

- No sacred cows. I feel like sometimes the tech we have chosen is
either begrudgingly kept because there's nothing good enough to change,
or hallowed as "the way this works." I would like to challenge some of
those cows and see if we can't do a little bit of work toward streamlining
and resilience by challenging conventional wisdom.

I'm going to work on these things from outside the TC anyway. However,
with the added influence that a seat on the TC provides, I can certainly
work on these things even more.

Thank you for your time!

Clint Byrum
IBM

__
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] [election] [tc] TC candidacy

[Sean Dague]

I'd like to submit my candidacy for the TC Election.

I've been involved with OpenStack since the beginning of the Folsom
release. We may have worked together on parts of Nova, Tempest,
DevStack, Grenade, or in generally debugging failures in the upstream
gate in OpenStack. Or from things like the gerrit-dash-creator that
makes it easy for teams to build custom review dashboards.

I'm a strong believer in the Big Tent approach to OpenStack. I was one
of the early instigators of that conversation [1], which as with all
things got better with more smart people involved in it. I'm also a
strong believer that the longevity of the OpenStack project is about
having a solid and small on ramp that gets OpenStack in as many places
as possible. And a clear path to expand it over time. This was one of
the reasons I believed the compute-starter-kit was an important tag
that the TC bless [2].

Over the past year I've spent time on decomposing and modularizing
OpenStack components. We no longer test all the projects and all the
libraries in one giant gate queue. We now have a plugin framework for
DevStack and Grenade that makes it easier for people to expand on top
of it.

I've also been focusing on the API side of OpenStack. In the API
working group, and on the Nova project. I helped define the
Micro-version approach that is used in Nova, and has been adopted by
other projects in OpenStack [3]. This has opened up a new way for
projects to evolve their API while not breaking existing applications.

Over the next couple of cycles my focus is going to be interop, with
an eye on the Service Catalog and the API of projects. I hope to do
that work with a broad range of contributors to make the end user
experience of OpenStack much better.

In my role at Hewlett Packard I've got the freedom to work on many of
these larger issues in the way that works best for the community.

If this is the kind of voice that you would like on the TC, please
feel free to vote for me. It would be my honor and pleasure to
continue to represent you, and the mission to expand OpenStack's
reach, on the TC.

-Sean

--
Sean Dague
irc: sdague

1. https://dague.net/2014/08/26/openstack-as-layers/
2. http://governance.openstack.org/reference/tags/compute_starter_kit.html
3. https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/

Review history: https://review.openstack.org/#/q/reviewer:2750,n,z
Commit history: https://review.openstack.org/#/q/owner:2750,n,z
Stackalytics: http://stackalytics.com/?user_id=sdague
: https://www.openhub.net/accounts/sdague

--
Sean Dague
http://dague.net

--
Sean Dague
http://dague.net

__
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] [election][tc] TC Candidacy

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Greetings Stackers! I'm announcing my candidacy for the Technical
Committee Elections.

Those of you who have been involved in OpenStack most likely know me,
as I was part of the original team from Rackspace that created
OpenStack in 2010. For the past year or so I have been employed at IBM
to work on 100% upstream OpenStack development. Part of that time has
been spent getting a good overview of both the project and the
community behind it. I've also placed some of my focus on the groups
of people working *with* OpenStack, and not just those developing it.
And to that end I've been working with the current TC as much as
possible, especially in the areas of API standardization and
consistency. I'm always lurking on the regular TC meetings (and
sometimes throwing in my two cents), and reviewing as much of the
material as I can. I believe that I can have a much greater impact as
part of the TC instead of just being that occasional voice from the
back of the room.

There are some good reasons not to vote for me: the other TC
candidates. I wish I could run on a "throw out the bums" platform, but
that's simply not possible.  I know all the current members, and they
have all done an excellent job this past year, and would all represent
the community well if re-elected. I can only promise that if elected,
I will work hard to have at least as much positive impact on the
community as the TC member I might replace. That will be a difficult
task indeed, but I believe that I have the long-term experience to
help guide OpenStack as it continues to grow and thrive in the future.

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJWCWEfAAoJEKMgtcocwZqLTJIP/2K4pD+jhdDO487k5zLUlYvY
8NB6Zv7VG7i6LRllX6D8M9zKgG2/vEknHa76lgE23N1fjhnSJ9zLyffLyAPmmOvT
T0Z4U80as8sxZCq7RwWvLh0VvyLq/wlXr1bHkTHiZbQTZl4B/V2fvVWATktkrf9T
Pv4BgVJTQj/lkLN6RVz027/z6t8bGx9idGYsU6BI3mQifO1ebePWxhPtr5BvZG+P
Bnio7Ya4cQqX9KPWNge6chlRCWZ8vsdCqxP5jJz4O7GTbXJPJ2X1WVHJZNpLq0Q+
+tvN1vKkdFbfQWFCQLUVyk0+qoE+SmGxksB7I77PK4sw49Yw8TZjXimQoDWyM1+x
6WlVleDvBQeHXB+13jjlJNkHIXb1typ28+nb9yU5pummH4OiTs/uVsqxqwZCAIOd
WwDDKoj2x17RsSbluVgQn7yAHE/5e82/HlZnBDKrtkQpc1qyNdq755zMbY8qLJk+
xH+qGvw//kicSFsERNZNX8JC0z8suVovuC+T7ZAyOZ9obk0LkT9+9E7BfnRxK0mi
URG9iyoZ02u4csN+hQz59+LrBLq+TqFga4pX3zqYQbCH+yXvEJg1iwHWbso3ERUn
uR1r2IBj8p6ZTh+iGzc7/7yyu/mpHV+FDjtOwA0GtBDOqvF0k83Vn1KDI0hvdzzx
JpjI9XunME417m8904qJ
=Q8LE
-END 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

[openstack-dev] [election][tc] TC Candidacy

[Doug Hellmann]

I am announcing my candidacy for a position on the OpenStack Technical
Committee.

I am currently employed by HP to work 100% upstream on OpenStack. I
started contributing to OpenStack in 2012, not long after joining
Dreamhost. In the time since, I have worked on a wide variety of
projects within the community. I am one of the founding members of the
Ceilometer and unified command line projects. I am also part of the
team working on the Python 3 transition, and have contributed to
several of the infrastructure projects. I formally joined the Release
Management team at the start of Liberty, and have been working on
updating processes and tools to make releases easier for all project
teams. I will be PTL of the Release Management team for the Mitaka
cycle.  I served as PTL for the Oslo project for three terms, and I
have served on the Technical Committee for the last two years. In
addition to my technical contributions, I helped to found and still
help to organize the OpenStack meetup group in Atlanta, Georgia.

I characterize most of my recent work as enabling others in the
community. As Oslo PTL I helped the team complete its transition from
copy-and-paste sharing to true shared libraries by creating new
processes and tools. Ceilometer was one of the earliest projects to
need to interact with a significant number of the other projects at a
code level, and my experience on that team led me to establish the
Oslo liaison program when we recognized a similar need as adoption of
Oslo libraries expanded. That pattern has been reused by many of the
other cross-project teams to establish formal lines of communication
to address our community’s growth. The self-service release review
tools the release management and infrastructure teams are building now
are another effort to remove process bottlenecks by enabling project
teams to manage their own releases.

During my past terms on the TC, I worked to find compromise positions
and clarity, incorporating the views of other committee members while
tempering them with my own. Several times I wrote the first draft of
policy changes on contentious topics, moving abstract arguments to
discussions of concrete terms. This was especially true for the shift
from the incubation to “big tent” governance models late in 2014. I
prepared several alternate versions of the policy changes before an
approach was found that appealed to all committee members.  Iteration
for the win.

All of these experiences have given me a unique cross-project
perspective into OpenStack, and reinforced for me the importance of
communication between project teams to smooth out the integration
points and remove friction.  Improving communication and cross-project
efforts is a key role for the Technical Committee. For example, during
Mitaka I will be working to support the interoperability goals of the
community by ensuring the DefCore committee have and understand all of
the input from project contributors to set the right technical
direction, and that the contributors in turn understand the issues
raised from within the DefCore committee so we can add or modify
features to improve interoperability between OpenStack deployments.

The OpenStack community is the most exciting and welcoming group I
have interacted with in more than 20 years of contributing to open
source projects. I'm looking forward to continuing to being a part of
the community and serving the project.

Thank you,
Doug

Official Candidacy: https://review.openstack.org/#/c/227857/
Review history: https://review.openstack.org/#/q/reviewer:2472,n,z
Commit history: https://review.openstack.org/#/q/owner:2472,n,z
Stackalytics: http://stackalytics.com/?user_id=doug-hellmann
Foundation: http://www.openstack.org/community/members/profile/359
OpenHUB: https://www.openhub.net/accounts/doughellmann
Freenode: dhellmann
Website: https://doughellmann.com

__
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