Open Stack

Thanks, Doug, for raising this campaign question


Here are my answers:


***How you would evaluate a project's application in general

First I would work through the requirements ([1]) to evaluate projects.
Since most of the requirements are specific enough. And here's more
important part, to leave evaluate logs or comments for projects which we
considered but didn't reach some requirements. It's very important to guide
projects to cross over requirements (and remember, a `-1` only means we
trying to help).

Then, I work on questions, like:

`How many user are interesting to/needs the functionality that service
provided?`

`How active is this project and how's the diversity of contributors?`

`Is this project required cross communities/projects cooperation? If yes,
how's the development workflows  are working between communities/projects?`

And last but is one of the most important questions,

`Is this service aligns with the OpenStack Mission`? (and let's jump to
next question to answer this part)



**What sorts of things do you consider when deciding whether a project
"aligns with the OpenStack Mission," for example?*

I would consider things like:

`Is the project's functionality complete the OpenStack infrastructure map?`

Asking from user requirement and functionality point of view, `how's the
project(services) will make OpenStack better infrastructure for
user/operators?` and `how's this functionality provide a better life for
OpenStack developers?`

`Is the project provides better integration point between communities`

To build a better infrastructure, IMO it's also important to ask if a
project (service) really help on integration with other communities like
Kubernetes, OPNFV, CEPH, etc. I think to keep us as an active
infrastructure to solutions is part of our mission too.

`Is it providing functionality which we can integrate with current projects
or SIG instead?`

In short, we should be gathering our development energy, to really achieve
the jobs which is exactly why we spend times on trying to find official
projects and said this is part of our mission to work on. So when new
projects jump out, it's really important to discuss cross-project `is it
suitable for projects integrated and join force on specific functionality?`
(to do this while evaluating a project instead of when it's creating might
not be the best time to said `please integrate or join forces with other
teams together`(not even with a smiling face), but it's never too late for
a non-official/incubating project to consider about this). I really don't
like to to see any project get higher chances to die just because
developers chance their developing focus. It's happening when projects are
all willing to do the functionality, but no communication between(some
cases, not even now other projects exists), and new/old projects dead, then
TC needs to spend the time to pick those projects out. So IMO, it's worth
to spend times to investigate on whether projects can be joined. Or ideally
to put a resolution said, it's project's obligation to help on this, and
help other join force to be part of the team.

`Can projects provide cross-project gating?`

Do think if it's possible, we should consider this when asking if a service
aligns with our mission because not breaking rest of infrastructure is part
of the definition of `to build`. And providing cross-project gate jobs
seems like a way to go. To stable the integration between projects and
prevent released a failed feature when other services trying to work on new
ways and provide no guideline, ML, or solution, just only leave words like
`this is not part of our function to fix`.



And finally,

If we can answer all above questions, try to put in with the more accurate
number (like from user survey), and provides communications it needs, will
definitely help in finding next official projects.

Also, when the evaluation is done, we should also evaluate the how's these
evaluation processes, how's guideline working for us? and which questions
above doesn't make any sense?.


[1]
https://governance.openstack.org/tc/reference/new-projects-requirements.html


May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180422/03641d72/attachment.html>