openstack/election
Code Issues Proposed changes

Add Shamail Tahir as TC candidate

Browse Source 
Text file with brief description of candidate.

Change-Id: I258691325012ca55c23955718e9f1587fe166d2c
This commit is contained in:
Shamail Tahir 2016-03-29 17:13:43 -04:00
parent 636ff1ea64
commit 93e2e60ec6
1 changed files with 77 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
candidates/newton/TC/Shamail_Tahir.txt Normal file
View File

@ -0,0 +1,77 @@
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 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] http://superuser.openstack.org/articles/section/superuser-tv
[5] http://www.openstack.org/software/roadmap/