>> Reliability is the key for them. But for the services and
>> applications that are built on top of this base? I'd like to see
>> allowing them a much more open approach: let them develop in whatever
>> language they like, release when they feel the timing is right, and
>> define their own CI testing. In other words, if you want to develop
>> in a language other than Python, go for it! If you want to use a
>> particular NoSQL database, sure thing! However, the price of that
>> freedom is that the burden will be on the project to ensure that it
>> is adequately tested, instead of laying that responsibility on our
>> infra team.
> This is *precisely* what the Big Tent was all about: opening up the "what is 
> an OpenStack project" idea to more newcomers and competing implementations 
> with the condition that the shared cross-project teams like docs and infra 
> would be enablers and not doers. Instead of creating infrastructure for all 
> the new project teams, the infra team would transition to providing guidance 
> for how the project teams should set up gate jobs for themselves. Instead of 
> writing documentation for the project teams, the docs team would instead 
> provide guidance to new teams on how to write docs that integrate effectively 
> with the existing docs tooling.

I think you raised a very important point by putting emphasis on enablement. In 
my view the fact that we experienced the advantages and disadvantages of being 
more centralized in these areas is an important and useful experience. In my 
view it is crucial to remain a continuously evolving community where we are not 
afraid of making changes even if sometimes they seem to happen slowly.

Being somewhat involved in the documentation team’s activities I’m happy to say 
that the team took many steps towards and is still working on [1] the direction 
you mentioned by moving (back) content to the project repositories and by this 
making it easier for the teams to update and maintain those parts, while still 
having the guidance of the docs team both for wording and tooling.


[1] https://review.openstack.org/#/c/439122/ 
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to