+1 Did not have a chance to draft a message but thanks for ops mention.
On Jun 29, 2017 3:02 PM, "Amy Marrich" <a...@demarco.com> 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 <thin...@gmail.com> 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 (thin...@gmail.com) 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 >> user-commit...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee >> > > > _______________________________________________ > User-committee mailing list > user-commit...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee > >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack