Contributor Portal Next Steps
Landing Page Mock ups
- [ ] thingee: A proposal for the second level of what the landing page
- [ ] thingee: Follow up with the Wes and Jimmy at the OpenStack Foundation
for design assistance.
Communication To The Community
Highlights from PTG session
TLDR (big changes from discussion)
- Instead of all team on-boarding documentation living in a central
repository, it will still remain with the individual teams to maintain in
their own repository. General documentation (e.g. git, creating accounts,
gerrit setup, etc) will still live in this central repo. If you choose to
contribute by code for example and you pick a project, it will take you
through our general documentation, then the project’s specific documentation.
- This could lead to inconsistencies in documentation design? Confusion
for the reader being sent to different pages?
- We can’t go based off services. Not everything people are contributing
to is a service, so they won't have anything corresponding in the
service type authority
There might be a field in projects.yaml that can help with this.
- Remind Thierry on the service type authority repo for
- Videos were considered, but they’re hard to keep up-to-date.
Previous Documentation PTL Alexandra Settle expressed that even
screenshots can get out of date real fast.
- Generate some kind of crash-course / cheatsheet content for people
who are used to GitHub but not familiar with Gerrit. Aspiers
volunteered for this and made this first pass ethercalc
- Translation team needs to be included
- Provide documentation with how to edit the landing page, since the
source is being hosted on github (there are transition discussions in
place with the infra team and Jimmy)
- Help projects with creating their own contributor guides if they
need to. Think of something like Cookie cutter for setting up the
scaffolding for a new OpenStack project, but getting projects
contributor guides going.
Attendees of the session we’re more in favor of projects keeping
their specific documentation owned in their repositories. As learned
from the centralize documentation problem
this is a good move. Upstream institute would then use whatever
general documentation is provided. If people get past that, we could
even suggest on-boarding to one of the top 5 most wanted
Lauren Sell worked with Melvin and others from the user committee to get their
requirements and perspective on the project. Here's an ether pad:
Mock Up Feedback
- Having the service types is great, but on the next level it would
be good to express the code name with a description of what the
- Combine in events OpenStack day, meetups, forum, ptg, etc.
(emphasize on in person thing)
- A word that combines code and documentation ("team(s)" was already
OpenStack Development Mailing List (not for usage questions)