<div dir="ltr"><b style="font-weight:normal" id="gmail-docs-internal-guid-10a41309-f36d-afd0-4732-599c3a8c54cd"><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Thanks, Doug for bringing out this campaign question</span></p><br><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">I think we have a start now with providing a decent map to show services in OpenStack and fill in with projects. What we should have and will be nice is to ask projects to search through the map (with a brief introduction of services) when they're registering. To prevent overlapping from the very beginning seems to be the most ideal, which might also mean it's actually our responsibility to search through what exactly a project aims to and what kind of feature it will provide when we allow people to register a project. We can also discuss about to let projects know that we encourage new ideas but we not encourage provides overlapping features just because you think the service is bad and you don't like to fix it (IMO to encourage people to point out problems and even try to fix it is very important when talking about continuing efforts). And to give credits instead of warnings might work better.</span></p><br><br><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">* How (and whether) the community would be able to replace the implementation</span></p><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">of any given component with a new set of technologies by "starting</span></p><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">from scratch".</span></p><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">With try to make such action as a long-term community goal, might be possible to said we're able to do it (if this new technology does matters, like containerize), and it might be even better than wait for people to pick up the job and keep asking him `are we there yet?`. We have to be really careful to prevent changing the behavior of services or cause a huge burden to developers.</span></p><br><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">* Where do you draw the line at "gratuitous"?</span></p><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">When a project is about more than 80% chances to dead or no maintainer, and pure overlapping effort.</span></p><br><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">* What benefits and drawbacks do you see in supporting multiple tools</span></p><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">with similar features?</span></p><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">It's good and allow people from multiple tools to help construct the bridge to us together. What I concern is we should try to decide a pattern and make it a success instead of letting parallel jobs works on similar features. So we can have a preview version of all other paths. And if we can make sure our success path first, we can even look back and provide features plus bug fixes to other tools. That brings a question back, `what're users using the most?`</span></p><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">* How would our community be different, in positive and negative ways,</span></p><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">if we were more strict about avoiding such overlap?</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">To allow concentrate our development energy on features, also to prevent lack of diversity/ideas/activity for those projects we promise to provide guideline when we allow them to stay under TC's governance. What we should also try to prevent it when it's overlap but exists project didn't provide fair communication or close their mind to new features/fixes. Which we should strong/change part of our TC resolutions and prevent this because that might just lead to a negative way that people quitting on providing new innovation.</span></p></b><div><br></div><div><br></div><br class="gmail-Apple-interchange-newline"><table border="0" cellpadding="0" cellspacing="0" style="font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;color:rgb(0,0,0);font-size:medium;font-family:verdana"><tbody><tr><td colspan="3" align="left" valign="center" style="font-family:arial,sans-serif;margin:0px"><span style="font-size:13px;font-family:verdana">May The Force of Open<font color="#ff0000">Stack</font> Be With You,</span> <br><b><i><font face="georgia, serif" size="4">Rico Lin<br></font></i></b><span class="gmail-gr_ gmail-gr_529 gmail-gr-alert gmail-gr_spell gmail-gr_inline_cards gmail-gr_run_anim gmail-ContextualSpelling gmail-ins-del gmail-multiReplace" id="gmail-529" style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat;color:inherit;font-size:inherit">irc</span>:<span> </span><span class="gmail-gr_ gmail-gr_530 gmail-gr-alert gmail-gr_spell gmail-gr_inline_cards gmail-gr_run_anim gmail-ContextualSpelling gmail-ins-del gmail-multiReplace" id="gmail-530" style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat;color:inherit;font-size:inherit">ricolin</span></td></tr></tbody></table><br><br><div class="gmail_extra"><br><div class="gmail_quote">2018-04-23 21:50 GMT+08:00 Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[This is meant to be one of (I hope) several conversation-provoking<br>
questions directed at prospective TC members to help the community<br>
understand their positions before considering how to vote in the<br>
ongoing election.]<br>
<br>
In the course of evaluating new projects that have asked to join<br>
as official members of the OpenStack community, we often discuss<br>
whether the feature set of the project overlaps too much with other<br>
existing projects. This came up within the last year during Glare's<br>
application, and more recently as part of the Adjutant application.<br>
<br>
Our current policy regarding Open Development is that a project<br>
should cooperate with existing projects "rather than gratuitously<br>
competing or reinventing the wheel." [1] The flexibility provided<br>
by the use of the term "gratuitously" has allowed us to support<br>
multiple solutions in the deployment and telemetry problem spaces.<br>
At the same time it has left us with questions about how (and<br>
whether) the community would be able to replace the implementation<br>
of any given component with a new set of technologies by "starting<br>
from scratch".<br>
<br>
Where do you draw the line at "gratuitous"?<br>
<br>
What benefits and drawbacks do you see in supporting multiple tools<br>
with similar features?<br>
<br>
How would our community be different, in positive and negative ways,<br>
if we were more strict about avoiding such overlap?<br>
<br>
Doug<br>
<br>
[1] <a href="https://governance.openstack.org/tc/reference/new-projects-requirements.html" rel="noreferrer" target="_blank">https://governance.openstack.<wbr>org/tc/reference/new-projects-<wbr>requirements.html</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="background-image:none!important"><div style="font-size:small"><div><table border="0" cellpadding="0" cellspacing="0" style="color:rgb(0,0,0);font-size:medium;font-family:verdana"><tbody><tr><td colspan="3" align="left" valign="center" style="height:10px;border-bottom-width:1px;border-bottom-style:dashed;border-bottom-color:rgb(221,221,221)"></td></tr><tr><td colspan="3"></td></tr></tbody></table><br></div></div></div><font size="2" face="tahoma, sans-serif" color="#999999"></font></div></div></div></div></div></div></div></div></div></div>
</div></div>