Launchpad Entry: bexar-dev-community
Created: 2010-11-11
Contributors: ThierryCarrez
Summary
Efforts to make sure the OpenStack development community is a welcoming and inclusive environment.
Release Note
OpenStack is an even better place to contribute to now.
Rationale
Dev community building is a necessary activity.
User stories
Adam has no clue about open source development and is a bit lost when "bzr", "irc" and other 3-letter acronyms are thrown in the discussion. He reads the "Basics" wiki page and is ready to go.
Chuck is an open source developer that is interested in OpenStack. He reads the available "Contributor" documentation on the wiki, understands our processes and is now ready to contribute.
Soren is an existing OpenStack developer. He reads the "Reference" documentation on the wiki and on the corresponding doc sites to be able to do the right thing in his OpenStack work.
Assumptions
None.
Design
Merge review process
- Require 2 core devs reviews (enforce it by LP ?)
Communication media
- Status: use blueprint and bug status
- IRC: keep one channel
- Mailing-lists: collapse them into one
Wiki: more obvious openstack.org -> wiki link (AnneGentle notes: according to Google Analytics it's the most clicked through link on openstack.org by quite a bit (twice as much), so I don't think we need to make it more obvious.)
- Planet: Open it to attract as many people as possible
Documentation
Basics documents (AnneGentle)
- "openstack on a stick" demo for easy discovery (AnneGentle/Dustin working on it)
IRC tutorial (maybe point to freenode URL/web-based client) (See UsingIRC, is this considered done?)
Life with bzr and LP (Added text to define bzr and lp to the LifeWithBzrAndLaunchpad, is that enough? I will review again in the future.)
Go from getting the code to testing (AnneGentle will do)
Associated technologies (AnneGentle will do)
- Contributor doc (ttx/AnneGentle)
- Process to add features (including explanation of blueprint/review/dev process)
- Process to triage bugs
- Process to contribute bug fixes
- Process for branch review
- Reference doc (ttx)
- Blueprints lifecycle/status
- Bugs lifecycle/status
- Release cycle, freezes, milestones
- Release schedule
- Coding standards for developers (PEP8, ensure doc strings are complete, etc.)
- Review guidelines
Implementation
Prio 1
- Publish release schedule (ttx)
- Write Release cycle, freezes, milestones doc (ttx)
- Write Blueprints lifecycle, with corresponding status and explanation of each field (ttx)
- Write Bugs lifecycle, with corresponding status and explanation of each field (ttx)
- Collapse Mailing-lists into one (dendrobates)
Prio 2
- Write Process to contribute bugfixes (ttx/AnneGentle)
- Write review guidelines (ttx)
- Write Process to triage bugs (ttx/AnneGentle)
Review/Enhance life with bzr and LP from a first-timer perspective (AnneGentle)
Write Go from getting the code to testing (AnneGentle)
- Planet: Open it to attract as many people as possible (all)
Prio 3
- Process to add features (ttx/AnneGentle)
- Process for branch review (ttx/AnneGentle)
- Coding standards for developers (ttx)
Create the "openstack on a stick" demo for easy discovery (AnneGentle)
- Look into enforcing 2 core devs reviews by LP (ttx)
List of associated technologies (AnneGentle)
Test/Demo Plan
None.
Unresolved issues
None.
BoF agenda and discussion
Etherpad @ http://etherpad.openstack.org/BexarDevCommunity
One thing that would make it easy to contribute is to list the technologies that one needs to be familiar with before contributing to each Nova/Swift components. Frameworks that look simple for Python veterans like twisted, WSGI, Tornado, eventlet, Carrot, etc. This would be especially useful to people who come for a background of C/Java/C# dev.