This is a new project to create a cookiecutter template repo for
use in creating tempest-plugin repos.
Change-Id: I5c7c7fc2ba274b651954c27b0acce3d6ebd0a57d
This change adds puppet-murano to the OpenStack Puppet
Modules project, which will contain the module necessary to configure
and manage Murano with Puppet.
Change-Id: Id846941c9002194e76a6ac31c1979d410aa25fb9
Depends-On: Ia7e917b3032ef5ea56b33cf92e6b7c2d62674f6a
We recently approved an infra-spec to host trystack.o.o[1]; as such we
need to import the current trystack.org website bits into infra.
NOTE: this request does not affect how or where the sandbox
environments runs. This is outside the scope of this repo.
[1] http://specs.openstack.org/openstack-infra/infra-specs/specs/trystack-site.html
Change-Id: I1651f35353705ba8c869bf245dbfc6bbb9588e27
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
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
