Add to docs tox target a check that reference/projects.yaml is sorted
alphabetically and display entries that are not sorted.
Change-Id: Ia86b50622e2fac5fdf791d57c884d2d8a9ec6c44
Since we generate a giant merge conflict with the introduction of
"deliverables" in the previous commit, take the opportunity to
reorder the file alphabetically. This will reduce future conflicts
when new projects add themselves at the end of the file.
Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
Our current projects.yaml file lists project teams and git
repositories associated to those. However, things we publish
as a single "thing" may be represented by multiple code
repositories. For example, a "neutron" release is actually made
of openstack/neutron and openstack/neutron-*aas. A "sahara"
release is actually made of openstack/sahara, openstack/sahara-extra
and openstack/sahara-image-elements. Those are all tagged at the
same time with the same version number, and published together
as a single "deliverable".
This change proposes to encode this layer in the projects.yaml file.
It also proposes to apply tags to the deliverable level rather than
at git repository level. Tags are meant to apply to things that are
consumed by our users, not to the technical pieces that help us
build those things. Note that for most projects have single-repo
deliverables and won't really look different. See Sahara and Neutron
in the proposed file to see examples of multi-repo deliverables.
Since this introduces a breaking change in the file format, we also
take the opportunity to simplify the YAML format: since tags no
longer have attributes they can be listed as an array rather than
as a dictionary, sparing us the useless "name:" part.
Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
This adds a resolution to retire the stackforge/ namespace in
favor of allowing all projects to use the openstack/ namespace.
This facilitates project development lifecycle transitions between
Stackforge and Openstack.
Change-Id: I6a895af592545b56293947b91579bfc7e6d4385a
With the change to big tent, many new projects are entering the big
tent with only one corporate contributor composing the core team.
An example that causes this script to break in Congress. This
patch produces the desired statistical results without crashing.
Change-Id: I0cae8a6864918d4f65e78829dc48f1af092ca7e8
The full project proposal can be found at
https://wiki.openstack.org/wiki/UX/ProgramProposal
The mission of the UX Program is to support and
facilitate cross-project efforts to improve the overall
user experience of OpenStack.
We provide user research to help teams identify any issues
preventing adoption of their services as well as help the
projects validate design and development efforts to address
those issues. In addition, we help the project teams create
solutions to address customer needs and pain points.
Finally, we will provide the OpenStack community with
visibility into any user experience issues related to
inconsistency across projects.
The UX team is not prescriptive; our goal is to collaborate
with OpenStack’s projects to create better experiences.
Contribution
Member contribution to the UX Project would be measured on
three metrics:
* No. of mock submissions to Invision
* No. of reviews/comments in Invision
* No. of UX studies conducted on behalf of the community
Invision is being provided to OpenStack at no charge as long as
the projects are shared within the open source community.Invision’s
concern was that folks might use our platform for internal
proprietary projects, which is not allowed.
We have 12 administers and 104 managers in Invision that
can add users and create projects from companies including
IBM, Mirantis, HP, and Redhat. We were very careful to
make sure that no single person or company had complete
control of the platform.
We are constantly looking for open source alternatives including
phabricator (phabricator.org), which is being discussed for
adoption by the community as a code review tool. Phabricator
also includes a design review that enables users to leave comments
on an image uploaded to the system. An added benefit is that
both code and UX review would be integrated into the same tool.
It is also important to note that projects can be downloaded from
Invision as PDF files that include both images and any comments
from users. If the community moves away from Invision, the plan
would be to make the PDFs available on the OpenStack UX wiki.
Project Communication
UX meetings were scheduled to occur every other week on IRC
but eventually slowed-down because most of the design efforts
were specifically focused on improving Horizon. That will
eventually change as the UX team engages additional projects.
In addition, IRC is a bit difficult to use within a discipline that is
largely aesthetic.
An additional way to get quick feedback or have a discussion with
the UX group is to join the IRC channel on freenode
(#openstack-ux).
There is a design review that occurs every other week were
community members are invited to share their design work
with the community. These meetings occur via virtual room
rather than IRC because the reviews require the participants to
“see” the designs in order to provide feedback.
A user panel was formed about two months ago in order to
provide feedback to the community from actual users. In
some ways, the user panel is intended to provide an alternative
“voice” to the development community.
The panel is struggling somewhat because we haven’t agreed
on a format for the meetings. For example, one suggestion was
to have a panel members talk about their specific challenges
during a session.
Panel members include users from NSA, Cisco, Pacific Northwest
National Labs, Orange and Yahoo.
Interim PTL
Until we have elections, Pieter Kruithof will be the PTL for delux.
Piet is currently a Sr UX Architect with HP Helion Cloud and
specifically focuses on improving the user experience of OpenStack.
This includes tactical activities such as proposing new designs in
addition to more strategic efforts such as providing platforms that
help enable collaboration within the community.
Piet was also a former Director with the Board of Certification in
Professional Ergonomics (BCPE). The board was established in
1990 as an independent nonprofit organization and is the certifying
body for individuals whose education and experience indicate broad
expertise in the practice of human factors, ergonomics and
user experience research.
Team members include engineers from IBM, Cisco, RackSpace,
HP and Mirantis.
Links
UX wiki
https://wiki.openstack.org/wiki/UX#Horizon_Proposals
User Research wiki
https://wiki.openstack.org/wiki/HorizonUsability_Testing
OpenStack UX patterns
https://wiki.openstack.org/wiki/UX/PatternsLibrary
OpenStack Invision Community
https://openstack.invisionapp.com
Change-Id: I4672d15a8e91190f05ba59086cc3b15f114d5f04
This postulates that tags should be tags, and therefore shouldn't
have attributes.
Attributes in tags were originally meant to hold additional
information on the area described by the tag. However, ideally
tags are self-contained units of information, with an opinionated
description (and ideally an objective set of application rules).
Keeping the option of having attributes in tags adds useless format
complexity and steers tags in the direction of structured project
metadata. Project structured metadata (like the ops-data) is fine,
it's just not the same thing as tags. Continuing to support
attributes in tags IMHO encourages the confusion between the two.
The integrated-release tag was the only one using attributes,
and it's now removed.
Change-Id: I1dd5c8090405bd87e8947892d78c62509258e363
In keeping with the concept of expanding a basic compute cloud through
non-disruptive additions, cinder is additional functionality that can be
reasonably added as a next step in making the cloud do more things.
Change-Id: If4b9b94867e093c27c1e2b67dc7c47f43afc907a
Also be clearer that the gate we want has to be on the OpenStack
infra, not in some random other place, and finally, move the ability
to make new repos from being a 'requirement' to being separate prose.
Change-Id: I38e545f8539195d79d6dfb42a8ec0d8eca435ccd
The VMT is building out automation and reporting for vulnerability
management processes in order to better accomodate the rapid growth
of the OpenStack ecosystem. In an order to scale consumability of
its processes beyond its current charter and capacity, a formal
acknowledgement of the list of source code repositories directly
handled by the VMT (rather than managed independently by individual
project teams) is best maintained through application of a
governance-related tag.
Change-Id: I1260839b50b6a5ff57a6649e419094f2d4f7f877
Host all packaging git repos for rpm based distributions in the
/openstack namespace in order to have gating and review of changes
to the packaging close to the actual OpenStack development.
Change-Id: I608651414fadc0206910d2720d8d14be51a5c8af
While nova-network is still supported because of concerns about
migration paths, neutron should be as strongly recommended for any new
deployments as is humanly possible so that we can ultimately get
ourselves out of the mess of having two network stacks.
Since starter-kit:compute is intended to help point a finger at what
people should install when trying things out, we should certainly not
imply that they install a network stack that we plan on deleting in the
future. Neutron in provider-vlan/linuxbridge mode is dead simple in not
requiring openvswitch or SDN, and still gets new users a cloud that is
upwards flexible with the future.
Change-Id: I91bce1bcc51121a8a577cff478fdc91002b689b4
Kuryr aims to service the Docker Container Network Model[1] by leveraging
Neutron in a way similar to how Nova does.
(Directing API's to Neutron API's)
The project will serve as a single effort point for connecting
the various Neutron sub projects with Dockers and provide
different Docker plumbing (connecting the docker instances into
the overlay) images for the various different Neutron plugins
and implementations
[1] https://github.com/docker/docker/blob/master/experimental/networking.md
Change-Id: Ia774a4f4d60377a42e8a5d3ba8a3f3eaace662e4
Depends-On: I38f24906493e25575b084b06b7a62bbfc0c2f414
A new git repo for hosting devstack amqp1 plugin
Depends-On: Ifcc52fee113a9f24fe028bef6e22fc4b68a694f7
Change-Id: I41f50e941a93a4c217bfcbdade6deb052a848dcb
In the Liberty cycle we support new release models, which made
the current release tags taxonomy a bit unusable.
Switch to a new model taxonomy where a repository may only have
one release model:
* release:cycle-with-milestones (think keystone or nova)
* release:cycle-with-intermediary (think swift or libraries)
* release:independent (think zuul)
* release:none (think: openstack/governance)
This will clarify which release models actually exist, and
more clearly communicate to our users (and our tooling) which
model each repository follows.
We also adapt the wording of the release:managed tag to avoid
excluding swift or Oslo libraries (which do not follow the
development milestones model) from being managed if the release
team accepts them.
Change-Id: Ie58a370f2a189a421040535b99949f3fac9eb4eb
