Hey Melvin, Ah yes, I should’ve mentioned earlier that this is totally a POC. There are lots missing, don’t worry! :)
— Mike Perez On June 29, 2017 at 13:47:14, Melvin Hillsman ([email protected]) wrote: > +1 > > Did not have a chance to draft a message but thanks for ops mention. > > On Jun 29, 2017 3:02 PM, "Amy Marrich" wrote: > > > First off it looks really sleek and I love the look! A few thoughts though > > and I do realize it's just a mock up: > > > > 1) We have Sponsor just to pick one but don't have > > Operators/Administrators and their feedback is a major contribution so > > please don't leave them out. > > 2) I would list the contributor types in alphabetical order that way no > > group feels slighted, you can't help it if Use Cases are last it's just > > that they start with a U vs Code which is a C. > > 3) What if you would like to contribute in multiple ways? > > > > Resources are definitely still underdevelopment there but are they meant > > to be broad applicable to all resources with more specialized one's visible > > when you click on how you'd like to contribute? > > > > Amy (spotz) > > > > On Thu, Jun 29, 2017 at 2:03 PM, Mike Perez wrote: > > > >> Hello all, > >> > >> Wes has just took my ugly mock up of the contributor portal idea and > >> came up with this [1]. > >> > >> Here’s what he said: > >> > >> "The idea is to help get potential contributors to the right place, > >> using the outline Mike put together. Rather than sending people to a > >> different page for each contribution type, users would be able to see > >> what options are available all on this page. We’d send them to any > >> necessary page(s) once they’ve gone through this quasi-wizard. Is this > >> along the lines of what you were thinking? page 2 shows the view once > >> you’ve clicked “Code” on page 1 (just in case that wasn’t super > >> obvious) Thanks!” > >> > >> What do you all think? This does change things a bit of instead of the > >> landing page being more obvious of a resource of links, it’s both for > >> new and current contributors. Current contributors would hopefully be > >> able to see the resource links below. > >> > >> Keep in mind that we will be working in the “Top 5 requested help” and > >> as suggested by Clark, an option of “I don’t know where I want to > >> start, but I want to help” kind of option. This would direct people to > >> resources such as Upstream University, mentor program, low hanging > >> fruit, that release priority idea I talked about earlier, etc. > >> > >> Personally I like it! > >> > >> > >> [1] - https://www.dropbox.com/s/3q172qwfkik1ysd/contributor-port > >> al.pdf?dl=0 > >> > >> — > >> Mike Perez > >> > >> On June 27, 2017 at 13:48:36, Mike Perez ([email protected]) wrote: > >> > Hello all, > >> > > >> > Every month we have people asking on IRC or the dev mailing list having > >> interest in working > >> > on OpenStack, and sometimes they're given different answers from > >> people, or worse, > >> > no answer at all. > >> > > >> > Suggestion: lets work our efforts together to create some common > >> documentation so that > >> > all teams in OpenStack can benefit. > >> > > >> > First it’s important to note that we’re not just talking about code > >> projects here. OpenStack > >> > contributions come in many forms such as running meet ups, identifying > >> use cases (product > >> > working group), documentation, testing, etc. We want to make sure those > >> potential contributors > >> > feel welcomed too! > >> > > >> > What is common documentation? Things like setting up Git, the many > >> accounts you need > >> > to setup to contribute (gerrit, launchpad, OpenStack foundation > >> account). Not all > >> > teams will use some common documentation, but the point is one or more > >> projects will use > >> > them. Having the common documentation worked on by various projects > >> will better help > >> > prevent duplicated efforts, inconsistent documentation, and hopefully > >> just more > >> > accurate information. > >> > > >> > A team might use special tools to do their work. These can also be > >> integrated in this idea > >> > as well. > >> > > >> > Once we have common documentation we can have something like: > >> > 1. Choose your own adventure: I want to contribute by code > >> > 2. What service type are you interested in? (Database, Block storage, > >> compute) > >> > 3. Here’s step-by-step common documentation to setting up Git, IRC, > >> Mailing Lists, > >> > Accounts, etc. > >> > 4. A service type project might choose to also include additional > >> documentation in that > >> > flow for special tools, etc. > >> > > >> > Important things to note in this flow: > >> > * How do you want to contribute? > >> > * Here are **clear** names that identify the team. Not code names like > >> Cloud Kitty, Cinder, > >> > etc. > >> > * The documentation should really aim to not be daunting: > >> > * Someone should be able to glance at it and feel like they can finish > >> things in five minutes. > >> > Not be yet another tab left in their browser that they’ll eventually > >> forget about > >> > * No wall of text! > >> > * Use screen shots > >> > * Avoid covering every issue you could hit along the way. > >> > > >> > ## Examples of More Simple Documentation > >> > I worked on some documentation for the Upstream University preparation > >> that has received > >> > excellent feedback meet close to these suggestions: > >> > * IRC [1] > >> > * Git [2] > >> > * Account Setup [3] > >> > > >> > ## 500 Feet Birds Eye view > >> > There will be a Contributor landing page on the openstack.org website. > >> Existing contributors > >> > will find reference links to quickly jump to things. New contributors > >> will find a banner > >> > at the top of the page to direct them to the choose your own adventure > >> to contributing to > >> > OpenStack, with ordered documentation flow that reuses existing > >> documentation when > >> > necessary. Picture also a progress bar somewhere to show how close you > >> are to being ready > >> > to contribute to whatever team. Of course there are a lot of other > >> fancy things we can come > >> > up with, but I think getting something up as an initial pass would be > >> better than what we > >> > have today. > >> > > >> > Here's an example of what the sections/chapters could look like: > >> > > >> > - Code > >> > * Volumes (Cinder) > >> > * IRC > >> > * Git > >> > * Account Setup > >> > * Generating Configs > >> > * Compute (Nova) > >> > * IRC > >> > * Git > >> > * Account Setup > >> > * Something about hypervisors (matrix?) > >> > - Use Cases > >> > * Products (Product working group) > >> > * IRC > >> > * Git > >> > * Use Case format > >> > > >> > There are some rough mock up ideas [4]. Probably Sphinx will be fine > >> for this. Potentially > >> > we could use this content for conference lunch and learns, upstream > >> university, and > >> > the on-boarding events at the Forum. What do you all think? > >> > > >> > [1] - http://docs.openstack.org/upstream-training/irc.html > >> > [2] - http://docs.openstack.org/upstream-training/git.html > >> > [3] - http://docs.openstack.org/upstream-training/accounts.html > >> > [4] - https://www.dropbox.com/s/o46xh1cp0sv0045/OpenStack%20contri > >> butor%20portal.pdf?dl=0 > >> > >> _______________________________________________ > >> User-committee mailing list > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee > >> > > > > > > _______________________________________________ > > User-committee mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee > > > > > _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
