)]}'
{"reference/openstack-projects.rst":[{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"448ee1dcb17b67fb7f0d416f00c278ddde9f9d53","unresolved":false,"context_lines":[{"line_number":5,"context_line":"code namespace, and the associated individuals who contribute to the source"},{"line_number":6,"context_line":"code, tests and documentation for the project."},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"Projects living under the `openstack/` code namespace are recognized as \u0027\u0027being"},{"line_number":9,"context_line":"a piece of code that enhances the experience of OpenStack users\u0027\u0027."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Requirements for Projects to Live in the `openstack/` Code Namespace"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_7c0b9e7d","line":8,"updated":"2014-10-09 20:13:07.000000000","message":"Recognised by whom? How do they get to live under that namespace?","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"fe76acc0b06d923dbb4104d8430d122961cc0c6f","unresolved":false,"context_lines":[{"line_number":5,"context_line":"code namespace, and the associated individuals who contribute to the source"},{"line_number":6,"context_line":"code, tests and documentation for the project."},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"Projects living under the `openstack/` code namespace are recognized as \u0027\u0027being"},{"line_number":9,"context_line":"a piece of code that enhances the experience of OpenStack users\u0027\u0027."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Requirements for Projects to Live in the `openstack/` Code Namespace"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_c7684224","line":8,"in_reply_to":"9aa7fdbe_5d797692","updated":"2014-11-18 20:02:45.000000000","message":"I like that wording \"beneficial to and in alignment with the OpenStack mission\", yes.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"c5bb64e5af69226f9ab2f31768417fb62a67a5fd","unresolved":false,"context_lines":[{"line_number":5,"context_line":"code namespace, and the associated individuals who contribute to the source"},{"line_number":6,"context_line":"code, tests and documentation for the project."},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"Projects living under the `openstack/` code namespace are recognized as \u0027\u0027being"},{"line_number":9,"context_line":"a piece of code that enhances the experience of OpenStack users\u0027\u0027."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Requirements for Projects to Live in the `openstack/` Code Namespace"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9aa7fdbe_5d797692","line":8,"in_reply_to":"baa201ad_5a44db73","updated":"2014-10-20 05:22:18.000000000","message":"The wording \"a piece of code\" does not include docs, diagrams, etc. I would rather this avoid a reference to the word \"code\" and instead stick to an inclusive word such as \"project\".\n\nThat nit aside, this sentence reads like a tautology to me.\n\nIt lacks any definition of characteristics of a project currently in the openstack/ namespace, and basically says that \"OpenStack projects enhance the experience of OpenStack users\".\n\nI am guessing (and could be completely off-base) that you meant to say something more like, \"projects within openstack/* namespace are recognized as being beneficial to and in alignment with the OpenStack mission\", though you left out any mention of that mission in this draft.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"62c41dfa2da021cdb06c8ce33f2ec42604b68211","unresolved":false,"context_lines":[{"line_number":5,"context_line":"code namespace, and the associated individuals who contribute to the source"},{"line_number":6,"context_line":"code, tests and documentation for the project."},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"Projects living under the `openstack/` code namespace are recognized as \u0027\u0027being"},{"line_number":9,"context_line":"a piece of code that enhances the experience of OpenStack users\u0027\u0027."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Requirements for Projects to Live in the `openstack/` Code Namespace"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_5a44db73","line":8,"in_reply_to":"baa201ad_7c0b9e7d","updated":"2014-10-13 15:10:36.000000000","message":"Recognized by the \"community\" as enhancing the experience of OpenStack users. The \"community\" would be the set of individuals that have +2 rights on the openstack/project-config repository (see below). This team should be composed of TC members (in order to give elected representatives of the community a vote) and folks that understand our technical onboarding systems -- i.e. the people already on the current project-config-core Gerrit team.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"c5bb64e5af69226f9ab2f31768417fb62a67a5fd","unresolved":false,"context_lines":[{"line_number":11,"context_line":"Requirements for Projects to Live in the `openstack/` Code Namespace"},{"line_number":12,"context_line":"--------------------------------------------------------------------"},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"The requirements for inclusion in the `openstack/` code namespace are as"},{"line_number":15,"context_line":"follows:"},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"- The project source code is licensed under the Apache 2.0 License"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9aa7fdbe_e208cb2f","line":14,"updated":"2014-10-20 05:22:18.000000000","message":"This may be your intent here, but I\u0027d like to call it out to verify whether it was or wasn\u0027t intended -- this wording has removed all mention of quality, maturity, diversity, or activity from a project and its contributor base. While in a big-tent model, holding those as requirements for inclusion is unreasonable, I still see value in listing them as aspirations. (Perhaps that\u0027s something you plan to cover in a discussion of \"tags\" in the following patch?)","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"fe76acc0b06d923dbb4104d8430d122961cc0c6f","unresolved":false,"context_lines":[{"line_number":11,"context_line":"Requirements for Projects to Live in the `openstack/` Code Namespace"},{"line_number":12,"context_line":"--------------------------------------------------------------------"},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"The requirements for inclusion in the `openstack/` code namespace are as"},{"line_number":15,"context_line":"follows:"},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"- The project source code is licensed under the Apache 2.0 License"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_477d32e7","line":14,"in_reply_to":"9aa7fdbe_e208cb2f","updated":"2014-11-18 20:02:45.000000000","message":"Yes, that\u0027s exactly correct, Deva.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"12bfe97e55e495f24c749a0378e44b755b091e95","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  areas"},{"line_number":24,"context_line":"- There should be documentation that clearly describes the function of the"},{"line_number":25,"context_line":"  project, its intended audience, any public APIs it exposes, and how"},{"line_number":26,"context_line":"  contribution to the project is handled"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"The team working on a source code project that desire to host their project"},{"line_number":29,"context_line":"under the `openstack/` code namespace should file an \"application patch\" to the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_b37b657a","line":26,"updated":"2014-10-10 09:55:23.000000000","message":"I think this is devaluating what \"OpenStack\" means. IMHO \"OpenStack\" is (1) a mission and (2) a set of values. This is enforcing none of it. I can get my photo app in and call it openstack/*. This is just crazy.\n\nI think we need a series of community checks, what\u0027s Monty calls \"are you one of us\". Those may not require the TC to approve (could be some sort of community council that the TC would delegate authority to), but someone has to check that you remotely make sense to be called as OpenStack. I\u0027d add:\n\n- The 4 opens (open design in particular)\n- Name checks (calling something openstack/* engages the Foundation, like it or not)\n- Are you even vaguely potentially aligned with the OpenStack mission ?\n\nOpenStack just can\u0027t be github and sourceforge.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},"change_message_id":"b531ccc5846e60373c2ad594a46a57ba3e05e519","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  areas"},{"line_number":24,"context_line":"- There should be documentation that clearly describes the function of the"},{"line_number":25,"context_line":"  project, its intended audience, any public APIs it exposes, and how"},{"line_number":26,"context_line":"  contribution to the project is handled"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"The team working on a source code project that desire to host their project"},{"line_number":29,"context_line":"under the `openstack/` code namespace should file an \"application patch\" to the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9aa7fdbe_34067f21","line":26,"in_reply_to":"9aa7fdbe_00d13dfb","updated":"2014-10-20 15:21:36.000000000","message":"Actually, additional point on the implementation language. If python is table-stakes for OpenStack, shouldn\u0027t it be in the mission? \n\n\"To produce the ubiquitous Python Open Source Cloud Computing platform ...\"","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},"change_message_id":"a79c53aa7715f1d8d01d2b6ee3333ab4f4b92bf3","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  areas"},{"line_number":24,"context_line":"- There should be documentation that clearly describes the function of the"},{"line_number":25,"context_line":"  project, its intended audience, any public APIs it exposes, and how"},{"line_number":26,"context_line":"  contribution to the project is handled"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"The team working on a source code project that desire to host their project"},{"line_number":29,"context_line":"under the `openstack/` code namespace should file an \"application patch\" to the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9aa7fdbe_00d13dfb","line":26,"in_reply_to":"9aa7fdbe_7d09da2b","updated":"2014-10-20 13:30:28.000000000","message":"Perhaps consider taking a \"core values\" approach?\n\nWHAT WE ARE (aka, The OpenStack Mission)\n\"To produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable.\"\n\nHOW WE WORK (aka, The Four Opens)\nOpen Source\nOpen Design\nOpen Development\nOpen Community\n\nPerhaps some discussion the project cores (ability to +2), no BDFL\n\nHOW WE BUILD\nThe original design tenets, I think make sense as well. They could also perhaps use a dusting off.\nhttps://wiki.openstack.org/wiki/BasicDesignTenets\n\nPerhaps some discussion of the review process, the gating process (including integration tests vs. unit tests) and/or API stability. This may also get into the Foundation\u0027s discussion of DevCore in that case?\n\nI\u0027d like to see a differentiation of API and implementation with the important focus on API and compatibility integration tests. I don\u0027t care what the implementation is written in ... best implementation wins. But perhaps that belongs in a different doc?","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"c5bb64e5af69226f9ab2f31768417fb62a67a5fd","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  areas"},{"line_number":24,"context_line":"- There should be documentation that clearly describes the function of the"},{"line_number":25,"context_line":"  project, its intended audience, any public APIs it exposes, and how"},{"line_number":26,"context_line":"  contribution to the project is handled"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"The team working on a source code project that desire to host their project"},{"line_number":29,"context_line":"under the `openstack/` code namespace should file an \"application patch\" to the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9aa7fdbe_7d09da2b","line":26,"in_reply_to":"baa201ad_15510436","updated":"2014-10-20 05:22:18.000000000","message":"I agree with what Thierry has said here regarding the four opens and alignment with the OpenStack mission.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"5e67a883b08fe0263889e2a3ba72f6490aa172ce","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  areas"},{"line_number":24,"context_line":"- There should be documentation that clearly describes the function of the"},{"line_number":25,"context_line":"  project, its intended audience, any public APIs it exposes, and how"},{"line_number":26,"context_line":"  contribution to the project is handled"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"The team working on a source code project that desire to host their project"},{"line_number":29,"context_line":"under the `openstack/` code namespace should file an \"application patch\" to the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_15510436","line":26,"in_reply_to":"baa201ad_81a5f305","updated":"2014-10-15 10:03:03.000000000","message":"On the \"vaguely aligned\" point, I think we can come up with an almost-objective criteria which, coupled with a \"in doubt, accept\" policy should do the trick.\n\nThe \"name checks\" point is more painful. In order to protect its members, the Foundation does trigger name checks currently for anything that enters openstack/*, and forces projects to rename when they detect potential for litigation. These checks come with a cost, which is contained when we are talking about a small-tent approach, but out of control in a big-tent approach. Solutions include (1) dramatically lowering the cost of such checks, (2) adopt a \"pick anything, rename if challenged\" approach or (3) force imaginary names (or name combinations) for all new projects.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"62c41dfa2da021cdb06c8ce33f2ec42604b68211","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  areas"},{"line_number":24,"context_line":"- There should be documentation that clearly describes the function of the"},{"line_number":25,"context_line":"  project, its intended audience, any public APIs it exposes, and how"},{"line_number":26,"context_line":"  contribution to the project is handled"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"The team working on a source code project that desire to host their project"},{"line_number":29,"context_line":"under the `openstack/` code namespace should file an \"application patch\" to the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_bd45c116","line":26,"in_reply_to":"baa201ad_b37b657a","updated":"2014-10-13 15:10:36.000000000","message":"All good thoughts, Thierry. My proposal was designed to get the proverbial wheels turning, and this is exactly the kind of feedback I was hoping for, thank you!\n\nI definitely agree on including the 4 opens as a requirement, and I will add that in the next draft patch.\n\nOn the \"are you even vaguely aligned\" point, I specifically want to get *away* from the current situation where the TC is forever getting into these \"big vs small tent\" or \"is XYZ *really* \u0027cloudy\u0027?\" existential discussions. I think our requirements for entrance into the OpenStack tent need to be as objective as possible. And, requirements that test whether a project is aligned with the OpenStack mission tend to encourage the subjective opinions that have frankly haunted the TC for years now.\n\nI\u0027m not against the idea behind your point; however I would encourage us to make any such requirement of aligned mission as objective as possible.\n\nFor the Name checks point, how do you recommend I word this? Is this a technical requirement for getting into the openstack/ namespace currently? Should the board\u0027s legal counsel be called into investigate name-marks for every proposed source code project that wants to live in the openstack/ namespace? Mainly here, I\u0027m looking for specifics on what the requirement should list.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"aac567721d4e9834784830544defcbcee7aa8a47","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  areas"},{"line_number":24,"context_line":"- There should be documentation that clearly describes the function of the"},{"line_number":25,"context_line":"  project, its intended audience, any public APIs it exposes, and how"},{"line_number":26,"context_line":"  contribution to the project is handled"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"The team working on a source code project that desire to host their project"},{"line_number":29,"context_line":"under the `openstack/` code namespace should file an \"application patch\" to the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_81a5f305","line":26,"in_reply_to":"baa201ad_bd45c116","updated":"2014-10-13 18:26:41.000000000","message":"Of the projects that have thus far applied for incubation, I don\u0027t believe any deserved to be rejected on grounds of insufficient cloudiness/alignment. (And to be fair to the TC, I can\u0027t think of any that were rejected primarily on those grounds... Rally comes closest I guess.)\n\nHowever, if we throw open the gates then we will get different kinds of projects wanting to join. For example we know, because they have said as much, that the Eucalyptus folks will try to add a Java-based implementation of the OpenStack APIs. (Not picking on them; that\u0027s just the only public statement of intent I\u0027ve seen.)\n\nWhether we accept or reject that, I believe we need to do so *explicitly* and up-front. Both so we\u0027re clear on what we\u0027re inevitably getting ourselves into and in fairness to the projects that might be interested in joining so there are no last-minute surprises.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"12bfe97e55e495f24c749a0378e44b755b091e95","unresolved":false,"context_lines":[{"line_number":30,"context_line":"`openstack-infra/project-config` repository that adds their project to the"},{"line_number":31,"context_line":"`openstack/` code namespace. The `project-config-core` Gerrit team is"},{"line_number":32,"context_line":"responsible for checking that each of the above requirements are met by the"},{"line_number":33,"context_line":"applying project."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Note that some members of the Technical Committee may be members of the"},{"line_number":36,"context_line":"`project-config-core` team, and members of the TC are expected to vote on new"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_98676025","line":33,"updated":"2014-10-10 09:55:23.000000000","message":"You seem to remove the repo grouping that \"programs\" allowed. A project team works on several code repositories (whatever makes the most technical sense), while sharing the same \"team\". You don\u0027t want liaisons for each repo, you want liaisons for each team.\n\nYou can implement this in two ways: either create a team/project/program concept and list the repositories under that, or have some inheritance process where you can declare a repo as inheriting team from another repo (openstack/heat-templates inherits team from openstack/heat)","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},"change_message_id":"a79c53aa7715f1d8d01d2b6ee3333ab4f4b92bf3","unresolved":false,"context_lines":[{"line_number":30,"context_line":"`openstack-infra/project-config` repository that adds their project to the"},{"line_number":31,"context_line":"`openstack/` code namespace. The `project-config-core` Gerrit team is"},{"line_number":32,"context_line":"responsible for checking that each of the above requirements are met by the"},{"line_number":33,"context_line":"applying project."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Note that some members of the Technical Committee may be members of the"},{"line_number":36,"context_line":"`project-config-core` team, and members of the TC are expected to vote on new"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9aa7fdbe_c0357547","line":33,"in_reply_to":"baa201ad_98660bec","updated":"2014-10-20 13:30:28.000000000","message":"This is actually an interesting point. To break something out into a separate repo implies a stable contract (an api of some fashion). So there should be no reason why we couldn\u0027t have separate leads for each api / repo.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"62c41dfa2da021cdb06c8ce33f2ec42604b68211","unresolved":false,"context_lines":[{"line_number":30,"context_line":"`openstack-infra/project-config` repository that adds their project to the"},{"line_number":31,"context_line":"`openstack/` code namespace. The `project-config-core` Gerrit team is"},{"line_number":32,"context_line":"responsible for checking that each of the above requirements are met by the"},{"line_number":33,"context_line":"applying project."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Note that some members of the Technical Committee may be members of the"},{"line_number":36,"context_line":"`project-config-core` team, and members of the TC are expected to vote on new"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_bde141fe","line":33,"in_reply_to":"baa201ad_98676025","updated":"2014-10-13 15:10:36.000000000","message":"\"You don\u0027t want liaisons for each repo, you want liaisons for each team.\"\n\nActually, that\u0027s not really true. Oslo has separate liaisons for each repo. For the client libraries, do we have the same liaison as the server project? If we do, should we have the same liaison? I would say no, as the audience, release cadence, and documentation contact points are entirely different between server and client projects.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"5e67a883b08fe0263889e2a3ba72f6490aa172ce","unresolved":false,"context_lines":[{"line_number":30,"context_line":"`openstack-infra/project-config` repository that adds their project to the"},{"line_number":31,"context_line":"`openstack/` code namespace. The `project-config-core` Gerrit team is"},{"line_number":32,"context_line":"responsible for checking that each of the above requirements are met by the"},{"line_number":33,"context_line":"applying project."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Note that some members of the Technical Committee may be members of the"},{"line_number":36,"context_line":"`project-config-core` team, and members of the TC are expected to vote on new"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_98660bec","line":33,"in_reply_to":"baa201ad_bde141fe","updated":"2014-10-15 10:03:03.000000000","message":"You mean you would run PTL elections or request liaisons for every single repository ? openstack/heat and openstack/heat-templates would not share the same team ? Under the disguise of removing an abstraction layer, that would actually add a lot of complexity.\n\nAt the very least I\u0027d pick a structure that lets \"secondary repositories\" inherit teams from existing ones. The client/server case is really a corner case. Look at infrastructure and their 46 repositories. Would you rather list liaisons for 46 of them, or just say that by default they all inherit the team from openstack-infra/system-config ?","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"12bfe97e55e495f24c749a0378e44b755b091e95","unresolved":false,"context_lines":[{"line_number":40,"context_line":"-----------------------"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Project Technical Leads (\"PTLs\") traditionally manage day-to-day operations,"},{"line_number":43,"context_line":"drive the program goals and resolve technical disputes within their program."},{"line_number":44,"context_line":"Each program community should be self-managing by the contributors, and all"},{"line_number":45,"context_line":"disputes should be resolved through active debate and discussion by the"},{"line_number":46,"context_line":"community itself.  However if a given debate cannot be clearly resolved, the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_78039c76","line":43,"updated":"2014-10-10 09:55:23.000000000","message":"s/program/project/gc","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"62c41dfa2da021cdb06c8ce33f2ec42604b68211","unresolved":false,"context_lines":[{"line_number":40,"context_line":"-----------------------"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Project Technical Leads (\"PTLs\") traditionally manage day-to-day operations,"},{"line_number":43,"context_line":"drive the program goals and resolve technical disputes within their program."},{"line_number":44,"context_line":"Each program community should be self-managing by the contributors, and all"},{"line_number":45,"context_line":"disputes should be resolved through active debate and discussion by the"},{"line_number":46,"context_line":"community itself.  However if a given debate cannot be clearly resolved, the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_fdebc9d9","line":43,"in_reply_to":"baa201ad_78039c76","updated":"2014-10-13 15:10:36.000000000","message":"thx, copy/paste error. will fix.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"42f583be59f4b075c2758530a0b8ff4ed8e1072d","unresolved":false,"context_lines":[{"line_number":44,"context_line":"Each program community should be self-managing by the contributors, and all"},{"line_number":45,"context_line":"disputes should be resolved through active debate and discussion by the"},{"line_number":46,"context_line":"community itself.  However if a given debate cannot be clearly resolved, the"},{"line_number":47,"context_line":"PTL can decide the outcome."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Projects are free to elect a Project Technical Lead but are also free to"},{"line_number":50,"context_line":"self-organize without a single PTL. Projects \u0027\u0027must\u0027\u0027 have a set of named"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9aa7fdbe_2cac61a0","line":47,"updated":"2014-10-21 06:41:17.000000000","message":"@Sandy, this is indeed tricky, but I disagree on this. An ever-widening attempt to please all interested parties dilutes a project, often, in my opinion, to the detriment of users. While I think OpenStack as a whole must embrace the existence of divergent architectural views, I think each project should be allowed to be as narrowly-scoped or as broadly-scoped as that project\u0027s team sees fit.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},"change_message_id":"a79c53aa7715f1d8d01d2b6ee3333ab4f4b92bf3","unresolved":false,"context_lines":[{"line_number":44,"context_line":"Each program community should be self-managing by the contributors, and all"},{"line_number":45,"context_line":"disputes should be resolved through active debate and discussion by the"},{"line_number":46,"context_line":"community itself.  However if a given debate cannot be clearly resolved, the"},{"line_number":47,"context_line":"PTL can decide the outcome."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Projects are free to elect a Project Technical Lead but are also free to"},{"line_number":50,"context_line":"self-organize without a single PTL. Projects \u0027\u0027must\u0027\u0027 have a set of named"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9aa7fdbe_60e209a1","line":47,"updated":"2014-10-20 13:30:28.000000000","message":"This is tricky if if the PTL is a meant to be viewed as a management lead and not an architectural lead. I would defer back to the design tenets and say \"conflicting architectural directions must allow for all paths to be supported and optional.\"","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},"change_message_id":"ce5660857403160217d90236c50b1435c2f95b6e","unresolved":false,"context_lines":[{"line_number":44,"context_line":"Each program community should be self-managing by the contributors, and all"},{"line_number":45,"context_line":"disputes should be resolved through active debate and discussion by the"},{"line_number":46,"context_line":"community itself.  However if a given debate cannot be clearly resolved, the"},{"line_number":47,"context_line":"PTL can decide the outcome."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Projects are free to elect a Project Technical Lead but are also free to"},{"line_number":50,"context_line":"self-organize without a single PTL. Projects \u0027\u0027must\u0027\u0027 have a set of named"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9aa7fdbe_3aed6ac4","line":47,"in_reply_to":"9aa7fdbe_2cac61a0","updated":"2014-10-21 11:09:17.000000000","message":"Yep, totally agree. I\u0027m specifically talking about the use case mentioned: \"a given debate cannot be clearly resolved.\"","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"448ee1dcb17b67fb7f0d416f00c278ddde9f9d53","unresolved":false,"context_lines":[{"line_number":46,"context_line":"community itself.  However if a given debate cannot be clearly resolved, the"},{"line_number":47,"context_line":"PTL can decide the outcome."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Projects are free to elect a Project Technical Lead but are also free to"},{"line_number":50,"context_line":"self-organize without a single PTL. Projects \u0027\u0027must\u0027\u0027 have a set of named"},{"line_number":51,"context_line":"liaisons that are responsible for cross-project coordination, however it is up"},{"line_number":52,"context_line":"to the project\u0027s contributor community to decide how it wishes to organize its"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_bc3d062f","line":49,"updated":"2014-10-09 20:13:07.000000000","message":"Maybe clarify this to say that if they choose to have a PTL, he or she must be elected.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"62c41dfa2da021cdb06c8ce33f2ec42604b68211","unresolved":false,"context_lines":[{"line_number":46,"context_line":"community itself.  However if a given debate cannot be clearly resolved, the"},{"line_number":47,"context_line":"PTL can decide the outcome."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Projects are free to elect a Project Technical Lead but are also free to"},{"line_number":50,"context_line":"self-organize without a single PTL. Projects \u0027\u0027must\u0027\u0027 have a set of named"},{"line_number":51,"context_line":"liaisons that are responsible for cross-project coordination, however it is up"},{"line_number":52,"context_line":"to the project\u0027s contributor community to decide how it wishes to organize its"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_7db7d9f5","line":49,"in_reply_to":"baa201ad_bc3d062f","updated":"2014-10-13 15:10:36.000000000","message":"Sure, that\u0027s a good clarification. will do.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"12bfe97e55e495f24c749a0378e44b755b091e95","unresolved":false,"context_lines":[{"line_number":50,"context_line":"self-organize without a single PTL. Projects \u0027\u0027must\u0027\u0027 have a set of named"},{"line_number":51,"context_line":"liaisons that are responsible for cross-project coordination, however it is up"},{"line_number":52,"context_line":"to the project\u0027s contributor community to decide how it wishes to organize its"},{"line_number":53,"context_line":"leadership positions."}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_982f60f6","line":53,"updated":"2014-10-10 09:55:23.000000000","message":"maybe \"If there is no consensus on the governance model, you should adopt the default PTL system\" ? Should avoid deadlocks","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"62c41dfa2da021cdb06c8ce33f2ec42604b68211","unresolved":false,"context_lines":[{"line_number":50,"context_line":"self-organize without a single PTL. Projects \u0027\u0027must\u0027\u0027 have a set of named"},{"line_number":51,"context_line":"liaisons that are responsible for cross-project coordination, however it is up"},{"line_number":52,"context_line":"to the project\u0027s contributor community to decide how it wishes to organize its"},{"line_number":53,"context_line":"leadership positions."}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_ddc7e562","line":53,"in_reply_to":"baa201ad_982f60f6","updated":"2014-10-13 15:10:36.000000000","message":"sure, good point.","commit_id":"b9c4c2dec2a84573fdde21630cdd1cc5bb4e6014"}]}