Open Stack

2018-04-23 22:43 GMT+08:00 Doug Hellmann <doug at doughellmann.com>:
>
> Excerpts from Rico Lin's message of 2018-04-22 16:50:51 +0800:
> > 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?`
>
> Our current policy is to allow projects with contributors from a small
> number of affiliations (even a single employer), under the theory that
> bringing a team into the community officially will help them grow by
> showing them the benefits of being more diverse and by making it easier
> for other community members who have employer restrictions on their open
> source work to justify contributing.
>
> Would you change that policy in any way?
I'm fine with the number of developers involved in the project. we should
encourage
people working on any crazy ideas. But the point is `is that developer
active?
and will he/she helps others to join that projects or just waiting for
others?`.
If we can try to put such requirement in policy will be better IMO.
Otherwise,
we can keep the policy but the diversity of developers might help to reduce
chances of that risk.
>
> >
> > `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.
>
> Please see my other question about projects with overlapping feature
> sets [1].
Done:)
>
> Doug
>
> [1]
http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html
>
> >
> > `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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
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/20180424/22f3e106/attachment.html>