Define 2023 upstream investment opportunities

Copy all three opportunities (QA, Infra and RBAC) from 2022
which I think still need help.

Change-Id: Ib76c9b0b74319f039c28c0bba7b5668f47d1ca57

reference/upstream-investment-opportunities/2023/community-infrastructure-sysadmins.rst

@@ -0,0 +1,113 @@
+==================================
+Community Infrastructure Sysadmins
+==================================
+
+Summary
+-------
+
+The OpenStack community is seeking developers and system administrators
+with a background in maintaining Unix/Linux servers and free software to
+join the TACT SIG Infrastructure team.  This team is responsible for
+designing, building and maintaining the systems that are used in the day
+to day operation of the OpenStack project as a whole.
+
+Attrition due to shifts in employment or availability of personal time
+impacts the team's ability to support the community effectively, and so
+there is a constant need for new contributors who can commit to investing
+sufficient effort to overcome the steep learning curve associated with these
+varied technologies.
+
+There is a particular need for infrastructure team members from APAC and EMEA.
+
+Business Case
+-------------
+
+Sponsorship of a team member is a way to visibly help build and
+maintain the development, collaboration, and testing tools used by the
+third most active open source project in the world without having to
+donate hardware.  Team members interact with contributors across all
+the OpenStack projects as well as with the OpenStack service providers
+who supply resources for OpenStack CI systems.
+
+Sponsors of infrastructure team members have a "seat at the table" as
+decisions are made about how to improve and scale OpenStack
+infrastructure going forwards.
+
+Sponsors gain in-house expertise and experience building large-scale,
+adaptive software development infrastructure with open-source tools
+and public configuration management.  There is no better way to gain
+exposure to and expertise with leading-edge CI/CD in advance of
+potential deployment at home than to place someone on the team
+deploying one of the world's most scaled out instances of the `Zuul
+project`_.
+
+The software developed, skills involved, and open community practices
+learned can have high value downstream in a sponsors own enterprises
+and software products.
+
+.. _`Zuul project`: https://zuul-ci.org
+
+Technical Details
+-----------------
+
+The infrastructure team is responsible for designing, building and
+maintaining the systems that are used in the day to day operation of
+the OpenStack project as a whole; this includes development, testing,
+and collaboration tools. All of the software it runs is open source,
+and under public configuration management so that everyone in the
+community has the opportunity to participate. One very effective way to
+get involved in OpenStack and gain a deep understanding and visibility
+within the community is by helping operate this infrastructure.
+
+In particular, the team seeks developers and systems administrators
+with a background both in maintaining Unix/Linux servers and free
+software, and places heavy emphasis on systems automation and
+configuration management (primarily Ansible at the moment).
+Everything possible goes through code review, and gets
+extensively documented and communicated with the rest of the
+community over IRC and mailing lists. Server resources are donated
+by companies operating OpenStack services so there is
+substantial opportunity both for people who have experience in those
+technologies as well as anyone wishing to gain more familiarity with
+them.
+
+Value
+~~~~~
+
+The infrastructure team leverages resources donated from companies operating
+OpenStack services. The community uses the software it produces as a tool for
+testing it. Every day, contributors submit thousands of patches for review.
+Infrastructure tools deploy each patch and test it against thousands of tests
+and scenarios. This volume provides an opportunity to improve the software we
+write by giving us first-hand experience with issues at scale. The benefit of
+fixing these issues for the OpenStack CI system is two-fold:
+
+1. It makes the test platform more stable and robust
+2. Products or services benefits from the fix being applied upstream
+
+Don't Repeat Yourself or Your Testing (DRY)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The culture built around extensive testing in OpenStack makes it easier for us
+to trust patches proposed for review. We've integrated this culture into our
+review process. Duplicating a social and technical CI system of this size takes
+incredible amounts of time, people, and patience. Bolstering the CI system we
+already have in place allows you to focus on testing that is specific to your
+product or service.
+
+Immediate Feedback
+~~~~~~~~~~~~~~~~~~~
+
+The OpenStack CI system is the backbone of feedback for contributors and
+operators. Users get this feedback early, ideally before the patch lands.
+Ensuring early feedback through a robust CI system and testing means fewer
+surprises down the road when you attempt to integrate your product into a new
+release or deploy a new version of a service.
+
+Contact
+-------
+
+Join the OpenStack Infra or TC IRC channel (``openstack-infra`` on `OFTC
+<https://www.oftc.net/>`_) or (``openstack-tc`` on `OFTC <https://www.oftc.net/>`_).
+You can also reach out through the openstack-discuss mail list at list.openstack.org
+if you would like to get involved.

