<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
<span>
</span><br>
<blockquote style="border: 0px none;"
cite="mid:33c5aefe-0d20-064f-fb31-1def6f9e2cbf@openstack.org"
type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="width:100%;border-top:1px solid #EDEEF0;padding-top:5px"> <div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:49%;">
<a moz-do-not-send="true" href="mailto:thierry@openstack.org"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Thierry Carrez</a></div> <div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:48%;text-align:
right;"> <font color="#9FA2A5"><span style="padding-left:6px">June
29, 2017 at 9:54 AM</span></font></div> </div></div>
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><div><!----><br>Unfortunately,
those pages just exist -- those hundreds of projects<br>projects might
be inactive, they still have git repositories and wiki<br>pages. We
could more actively clean them up (and then yes, adjusting the<br>corresponding
Google juice), but (1) we don't really have any right to<br>do so
unless we get permission (which is hard to get from dead<br>projects),
and (2) that's a giganormous amount of maintenance work.<br></div></div>
</blockquote>
It might be a giganormous amount of maintenance work, but it's the only
way you're going to properly fix the Google problem. You can still keep
the data archived, but I would change the link to something like
/inactive-projects/meteos, again with the proper redirects. And again,
updating the sitemap.<br>
<br>
As far as github, if the project is legitimately dead, the repo should
be set to private.<br>
<br>
Just because something is a lot of work doesn't mean it's not worth
doing :)<br>
<blockquote style="border: 0px none;"
cite="mid:33c5aefe-0d20-064f-fb31-1def6f9e2cbf@openstack.org"
type="cite">
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody">
<div><br></div>
</div>
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="width:100%;border-top:1px solid #EDEEF0;padding-top:5px"> <div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:49%;">
<a moz-do-not-send="true" href="mailto:jimmy@openstack.org"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Jimmy McArthur</a></div> <div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:48%;text-align:
right;"> <font color="#9FA2A5"><span style="padding-left:6px">June
29, 2017 at 8:49 AM</span></font></div> </div></div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody">
<br>
<br><br>If there is specifically confusion around Google searches, I'd
suggest
as a first step to spend some time working on redirects for dead
projects and very clearly updating documentation. For all of Google's
magic, there are some simple and easy rules to help correct bad search
data.
<br>
<br>Additionally, we just implemented SwifType on OpenStack.org and
docs.o.o
b/c Google deprecated their Site Search product. We have a ton of
control over that search and can very easily modify search results.
<br>
<br>Let me know if I can be of service on any of these fronts.
<br>
<br>
<br>__________________________________________________________________________
<br>OpenStack Development Mailing List (not for usage questions)
<br>Unsubscribe:
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<br><a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br></div>
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="width:100%;border-top:1px solid #EDEEF0;padding-top:5px"> <div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:49%;">
<a moz-do-not-send="true" href="mailto:thierry@openstack.org"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Thierry Carrez</a></div> <div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:48%;text-align:
right;"> <font color="#9FA2A5"><span style="padding-left:6px">June
29, 2017 at 3:00 AM</span></font></div> </div></div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody"><pre wrap="">Monty Taylor wrote:
</pre><blockquote type="cite"><pre wrap="">On 06/28/2017 09:50 AM, Thierry Carrez wrote:
</pre><blockquote type="cite"><pre wrap="">[...] Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The benefits of
offering that service are:
</pre></blockquote><pre wrap="">I disagree that this is removing the root cause.
I believe this is reacting to a misunderstanding by hiding from it. I do
not believe that doing this provides any value to us as a community.
Even though we do not actually use github for development, we have
implicitly accepted the false premise that github is a requirement. It
is suggested that the existence of git repos in the openstack/ github
org is confusing to people. And our reaction to that is to cut off
access to our Open Source tools that we set up to collaboratively
develop cloud software and tell people to go use the thing that people
suggest is one of the causes of people being confused?
</pre></blockquote><pre wrap=""><!---->
I don't think I agree. GitHub is just one area where confusion spreads.
Going back to my example, searching for "openstack machine learning" on
Google will give you links to GitHub, but also the OpenStack wiki, and
our cgit farm. All of them corroborate that the two projects returned
are, by all means, official (while they aren't).
So the suggestion (to cut off access to openstack project infrastructure
for things that are not openstack and will never be) is not in reaction
to GitHub, it's in reaction to the confusion that having them on the
very same project infrastructure creates (on all of our online
presence), *and* how hard it is to address that confusion at the edge.
</pre><blockquote type="cite"><pre wrap="">* People are not 'confused' by what OpenStack is.
Being "confused" is a passive-aggressive way of expressing that they
DISAGREE with what OpenStack is. We still have _plenty_ of people who
express that they think we should only be IaaS - so they're still going
to be unhappy with cloudkitty, congress and karbor.
Such people are under the misguided impression that kicking cloudkitty
out of OpenStack will somehow cause Nova features to land quicker. I
can't even begin to express all of the ways in which it's wrong. We
aren't a top-down corporate structure and we can't 'reassign' humans -
but even if we WERE - this flawed thinking runs afoul of the Mythical
Man Month.
</pre></blockquote><pre wrap=""><!---->
Sure, but you are missing my point. I totally agree that a lot of people
involved in OpenStack pretend to be confused, despite us being very
clear as to what's officially in OpenStack and what's not, and that's
their own way of complaining about how things turned out.
The confusion I'm talking about is not the passive-aggressive from
people involved in openstack. It's from our prospective new users, who
have no idea about our governance, making random searches on Google.
It's from people getting hit by marketing message from projects claiming
to be official OpenStack projects, while they are not. It's extremely
difficult for those to see clearly, especially with all our online
presence reinforcing the confusion.
</pre><blockquote type="cite"><pre wrap="">* Kicking non-official things out will not help
If I'm wrong about the above and it really is all just about not being
able to navigate a set of repositories that are prefixed with the string
'openstack/', it STILL WON'T HELP.
There are 1049 official repos. There are only 1676 repos in gerrit.
Do we honestly think that people who are confused are going to be less
confused by the number of repos in the sacred 'openstack/' namespace
going from 1676 to 1049? Do we next tell projects they can only have
their primary service managed? Kick out chef, puppet, juju and ansible,
as well as the deb- repos? Because maybe the existence of
openstack/deb-python-oslo.privsep is confusing someone?
</pre></blockquote><pre wrap=""><!---->
Again, I agree, but I think you're missing my point. Kicking
non-official things is not about cutting the number of repositories, or
somehow making the git.openstack.org/cgit front page more navigable. We
are indeed past that.
Kicking non-official things is about stopping blurring the line between
what's "in" openstack and what's "out". It's about someone googling for
machine learning on openstack, finding Cognitive on git.openstack.org
and wiki.openstack.org, assuming it's an official openstack project
based on those domain names, trying to check it out, realizing it's only
4 commits and dead for two years, and assuming OpenStack has pretty low
standards and is a bunch of dead crap. How do you propose we address
*that* ?
</pre><blockquote type="cite"><pre wrap="">[...]
</pre><blockquote type="cite"><pre wrap="">Thoughts on that ? Would you rather address the confusion at the edges,
or remove the root cause ?
</pre></blockquote><pre wrap="">The only reasonable action is actually addressing the confusion.
the confusion isn't just at the edges - the confusion is actually THE
ONLY PROBLEM. There is no other problem that needs to be solved _other_
than confusion in this area. The number of projects in gerrit is not a
technical problem. It's not overwhelming our governance. It's not a
problem for anyone who isn't confused (or saying they're confused when
they just disagree)
If we create problems for any our developers because there are people
who are confused rather than addressing the confusion, we will have
abdicated our responsibilities wholesale.
</pre></blockquote><pre wrap=""><!---->
That would be the first option. We continue to communicate about how
things really are, and find technical ways to drop markers on unofficial
projects so that people don't assume too much from the project hosting.
It's just a lot of maintenance work, and it's not been very successful
so far. With less and less resources on the infra team to implement
technical workarounds, I'm just not convinced that's a sustainable solution.
</pre></div>
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="width:100%;border-top:1px solid #EDEEF0;padding-top:5px"> <div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:49%;">
<a moz-do-not-send="true" href="mailto:mordred@inaugust.com"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Monty Taylor</a></div> <div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:48%;text-align:
right;"> <font color="#9FA2A5"><span style="padding-left:6px">June
28, 2017 at 4:50 PM</span></font></div> </div></div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody">On 06/28/2017 09:50 AM, Thierry
Carrez wrote:
<br><blockquote type="cite">Hi everyone,
<br>
<br>Two weeks ago, as a result of a discussion at the Board+TC+UC
workgroup
<br>working on "better communicating what is openstack", I started a
<br>thread[1] about moving away from big tent terminology. The thread
went
<br>in a lot of directions, including discussing GitHub mirroring
strategy,
<br>what makes projects want to be official, the need for returning to a
<br>past when everything was (supposedly) simpler, and naming fun.
<br>
<br>[1]
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html">http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html</a>
<br>
<br>Many agreed that the "Big Tent" name (as a synonym to "official
<br>openstack projects") is hurting more than it helps, and we should
stop
<br>using it. The issue is, merely stopping using it won't be enough. We
<br>have tried, and the name sticks. You need to replace the name by
<br>something that sticks more, or address the root cause directly.
<br>
<br>The central issue being discussed here is an issue of external
<br>perception. It's hard for newcomers to the OpenStack world to see
what
<br>is a part of OpenStack and what's not. If you google "openstack
machine
<br>learning", the first hits are Cognitive and Meteos, and it's
impossible
<br>to tell that those are actually not OpenStack projects. One of those
has
<br>been dead for 2 years -- having people think that those are official
<br>projects hurts all the OpenStack projects, by lowering expectations
<br>around what that means, in terms of quality, maintenance, or
community.
<br>
<br>The confusion mainly stems from the fact that OpenStack project
<br>infrastructure is open to any open source project (and it's nobody's
job
<br>to clean up dead things). So you can find (on our wiki, on our
<br>mailing-list, on our cgit farm, on our gerrit, on our GitHub
<br>organization...) things that are actually not OpenStack, even with
the
<br>expansive "are you one of us" definition. Arguably the most
confusing
<br>aspect is the "openstack/" prefix in the git repository name, which
<br>indicates some kind of brand association.
<br>
<br>I'd say we have two options. We can address the perception issue on
the
<br>edges, or you can treat the root cause. Neither of those options is
<br>really an OpenStack governance change (or "big tent" change) --
they
<br>are more about what to do with things that are actually *not* in our
<br>governance.
<br>
<br>Addressing the perception on the edges means making it clearer when
<br>things are not official. The thread above discussed a lot of
potential
<br>solutions. We could give unofficial things a catchy group name
<br>(Stackforge, Opium, Electrons...), and hope it sticks. We could find
a
<br>way to tag all projects on GitHub that are not official, or mirror
them
<br>to another organization, or stop mirroring them altogether. We could
<br>remove the openstack/ prefix from all the projects we host. We could
<br>actively mark all wiki pages that are not about an official project.
We
<br>could set up a separate Gerrit or separate ML for hosted projects
<br>development discussions. The main issue with that approach is that
it's
<br>a *lot* of work, and it never completely eliminates the confusion.
<br>
<br>Removing the root cause would be a more radical move: stop offering
<br>hosting to non-OpenStack projects on OpenStack infrastructure
<br>altogether. We originally did that for a reason, though. The
benefits of
<br>offering that service are:
<br></blockquote>
<br>I disagree that this is removing the root cause.
<br>
<br>I believe this is reacting to a misunderstanding by hiding from it. I
do
not believe that doing this provides any value to us as a community.
<br>
<br>Even though we do not actually use github for development, we have
implicitly accepted the false premise that github is a requirement. It
is suggested that the existence of git repos in the openstack/ github
org is confusing to people. And our reaction to that is to cut off
access to our Open Source tools that we set up to collaboratively
develop cloud software and tell people to go use the thing that people
suggest is one of the causes of people being confused?
<br>
<br>* People are not 'confused' by what OpenStack is.
<br>
<br>Being "confused" is a passive-aggressive way of expressing that they
DISAGREE with what OpenStack is. We still have _plenty_ of people who
express that they think we should only be IaaS - so they're still going
to be unhappy with cloudkitty, congress and karbor.
<br>
<br>Such people are under the misguided impression that kicking
cloudkitty
out of OpenStack will somehow cause Nova features to land quicker. I
can't even begin to express all of the ways in which it's wrong. We
aren't a top-down corporate structure and we can't 'reassign' humans -
but even if we WERE - this flawed thinking runs afoul of the Mythical
Man Month.
<br>
<br>* Kicking non-official things out will not help
<br>
<br>If I'm wrong about the above and it really is all just about not
being
able to navigate a set of repositories that are prefixed with the string
'openstack/', it STILL WON'T HELP.
<br>
<br>There are 1049 official repos. There are only 1676 repos in gerrit.
<br>
<br>Do we honestly think that people who are confused are going to be
less
confused by the number of repos in the sacred 'openstack/' namespace
going from 1676 to 1049? Do we next tell projects they can only have
their primary service managed? Kick out chef, puppet, juju and ansible,
as well as the deb- repos? Because maybe the existence of
<br>openstack/deb-python-oslo.privsep is confusing someone?
<br>
<br>Guess what? We're big. Software is hard. Life doesn't fit into neat
packages people want it to fit in to.
<br>
<br>
<br><blockquote type="cite">1- it lets us set up code repositories and
testing infrastructure before
<br>a project applies to be an official OpenStack project.
<br>
<br>2- it lets us host things that are not openstack but which we work
on
<br>(like abandoned Python libraries or GPL-licensed things) in a
familiar
<br>environment
<br>
<br>3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack
itself
<br>
<br>I would argue that we could handle (1) and (2) within our current
<br>governance.
<br>
<br>For (1) we could have an "onboarding" project team that would help
<br>incoming projects through the initial steps of becoming an openstack
<br>project. The team would act as an umbrella team, an experimental
area
<br>for projects that have some potential to become an OpenStack project
one
<br>day. There would be a time limit -- if after one year(?) it looks
like
<br>you won't become an openstack project after all, the onboarding team
<br>would clean you up. I actually think a bit more project mentoring
would
<br>serve us better than our current hands-free approach.
<br>
<br>For (2) we could also have some other official project team as an
<br>umbrella for those deps we depend on and have to continue
maintaining.
<br>Or we could expand Oslo's team scope to cover it. It's just a couple
of
<br>repositories anyway.
<br>
<br>That leaves (3). I would argue that was a nice thing to have, but
its
<br>impact was very limited (not so many successful/alive projects in
that
<br>category). I guess if the need is still there and people really want
to
<br>work on this, it could be (and actually has been) set up as a
parallel
<br>infrastructure. The confusion that stems from running it on top of
the
<br>very same infrastructure is just too costly for us at this point.
<br>
<br>This radical solution still means work, but it's one-time governance
<br>work, rather than infra changes / continuous curation work. It *is*
<br>radical though, especially for the affected git repositories (for
which
<br>we often don't have any contact email). It will also make removing
<br>projects a lot more difficult (as there will be consequences in
terms of
<br>project hosting).
<br></blockquote>
<br>The work to do this provides absolutely no benefit.
<br>
<br><blockquote type="cite">Thoughts on that ? Would you rather address
the confusion at the edges,
<br>or remove the root cause ?
<br></blockquote>
<br>The only reasonable action is actually addressing the confusion.
<br>
<br>the confusion isn't just at the edges - the confusion is actually
THE
ONLY PROBLEM. There is no other problem that needs to be solved _other_
than confusion in this area. The number of projects in gerrit is not a
technical problem. It's not overwhelming our governance. It's not a
problem for anyone who isn't confused (or saying they're confused when
they just disagree)
<br>
<br>If we create problems for any our developers because there are
people
who are confused rather than addressing the confusion, we will have
abdicated our responsibilities wholesale.
<br>
<br>Monty
<br>
<br>__________________________________________________________________________
<br>OpenStack Development Mailing List (not for usage questions)
<br>Unsubscribe:
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<br><a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br></div>
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="width:100%;border-top:1px solid #EDEEF0;padding-top:5px"> <div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:49%;">
<a moz-do-not-send="true" href="mailto:thierry@openstack.org"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Thierry Carrez</a></div> <div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:48%;text-align:
right;"> <font color="#9FA2A5"><span style="padding-left:6px">June
28, 2017 at 9:50 AM</span></font></div> </div></div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody"><div>Hi everyone,<br><br>Two
weeks ago, as a result of a discussion at the Board+TC+UC workgroup<br>working
on "better communicating what is openstack", I started a<br>thread[1]
about moving away from big tent terminology. The thread went<br>in a lot
of directions, including discussing GitHub mirroring strategy,<br>what
makes projects want to be official, the need for returning to a<br>past
when everything was (supposedly) simpler, and naming fun.<br><br>[1]
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html">http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html</a><br><br>Many
agreed that the "Big Tent" name (as a synonym to "official<br>openstack
projects") is hurting more than it helps, and we should stop<br>using
it. The issue is, merely stopping using it won't be enough. We<br>have
tried, and the name sticks. You need to replace the name by<br>something
that sticks more, or address the root cause directly.<br><br>The
central issue being discussed here is an issue of external<br>perception.
It's hard for newcomers to the OpenStack world to see what<br>is a part
of OpenStack and what's not. If you google "openstack machine<br>learning",
the first hits are Cognitive and Meteos, and it's impossible<br>to tell
that those are actually not OpenStack projects. One of those has<br>been
dead for 2 years -- having people think that those are official<br>projects
hurts all the OpenStack projects, by lowering expectations<br>around
what that means, in terms of quality, maintenance, or community.<br><br>The
confusion mainly stems from the fact that OpenStack project<br>infrastructure
is open to any open source project (and it's nobody's job<br>to clean
up dead things). So you can find (on our wiki, on our<br>mailing-list,
on our cgit farm, on our gerrit, on our GitHub<br>organization...)
things that are actually not OpenStack, even with the<br>expansive "are
you one of us" definition. Arguably the most confusing<br>aspect is the
"openstack/" prefix in the git repository name, which<br>indicates some
kind of brand association.<br><br>I'd say we have two options. We can
address the perception issue on the<br>edges, or you can treat the root
cause. Neither of those options is<br>really an OpenStack governance
change (or "big tent" change) -- they<br>are more about what to do with
things that are actually *not* in our<br>governance.<br><br>Addressing
the perception on the edges means making it clearer when<br>things are
not official. The thread above discussed a lot of potential<br>solutions.
We could give unofficial things a catchy group name<br>(Stackforge,
Opium, Electrons...), and hope it sticks. We could find a<br>way to tag
all projects on GitHub that are not official, or mirror them<br>to
another organization, or stop mirroring them altogether. We could<br>remove
the openstack/ prefix from all the projects we host. We could<br>actively
mark all wiki pages that are not about an official project. We<br>could
set up a separate Gerrit or separate ML for hosted projects<br>development
discussions. The main issue with that approach is that it's<br>a *lot*
of work, and it never completely eliminates the confusion.<br><br>Removing
the root cause would be a more radical move: stop offering<br>hosting
to non-OpenStack projects on OpenStack infrastructure<br>altogether. We
originally did that for a reason, though. The benefits of<br>offering
that service are:<br><br>1- it lets us set up code repositories and
testing infrastructure before<br>a project applies to be an official
OpenStack project.<br><br>2- it lets us host things that are not
openstack but which we work on<br>(like abandoned Python libraries or
GPL-licensed things) in a familiar<br>environment<br><br>3- it spreads
"the openstack way" (Gerrit, Zuul) beyond openstack itself<br><br>I
would argue that we could handle (1) and (2) within our current<br>governance.<br><br>For
(1) we could have an "onboarding" project team that would help<br>incoming
projects through the initial steps of becoming an openstack<br>project.
The team would act as an umbrella team, an experimental area<br>for
projects that have some potential to become an OpenStack project one<br>day.
There would be a time limit -- if after one year(?) it looks like<br>you
won't become an openstack project after all, the onboarding team<br>would
clean you up. I actually think a bit more project mentoring would<br>serve
us better than our current hands-free approach.<br><br>For (2) we could
also have some other official project team as an<br>umbrella for those
deps we depend on and have to continue maintaining.<br>Or we could
expand Oslo's team scope to cover it. It's just a couple of<br>repositories
anyway.<br><br>That leaves (3). I would argue that was a nice thing to
have, but its<br>impact was very limited (not so many successful/alive
projects in that<br>category). I guess if the need is still there and
people really want to<br>work on this, it could be (and actually has
been) set up as a parallel<br>infrastructure. The confusion that stems
from running it on top of the<br>very same infrastructure is just too
costly for us at this point.<br><br>This radical solution still means
work, but it's one-time governance<br>work, rather than infra changes /
continuous curation work. It *is*<br>radical though, especially for the
affected git repositories (for which<br>we often don't have any contact
email). It will also make removing<br>projects a lot more difficult (as
there will be consequences in terms of<br>project hosting).<br><br>Thoughts
on that ? Would you rather address the confusion at the edges,<br>or
remove the root cause ?<br><br></div></div>
</blockquote>
<br>
</body></html>