<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Feb 21, 2019 at 6:14 AM Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org">cdent+os@anticdent.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
This is another set of questions for TC candidates, to look at a<br>
different side of things from my first one [1] and somewhat related<br>
to the one Doug has asked [2].<br>
<br>
As Doug mentions, a continuing role of the TC is to evaluate<br>
applicants to be official projects. These questions are about that.<br>
<br>
There are 63 teams in the official list of projects. How do you feel<br>
about this size? Too big, too small, just right? Why?<br>
<br>
If you had to make a single declaration about growth in the number<br>
of projects would you prefer to see (and why, of course):<br>
<br>
* More projects as required by demand.<br>
* Slower or no growth to focus on what we've got.<br>
* Trim the number of projects to "get back to our roots".<br>
* Something else.<br>
<br>
How has the relatively recent emergence of the open infrastructure<br>
projects that are at the same "level" in the Foundation as OpenStack<br>
changed your thoughts on the above questions?<br>
<br>
Do you think the number of projects has any impact (positive or<br>
negative) on our overall ability to get things done?<br></blockquote><div><br></div><div>I haven't formed a strong opinion on the above, but I'll answer this.</div><div><br></div><div>I don't think the number of projects has made a significant impact on our</div><div>ability to get things done overall. If something is important to a certain</div><div>amount of users or operators, I believe it will somehow get done eventually</div><div>(with the caveat that the number of people it is important to scales with the</div><div>effort required to get it done).</div><div><br></div><div>But I do think it makes a negative impact on the ability to keep things</div><div>consistent. The projects with fewer contributor-hours, so to speak, will</div><div>have a hard time finding sufficient time to keep up with the large number</div><div>of things we attempt to make consistent between projects. Between python</div><div>versions, the PTI, docs structure, rolling upgrades, stable policy, API</div><div>versioning, API "feel", client consistency, etc.etc.etc., there's a lot to</div><div>keep up with that seems to change fairly frequently.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Recognizing that there are many types of contributors, not just<br>
developers, this question is about developers: Throughout history<br>
different members of the community have sometimes identified as an<br>
"OpenStack developer", sometimes as a project developer (e.g., "Nova<br>
developer"). Should we encourage contributors to think of themselves<br>
as primarily OpenStack developers? If so, how do we do that? If not,<br>
why not?<br></blockquote><div><br></div><div>Yes. Or maybe just anything other than "$project developers". Ideally I</div><div>like to think that we would organize ourselves more around classes of features</div><div>or layers of the stack. I'd like to see more "compute node developers",</div><div>"networking developers", "REST API developers", "quota developers", etc. I</div><div>think this would allow us to get important things done consistently across</div><div>a wider number of projects, eventually making OpenStack a more coherent thing.</div><div><br></div><div>That said, our culture is so ingrained as-is (both here and inside our</div><div>supporting employers), that I'm not sure how to make this change. I'd love</div><div>to talk with others and figure that out.</div><div><br></div><div>// jim<br></div></div></div></div></div></div>