reference/upstream-investment-opportunities/2023/index.rst

@@ -0,0 +1,17 @@
+:orphan:
+
+=======================================
+ 2023 Upstream Investment Opportunities
+=======================================
+
+.. note::
+
+    The latest list of upstream investment opportunities can always be found on
+    the :doc:`../index` page. Historical data is retained for reference.
+
+.. toctree::
+    :glob:
+    :maxdepth: 1
+    :titlesonly:
+
+    *

reference/upstream-investment-opportunities/2023/quality-assurance-developers.rst

@@ -0,0 +1,110 @@
+==================================
+Quality Assurance Developers
+==================================
+
+Summary
+-------
+
+The OpenStack community is seeking developers with a background in Python, bash
+shell, or Javascript programming and free software to join the OpenStack QA
+team.  This team is responsible for maintaining and evolving OpenStack's robust
+and comprehensive quality assurance tools, which form the backbone of the
+OpenStack CI pipeline.
+
+Attrition due to shifts in employment or availability of personal time
+impacts the team's ability to support the community effectively, and
+so there is a constant need for new contributors who can commit to
+investing sufficient effort to overcome the steep learning curve
+associated with these varied technologies.
+
+Business Case
+-------------
+
+Sponsorship of a team member is a way to visibly help build and maintain the
+development and testing tools used by one of the most active open source project
+in the world.  Team members interact with contributors across all the OpenStack
+projects as well as with the OpenStack infrastructure system administrators who
+ensure reliable access to resources for OpenStack CI systems.
+
+Sponsors gain in-house expertise and experience building complex, comprehensive,
+and modular software testing suites with open-source tools.  There is no better
+way to gain exposure to and expertise with the testing suites that power a
+leading-edge CI/CD in advance of potential deployment at home than to place
+someone on the team that creates testing frameworks that are used by dozens of
+software projects to run tests in the `Zuul project`_.
+
+The software developed, skills involved, and open community practices learned
+can have high value downstream in a sponsor's own enterprises and software
+products.
+
+Technical Details
+-----------------
+
+The OpenStack QA team is responsible for designing, building and maintaining the
+testing harnesses and tools that are used in the day to day development and CI
+process of the OpenStack project, as well as production cloud testing also.  In
+the OpenStack paradigm, project teams are responsible for writing tests that
+exercise and validate the code that they are contributing.  The definition of
+what needs to be tested is standardized in the `Project Testing Interface`_.
+The OpenStack QA team writes code that:
+
+* deploys the OpenStack services in a form usable for testing (devstack)
+* runs a gauntlet of API tests against the control plane of each OpenStack
+  service (tempest)
+* including complex RBAC operations (patrole),
+* OpenStack-health dashboard for visualizing test results of OpenStack CI jobs
+* grenade for upgrade testing
+* hacking for code style
+
+In addition to being used in the OpenStack CI pipeline, tempest and patrole can
+also be used for large scale testing of production clouds. In addition, Tempest
+is used in the interoperability certification program. All of the software
+it runs is open source, and under public configuration management so that
+everyone in the community has the opportunity to participate.  One very
+effective way to get involved in OpenStack and gain a deep understanding and
+visibility within the community is by helping maintain and evolve these tools.
+Everything possible goes through code review, and gets extensively documented
+and communicated with the rest of the community over IRC and mailing lists.
+
+Value
+~~~~~
+
+The OpenStack project is composed of dozens of project teams that focus on
+delivering specific services that together compose OpenStack.  What defines code
+as being part of OpenStack is that it has passed review by the tools built by
+the QA team.  Contributors to the QA team have a special vantage point, being
+able to see how these services fit together, and how those integrations can have
+problems.  This is first-hand experience with the challenges of integrating a
+large, distributed multi-component project, which is a valuable skill.
+Experiences with integration challenges with projects of this scale can be
+transferred to other large projects within the enterprise.
+
+Innovating On Top Of A Massive Effort
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The culture built around extensive testing in OpenStack makes it easier for us
+to trust patches proposed for review.  There are many kinds of testing
+performed: unit, functional, style, API, scenario, upgrade, and end-to-end
+(fullstack) testing are all supported by the toolset developed by the QA team.
+For more information, see the `Project Team Guide, Testing Chapter`_.
+In addition, we are constantly looking forward to innovate our testing
+framework to provide more accurate simulations of customer issues.  Duplicating
+a social and technical quality control system of this size takes incredible
+amounts of time, people, and patience. Bolstering the QA system we already have
+in place allows you to focus on testing that is specific to your product or
+service while benefitting from the best of breed for testing innovation that
+occurs anywhere in the project..
+
+Contact
+-------
+
+Join the OpenStack QA IRC channel (``#openstack-qa`` on `OFTC IRC`_), email
+the openstack-discuss mailing list at list.openstack.org, or contact the `QA
+PTL`_ directly if you would like to get involved.
+
+
+.. _`Zuul project`: https://zuul-ci.org
+.. _`Project Testing Interface`: https://governance.openstack.org/tc/reference/project-testing-interface.html
+.. _`Project Team Guide, Testing Chapter`: https://docs.openstack.org/project-team-guide/testing.html
+.. _`OFTC IRC`: https://www.oftc.net
+.. _`QA PTL`: https://governance.openstack.org/tc/reference/projects/quality-assurance.html

reference/upstream-investment-opportunities/2023/rbac.rst

@@ -0,0 +1,92 @@
+=====================================
+Consistent and Secure Policy Defaults
+=====================================
+
+Summary
+-------
+
+The OpenStack community is seeking contributors to the Secure Policy Defaults
+initiative.  This ongoing initiative aims to provide set of common roles that
+will enable secure enforcement of authorization policies across OpenStack
+projects and deployments.
+
+Business Case
+-------------
+
+Supporting consistent and secure default RBAC configuration in OpenStack
+provides the best means to secure your organization's OpenStack deployment and
+to make security maintenance less error-prone. This is especially incumbent upon
+organizations that are subject to security audits and strict regulations for
+whom OpenStack's lack of consistent RBAC prohibits production use.
+
+Sponsorship of contributors to this RBAC initiative positions them to
+influence direction and drive implementation choices on critical
+infrastructure used by every OpenStack project and every OpenStack
+deployment -- ensuring that an organization's downstream requirements
+are fully understood and taken into account.
+
+Because of its use in every OpenStack project, work on this RBAC
+initiative is a good way to build reputation and influence upstream,
+and at the same time gain vital in-house expertise for an
+organization's downstream deployments or software distributions.
+
+Technical Details
+-----------------
+
+Currently, most OpenStack services have a very binary approach to Role Based
+Access Control (RBAC) enforcement. This approach usually handicaps new
+functionality from being exposed to users because users typically do not fall
+in one of two camps.  Contributors either need to lock down the feature to only
+system administrators, or open it up to nearly every user in the deployment.
+This is especially true for APIs that expose details about multiple tenants.
+
+Implementing better API protection allows contributors to expose more
+functionality to end users and operators by default. Lowering the bar for users
+to access a feature means more opportunities for feedback loops, more end users
+getting access to the functionality they need, and makes OpenStack more usable
+overall.
+
+For detail, read the `community-wide rbac goal`_ document.
+
+Enhanced Security
+~~~~~~~~~~~~~~~~~
+
+OpenStack has a wide variety of users. Auditing APIs and adjusting default
+access control increases security across the entire OpenStack platform. This
+exercise gives contributors the ability to provide secure defaults for new
+deployments. Reasonable default values that are inherently secure makes it
+easier for organizations with strict security requirement to deploy OpenStack.
+
+Reduced Operational Complexity
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Today's RBAC enforcement implementation lacks secure defaults, but it is
+somewhat configurable. Deployments that must have a more secure enforcement
+implementation are forced to maintain arduously complex configuration files.
+Furthermore, many organizations re-implement similar use cases.
+
+Interoperability
+~~~~~~~~~~~~~~~~
+
+Because policy configuration gives deployments the flexibility to maintain
+complicated policies at their own expense, it is common to see many
+organizations solve the same problem. Unfortunately, it's unlikely
+organizations are sharing the same solution. This pattern impedes
+interoperability between deployments, making it frustrating for users
+interacting with different OpenStack clouds.
+
+Offering a reasonable set of roles and implementing basic RBAC improves
+interoperability by not requiring each organization to solve the same problem
+individually.
+
+-----------------
+
+Contact
+-------
+
+To contribute to this initiative, contact the `champion`_ of this goal or the
+`OpenStack Technical Committee`_.
+
+.. _community-wide rbac goal: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html
+.. _champion: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#champion
+.. _OpenStack Technical Committee: https://governance.openstack.org/tc/

reference/upstream-investment-opportunities/index.rst

@@ -28,7 +28,7 @@ Current Investment Opportunities
 .. toctree::
     :maxdepth: 2
 
-    2022/index
+    2023/index
 
 Previous Investment Opportunities
 ---------------------------------
@@ -42,6 +42,7 @@ Previous Investment Opportunities
 .. toctree::
     :maxdepth: 2
 
+    2022/index
     2021/index
     2020/index
     2019/index