← Back to team overview

openstack-poc team mailing list archive

Revisit project autonomy / project philosophy discussion

 

I'm starting a separate thread here so that we can keep the discussions clear in our minds.

It seems that there is some misunderstanding on what was discussed and decided a couple of weeks ago. A decision was made, but what that even means still seems unclear.

I'm not sure that anyone is advocating for complete project autonomy in all respects. (I say this as the person who seems to be the strongest advocate for autonomy--please correct me if I'm wrong here.) With no guidelines or requirements on projects, Openstack ceases to mean much at all. That being said, I do think that projects should have a great deal of latitude.

I believe OpenStack should should provide:
	• A common unifying vision for the group that each individual project must agree to
	• Central place to go for:
		• OpenStack releases.
		• OpenStack documentation.
		• Bug reporting.
		• Roadmaps.
		• Managing OpenStack packaging of projects.

Everything else should be guidelines and support in implementation if those guidelines are desired. Such as:
	• Code hosting
	• Bug tracking
	• Roadmap planning
	• Project releases and packaging

So, as long as a project meets the dictated rules in the first section, it shouldn't matter how they accomplish it in the second section. If a project team really really wants to use Bitkeeper and Bugzilla to manage their project, that should be fine, even if they have to manually update the OpenStack centralized bug reports and roadmaps. If they tend to only use Red Hat in their work, and therefore their project releases and packaging, that should be fine as long as they update the OpenStack packaging for the OpenStack releases.

I believe this sort of autonomy provides for differences in project teams, project lifecycles, and reduces barriers for new projects to join.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Follow ups