<div dir="ltr"><br><br>2018-04-23 22:43 GMT+08:00 Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>>:<br>><br>> Excerpts from Rico Lin's message of 2018-04-22 16:50:51 +0800:<br>> > Thanks, Doug, for raising this campaign question<br>> ><br>> ><br>> > Here are my answers:<br>> ><br>> ><br>> > ***How you would evaluate a project's application in general<br>> ><br>> > First I would work through the requirements ([1]) to evaluate projects.<br>> > Since most of the requirements are specific enough. And here's more<br>> > important part, to leave evaluate logs or comments for projects which we<br>> > considered but didn't reach some requirements. It's very important to guide<br>> > projects to cross over requirements (and remember, a `-1` only means we<br>> > trying to help).<br>> ><br>> > Then, I work on questions, like:<br>> ><br>> > `How many user are interesting to/needs the functionality that service<br>> > provided?`<br>> ><br>> > `How active is this project and how's the diversity of contributors?`<br>><br>> Our current policy is to allow projects with contributors from a small<br>> number of affiliations (even a single employer), under the theory that<br>> bringing a team into the community officially will help them grow by<br>> showing them the benefits of being more diverse and by making it easier<br>> for other community members who have employer restrictions on their open<br>> source work to justify contributing.<br>><br>> Would you change that policy in any way?<div>I'm fine with the number of developers involved in the project. we should encourage</div><div>people working on any crazy ideas. But the point is `is that developer active?</div><div>and will he/she helps others to join that projects or just waiting for others?`.</div><div>If we can try to put such requirement in policy will be better IMO. Otherwise, </div><div>we can keep the policy but the diversity of developers might help to reduce chances of that risk. </div><div>><br>> ><br>> > `Is this project required cross communities/projects cooperation? If yes,<br>> > how's the development workflows  are working between communities/projects?`<br>> ><br>> > And last but is one of the most important questions,<br>> ><br>> > `Is this service aligns with the OpenStack Mission`? (and let's jump to<br>> > next question to answer this part)<br>> ><br>> ><br>> ><br>> > **What sorts of things do you consider when deciding whether a project<br>> > "aligns with the OpenStack Mission," for example?*<br>> ><br>> > I would consider things like:<br>> ><br>> > `Is the project's functionality complete the OpenStack infrastructure map?`<br>> ><br>> > Asking from user requirement and functionality point of view, `how's the<br>> > project(services) will make OpenStack better infrastructure for<br>> > user/operators?` and `how's this functionality provide a better life for<br>> > OpenStack developers?`<br>> ><br>> > `Is the project provides better integration point between communities`<br>> ><br>> > To build a better infrastructure, IMO it's also important to ask if a<br>> > project (service) really help on integration with other communities like<br>> > Kubernetes, OPNFV, CEPH, etc. I think to keep us as an active<br>> > infrastructure to solutions is part of our mission too.<br>> ><br>> > `Is it providing functionality which we can integrate with current projects<br>> > or SIG instead?`<br>> ><br>> > In short, we should be gathering our development energy, to really achieve<br>> > the jobs which is exactly why we spend times on trying to find official<br>> > projects and said this is part of our mission to work on. So when new<br>> > projects jump out, it's really important to discuss cross-project `is it<br>> > suitable for projects integrated and join force on specific functionality?`<br>> > (to do this while evaluating a project instead of when it's creating might<br>> > not be the best time to said `please integrate or join forces with other<br>> > teams together`(not even with a smiling face), but it's never too late for<br>> > a non-official/incubating project to consider about this). I really don't<br>> > like to to see any project get higher chances to die just because<br>> > developers chance their developing focus. It's happening when projects are<br>> > all willing to do the functionality, but no communication between(some<br>> > cases, not even now other projects exists), and new/old projects dead, then<br>> > TC needs to spend the time to pick those projects out. So IMO, it's worth<br>> > to spend times to investigate on whether projects can be joined. Or ideally<br>> > to put a resolution said, it's project's obligation to help on this, and<br>> > help other join force to be part of the team.<br>><br>> Please see my other question about projects with overlapping feature<br>> sets [1].</div><div>Done:)<br>><br>> Doug<br>><br>> [1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html">http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html</a><br>><br>> ><br>> > `Can projects provide cross-project gating?`<br>> ><br>> > Do think if it's possible, we should consider this when asking if a service<br>> > aligns with our mission because not breaking rest of infrastructure is part<br>> > of the definition of `to build`. And providing cross-project gate jobs<br>> > seems like a way to go. To stable the integration between projects and<br>> > prevent released a failed feature when other services trying to work on new<br>> > ways and provide no guideline, ML, or solution, just only leave words like<br>> > `this is not part of our function to fix`.<br>> ><br>> ><br>> ><br>> > And finally,<br>> ><br>> > If we can answer all above questions, try to put in with the more accurate<br>> > number (like from user survey), and provides communications it needs, will<br>> > definitely help in finding next official projects.<br>> ><br>> > Also, when the evaluation is done, we should also evaluate the how's these<br>> > evaluation processes, how's guideline working for us? and which questions<br>> > above doesn't make any sense?.<br>> ><br>> ><br>> > [1]<br>> > <a href="https://governance.openstack.org/tc/reference/new-projects-requirements.html">https://governance.openstack.org/tc/reference/new-projects-requirements.html</a><br>> ><br>> ><br>> > May The Force of OpenStack Be With You,<br>> ><br>> > *Rico Lin*irc: ricolin<br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br clear="all"><div><br></div>-- <br><div class="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"><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"><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>irc: ricolin</td></tr><tr><td colspan="3" align="left" valign="center" style="height:10px;border-bottom:1px dashed 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>