Last week at the Forum in Berlin we met to discuss potential community-wide goals for the Train development cycle. We had a good list of proposals [1], although some of them do not meet the criteria for the goals program as currently defined [2]. We came up with a few suggestions that do fit the criteria, listed here in the order we discussed them: * Ensure that each project has contributor on-boarding documentation in a discoverable place in their documentation tree, and link to that from the contributor portal at openstack.org/community. (proposed by TheJulia) This should be relatively light-weight for teams to do, and will uncover some good opportunities for documentation reuse. * Deletion of project resources. (proposed by tobberydberg and adriant) This has been a long-standing request from operators, as discussed in forum session earlier in the week [3]. The propose next-steps are to establish a way for the existing os-purge program to accept plugins so that project teams can declare the relationships between resources that need to be deleted, to make orchestration easier. See the etherpad from the session for more details. * Finish moving legacy python-*client CLIs to python-openstackclient (proposed by mriedem on behalf of Tim Bell) This is another initiative that has been going on for a few years, and completing it would give users more clarity as well as providing a more consistent user interface. The general idea was to finish implementing all of the commands within OSC using the existing client libs, then update the SDK to support those features so we can drop the client libs from OSC as well, giving us 1 SDK and 1 CLI. That’s a multi-step process, so I think for the first phase targeting completing all of the commands within OSC using the various client libraries would be enough for 1 cycle. * Ensure all projects pass request-id when calling one another. (proposed by Pavlo Shchelokovskyy) Passing request-id allows us to chain requests together and trace them for debugging and profiling. We started this a while back and some projects are doing it but not all. * Rolling out oslo health-check middleware so each project provides that API. (proposed by mugsie) This came up at the PTG in Denver earlier this year [4]. There will be some up-front work to make the health check API able to support real backend checks for the database, message bus, etc. Then we would need to add the middleware to all services. In all of these cases, we have a bit more up-front work to do to be ready to accept the idea as a goal. There should be time during the remainder of the Stein cycle to make enough progress on that work to know if we could accept it as a goal. Our next steps are for the people proposing these goals to ensure that up-front work is done and be prepared to write up the goal document for review. If the proposes aren’t able/willing to act as goal champions, we need to identify someone else to fill that role. I propose we set a target of early March for having the formal goal proposals ready for review. That will give us time to approve them well before the next Summit/PTG, so that teams can use time during the PTG for planning their implementation. [1] https://etherpad.openstack.org/p/BER-t-series-goals [2] https://governance.openstack.org/tc/goals/index.html [3] https://etherpad.openstack.org/p/BER-deletion-of-project-resources [4] 1. https://etherpad.openstack.org/p/api-sig-stein-ptg (line 20) -- Doug