notmyname/gist:1052036

## gistfile1.txt
My hope for project autonomy:

 - Projects are highly autonomous (code hosting, issue tracking, versioning, release schedules, branching models, developer workflow, etc)
 - Projects are required to integrate with Openstack releases and support the open goals of Openstack

This implies that Openstack is a collection of affiliated projects that work well together and are distributed together as an official Openstack release. Openstack can require that projects follow good coding practices (reviews, tests, version control, etc), but these requirments should be descriptive rather than prescriptive. For example, Openstack can require that a project use version control, recommend bzr, but allow the project to choose what they want.

As an example from swift (because that's my experience), the swift devs choose their own code hosting and issue tracking. For releases, the swift team (or PTL) provides the openstack packagers info on what's changed. This can be in the form of changelogs, copies of bug reports in LP, or copies of blueprints in LP. The dev team also should coordinate with the Openstack release manager to ensure that each Openstack release has a stable, supported version of swift that integrates with the other Openstack projects.

The swift way of doing things is probably different than the way another project may choose to do something, and that's the point. A high degree of autonomy allows each project to choose what's best for their own particular project. This will also reduce barriers to entry for projects that wish to join Openstack.
	My hope for project autonomy:

	- Projects are highly autonomous (code hosting, issue tracking, versioning, release schedules, branching models, developer workflow, etc)
	- Projects are required to integrate with Openstack releases and support the open goals of Openstack

	This implies that Openstack is a collection of affiliated projects that work well together and are distributed together as an official Openstack release. Openstack can require that projects follow good coding practices (reviews, tests, version control, etc), but these requirments should be descriptive rather than prescriptive. For example, Openstack can require that a project use version control, recommend bzr, but allow the project to choose what they want.

	As an example from swift (because that's my experience), the swift devs choose their own code hosting and issue tracking. For releases, the swift team (or PTL) provides the openstack packagers info on what's changed. This can be in the form of changelogs, copies of bug reports in LP, or copies of blueprints in LP. The dev team also should coordinate with the Openstack release manager to ensure that each Openstack release has a stable, supported version of swift that integrates with the other Openstack projects.

	The swift way of doing things is probably different than the way another project may choose to do something, and that's the point. A high degree of autonomy allows each project to choose what's best for their own particular project. This will also reduce barriers to entry for projects that wish to join Openstack.