:title: OpenDev Project
.. _infra-project:
OpenDev Project
###############
OpenDev is an evolution of the OpenStack Infrastructure project. The
goal is to make OpenStack's proven software development tools available
for projects outside of OpenStack. We believe that Free Software needs
Free tools and OpenDev provides one such set that has been proven to
work at large and small scales of development.
The OpenDev team is an open meritocracy that welcomes new members. We
follow OpenStack's `Four Opens `_.
Scope
=====
OpenDev now covers many of the original OpenStack Infrastructure systems,
but not all. The goal is to run any service that has generic applicability
for open and collaborative software development in OpenDev. OpenStack and
other project specific tooling would be managed by those projects outside
of OpenDev.
In particular OpenDev covers the operations and development of code
management systems and collaboration tools. Git repository management, code
review, continuous integration, etherpads, mailing lists, and more are all
within the scope of OpenDev. All of the software we run is open source, and
openly operated through configuration files stored in git.
Contributing
============
.. note::
Until we complete the transition from OpenStack Infra to OpenDev some
communication platforms will remain under "OpenStack". Expect
this list to get smaller over time.
We welcome contributions from new contributors. Reading this
documentation is the first step. You should also join our `announcements
`_
and `discussion
`_
mailing lists.
We are most active on IRC, so please join the **#opendev**
channel on OFTC.
Feel free to attend our `weekly IRC meeting
`_
on Tuesdays at 19:00 UTC in #opendev-meeting on OFTC.
To read about how our systems are managed and how to view or edit
those configurations, see :ref:`sysadmin`.
We also have a collection of `OpenStack Project Infrastructure Publications
`_ where we host slides for
presentations team members have given about the infrastructure.
And if you have any questions, please ask.
Bugs
====
The OpenDev project maintains a bug list at:
https://storyboard.openstack.org/#!/project_group/55
Both defects and new features are tracked in the bug system. A number
of tags are used to indicate relevance to a particular subsystem.
There is also a low-hanging-fruit tag associated with bugs that should
provide a gentle introduction to working on the OpenDev project
without needing too much in-depth knowledge or access.
Priority Efforts
================
The OpenDev project designates a small number of efforts
underway at any time as priority efforts. These are areas where the
project has decided to focus resources to achieve major initiatives.
These help reviewers prioritize their review workload and help to
ensure the project accomplishes important tasks. Priority efforts are
a great way to get involved in the project as they will generally
provide the most interaction with experienced contributors.
Priority efforts are documented in the infra-specs repo. Each
priority effort has one entry in infra-specs, though that may link to
multiple smaller specifications for individual units of work if the
effort is sufficiently large. Each priority effort also has a single
person designated as the driver of that effort. That person is
responsible for ensuring that anything blocking progress of the effort
is discussed at team meetings and may be a good point of contact for
someone who wants to get involved.
Changes not related to priority efforts will be reviewed by the core
review team as time permits. This may mean that they spend
considerable time in review, but they will be reviewed eventually. If
a change is urgent, you might consider contacting someone in
#opendev on OFTC.
Governance
==========
The OpenDev project is governed by two entities. The first is the
Service Coordinator. They coordinate work of contributors and act as
a tie breaker when clear consensus isn't found. The Service Coordinator is
responsible for managing spec reviews and core team membership (details
below). This role is essentially the same as the old Infra PTL role.
The Service Coordinator is elected every 6 months. The nominee pool and
electorate are individuals that have contributed changes to OpenDev git
repositories in the last 12 months.
The second is an Advisory Board made up of representatives from OpenDev's
user base of projects and organizations that contribute compute resources.
This Advisory Board provides a formal location for those key
stakeholders to express their needs to the OpenDev project.
This creates a clear contact point for feedback on priorities and direction.
Their input will help ensure that the OpenDev project is a good steward of
the resources provided to it and that user needs are being addressed.
Contributing orgs and user projects are not required to join the Advisory
Board, but are encouraged to do so. Individuals on the board would be
selected by their own constituency as that constituency feels is
appropriate.
The Advisory Board will also serve as a point of contact for the OpenDev
project when making changes that may be disruptive. The intent is to create
bidirectional communication between OpenDev and its constituent
organizations.
Teams
-----
The OpenDev project is open, meaning anyone may join and begin
contributing with no formal process. As an individual's contributions
and involvement grow, there are more formal roles. These roles are
designed to empower groups of people to get work done in their area of
expertise and interest, as well as supply a strong sense of direction
for the OpenDev project as a whole. Everyone participating in
the project is encouraged to expand their own knowledge while helping
to support and mentor others as they progress.
Core Teams
The OpenDev project is composed of a large number of
subprojects. Every source code repository has its own core team
which is responsible for maintenance of that subproject, with some
groups of repositories sharing a core team. These core teams are
empowered to approve changes that reflect the currently understood
project direction. Changes in project direction or major new
initiatives must be approved by the OpenDev council.
Any existing core team member may nominate someone for addition to
that core team by private communication with the OpenDev Service
Coordinator. The Service Coordinator will consider the opinions of the
existing core team members and the review history of the person in
question, but final determination of core team membership (additions and
removals) rests with the Service Coordinator. This process is private to
enable honest evaluations in a safe environment.
OpenDev Core Team
Individuals who show an interest in a wide range of areas of the
OpenDev project may be asked to join the infra-core team. To
provide a baseline level of support to all of our subprojects and to
ensure that important efforts may move forward, this team has
approval rights in all OpenDev repositories. Members of this
team may not be experts in all areas, but know their limits, and
will not exceed those limits when reviewing changes outside of their
area of expertise.
They are expected to have a wide general knowledge of what is going
on in the OpenDev project and to help guide overall project
direction. To that end, they are able to veto specs proposed to the
OpenDev council.
OpenDev Council
The OpenDev council is the technical design body for the
Opendev project. While individuals and groups are empowered
to execute the designs from the council, major technical designs are
agreed upon as a group to ensure that our large set of projects are
all working together to the same end. The council need not delve
too deeply into technical detail -- just enough so that development
efforts may happen in parallel and work toward a common goal.
All members of any OpenDev project core team have a seat on
the Council. The Council is responsible for approving changes in
project direction, major new initiatives, setting priority efforts,
and addition or removal of projects.
Any such changes should be proposed to the infra-specs repository.
Anyone is welcome to review specs and they are expected to evolve
during the review process. When a change to infra-specs is ready
for final approval, the author will add the change to the infra team
meeting agenda so that the entire team is notified that the spec is
ready. Members of the council will vote by leaving reviews on the
spec to approve or reject the change. The determination will be
based on a majority vote, with members of the infra-core team able
to veto, and in the case of a tie, the Service Coordinator will cast
the deciding vote. The Service Coordinator will execute the workflow
action on the change after the vote.
Specs are living documents, and once approved, should be maintained
for the duration of the effort they describe. Substantial changes
in direction should go through the same process described above.
The Service Coordinator may chose to approve insubstantial changes
without the formal council voting process.
OpenDev Root Team
Core membership enables one to approve changes within our code
repositories. Because the OpenDev team operates
production servers there is another sub-group of the OpenDev
team that has root access to all servers. Root membership is
handled in the same way as core membership. Root members must also
be infra-core members, but infra-core members may not necessarily be
root members. This is because primary system administration is
performed through code review, so anyone able to log into a machine
to execute commands must be able to approve those same commands in
configuration management; otherwise it would be easier for a person
to bypass configuration management than use it in the intended
fashion.
Root access is generally only necessary to launch new servers,
perform low-level maintenance, manage DNS, or fix problems. In
general it is not needed for day-to-day system administration and
configuration which is done through automated config management tools
(where anyone may propose changes). Therefore it is generally
reserved for people who are well versed in OpenDev operations and can
commit to spending a significant amount of time troubleshooting on servers.
Some individuals may need root access to individual servers; in
these cases the infra-core group may grant root access on a limited
basis.
Review Criteria
===============
We review each others changes before they are merged. This helps us
improve the quality of the code we produce as well as ensure that we
are working together as a team. Generally we expect at least two
members of the core review team to approve a change before it is
merged, but we are flexible in this requirement -- typo fixes, or
other simple changes may be approved with less formality.
The primary purpose of change review is to catch substantial errors
before they are merged. In order to keep this process useful and
avoid frustration for both authors and reviewers, please do not leave
negative reviews for insubstantial faults or potential improvements.
The purpose is not to make someone else's code match your vision of
perfection, but to enable all of us to work together on a project.
Please use discretion when deciding what is important enough for
someone to spend the time to rework and for you to spend the time
re-reviewing. Sometimes minor things are important, such as
consistent use of hyphens versus underscores in a configuration
language. Sometimes they are not, such as whitespace in
documentation.
If you would like to mention minor improvements such as this, feel
free to do so, but please do not leave a negative score on the review.
If you mention them along with other more substantial criticisms,
please note them in a review, for example, with "(nit)" or "(not a
-1)" or "you may want to fix this if you are updating the patch
anyway".
Please also see the section in the Infrastructure Manual on `peer review
`_.