<div dir="ltr">Hi stackers, <div><br></div><div>it goes without saying that working on cross-project stuff in OpenStack is quite hard task. </div><div><br></div><div>Because it's always hard to align something between a lot of people from different project. And when topic start being too "HOT"  the discussion goes in wrong direction and attempt to do cross project change fails, as a result maybe not *ideal* but *good enough* change in OpenStack will be abandoned. </div><div><br></div><div>The another issue that we have are "specs". Projects are asking to make spec for change in their project, and in case of cross project stuff you need to make N similar specs (for every project). That is really hard to manage, and as a result you have N different specs that are describing the similar stuff. </div><div><br></div><div>To make this process more formal, clear and simple, let's reuse process of "specs" but do it in one repo /openstack/cross-project-specs.</div><div><br></div><div>It means that every cross project topic: Unification of python clients, Unification of logging, profiling, debugging api, bunch of others will be discussed in one single place..</div><div><br></div><div>Process description of cross-project-specs:</div><div><ul><li>PTL - person that mange core team members list and puts workflow +1 on accepted specs</li><li>Every project have 1 core position (stackforge projects are included)</li><li>Cores are chosen by project team, they task is to advocate project team opinion </li><li>No more veto, and -2 votes</li><li>If > 75% cores +1 spec it's accepted. It means that all project have to accept this change.</li><li>Accepted specs gret high priority blueprints in all projects</li></ul></div><div><br></div><div>With such simple rules we will simplify cross project work: </div><div><br></div><div>1) Fair rules for all projects, as every project has 1 core that has 1 vote. </div><div>2) Small team that works  on cross project features. </div><div>3) Faster adoption of cross features </div><div>4) Single person/project is not able to block adoption of feature</div><div>5) Code unification between projects. E.g. single feature has same implementation in all projects, and this specification is specified in spec.</div><div> </div><div><br></div><div>This is just a draft. Any thoughts and ideas are welcome.</div><div><br></div><div> <br></div><div>Best regards,</div><div>Boris Pavlovic </div></div>