Well hello again! As always, inline below: On 21/02/2019 11:13, Chris Dent wrote:
This is another set of questions for TC candidates, to look at a different side of things from my first one [1] and somewhat related to the one Doug has asked [2].
As Doug mentions, a continuing role of the TC is to evaluate applicants to be official projects. These questions are about that.
There are 63 teams in the official list of projects. How do you feel about this size? Too big, too small, just right? Why?
I think it's safe for me to say that isn't a single person in our entire community that could honestly say they know what all those 63 projects are and how they function. We are all specialists in our own right and that's how our community works together. I do not believe it is my place to determine via a standalone number if our project list is too big, too small, or just right. I could very easily say that we only require "the main 5 projects" for OpenStack to work, but part of the beauty of OpenStack as an open source product is we allow freedom of development (within technical guidelines, as discussed) and that is one of the things that draws developments and their projects to integrate and grow with OpenStack. That also being said, there has been duplication of efforts in certain areas. Projects that are eerily similar, yet not working together. I think these are areas that we could potentially be reviewing, in the sense of encouraging teams to collaborate more.
If you had to make a single declaration about growth in the number of projects would you prefer to see (and why, of course):
* More projects as required by demand. * Slower or no growth to focus on what we've got. * Trim the number of projects to "get back to our roots". * Something else. My answer is: Something else (ha, what a surprise).
I think all those options are applicable. If there is room and movement for growth, we should be encouraging of that. If there is a slow down, we should not be pushing the community to grow when it clearly is stablising. I believe we should always be looking at ways to trim - if you do not cut back, there is no room for improvement. If a stable, yet unattended project is left to expire on its own does not open up for new change and new ownership. We've seen this happen before.
How has the relatively recent emergence of the open infrastructure projects that are at the same "level" in the Foundation as OpenStack changed your thoughts on the above questions?
The OIP has mostly changed the way I think about your questions in the sense that it isn't just "us" anymore. And we need to be looking more towards future development. We needn't have such a focus on OpenStack projects alone but where the revised community is going and how we're going to get there. As I said in my email to Doug: Don't fix what's broken, let's move forward and focus on that.
Do you think the number of projects has any impact (positive or negative) on our overall ability to get things done?
I'd be lying if I didn't say: Sometimes. I think ensuring you are considering the needs and wants of 63 projects is an enormous task. And often that means what could be a cut and dry is not because you need to ensure you're considering every angle. But, this isn't necessarily a bad thing.
Recognizing that there are many types of contributors, not just developers, this question is about developers: Throughout history different members of the community have sometimes identified as an "OpenStack developer", sometimes as a project developer (e.g., "Nova developer"). Should we encourage contributors to think of themselves as primarily OpenStack developers? If so, how do we do that? If not, why not?
To reiterate my first answer to your question: There is not one person who understands the intimidate details of every OpenStack project. While I encourage anyone to identify as an OpenStack developer, I can see why someone would prefer to refer to themselves as a Nova developer on the OpenStack product. Being an OpenStack developer can often imply that you know everything about the entire ecosystem - which I believe many to have very in-depth knowledge on several projects, but not the entire product. That being said, there are those that are core contributors on several projects and identifying as an OpenStack developer is an easier course than saying they are core developers on Keystone, Glance, Cinder and the Potato project (so be it). While you address this question to developers and recognise that there are many different types of contributors, I think documentation sits in a weird loop hole here. We are often considered developers because we follow developmental workflows, and integrate with the projects directly. Some of us are more technical than others and contribute to both the code base and to the physical documentation. Risking a straw man here: How would you define the technical writers that work for OpenStack? We too are often considered "OpenStack" writers and experts, yet as I say, we are not experts on every project.
Thanks.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002914.... [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002923....
Looking forward to your response to my question :)