19:03:11 <clarkb> #startmeeting winterstack_naming
19:03:12 <fungi> case in point ^
19:03:12 <openstack> Meeting started Wed Jun 13 19:03:11 2018 UTC and is due to finish in 60 minutes.  The chair is clarkb. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:15 <openstack> The meeting name has been set to 'winterstack_naming'
19:03:30 <openstackgerrit> Colleen Murphy proposed openstack-infra/puppet-cgit master: Update Gemfile for Zuulv3  https://review.openstack.org/571987
19:03:36 <jbryce> so what if start out by just putting out there what i think we're talking about and trying to name/brand and y'all can tell me where i'm wrong, and then i can talk about some steps for working towards a name
19:03:44 <clarkb> jbryce: sounds good
19:03:50 <mordred> ++
19:07:02 <jbryce> over the years, we've built up a set of tools and services to enable the "openstack way" of collaborating, including code management and communications tools. there's a feeling that these are too tightly coupled to the openstack project because of their existing naming schemes and we'd like to come up with another way to refer to them so that they are available to other projects that could benefit from the same tools
19:07:39 <fungi> that sounds like an accurate summary to me
19:07:40 <openstackgerrit> Colleen Murphy proposed openstack-infra/puppet-cgit master: Update Gemfile for Zuulv3  https://review.openstack.org/571987
19:08:11 <clarkb> yup that sounds right to me
19:08:33 <jbryce> ok cool
19:09:13 <jbryce> and this name should stand on its own from the openstack project or openstack foundation
19:09:37 <ianw> this isn't about a "puppet-openstackci" type thing though, where we support "replicating" openstack-infra locally in your environment though, correct?  it's about traditionally non-openstack things using the existing infrastructure we have?
19:09:48 <mordred> yes
19:09:56 <clarkb> yes, I think one of the specific concerns by "others" is that they are not openstack and don't want to be openstack so something "neutral" is helpful
19:10:05 <clarkb> my yes was to jbryce but also yes to ianw
19:10:10 <mordred> me too
19:10:23 <jbryce> ianw: my understanding is that we're talking about the actual hosted instances of the tools
19:10:58 <ianw> ++ thanks for clarifying
19:11:18 <fungi> yes
19:11:49 <mnaser> o/
19:11:54 <mnaser> (late but better than ever)
19:11:55 <jbryce> when i think about those services, i obviously include git/gerrit services, but i also think things like etherpad/calc, storyboard and other things could be part of the overall "suite" of tools
19:12:03 <fungi> case in point, the other day we were asked if etherpad.openstack.org was available by any other domain names because there was something going on at kubecon and they wanted to take some notes on our etherpad but didn't want to use something with openstack in the domain
19:12:28 <cmurphy> i'm curious about the part about standing on its own free from the foundation, i'd been assuming that this team's mission was in large part about serving the projects presided over by the foundation
19:13:02 <fungi> it's about serving those projects, but not about serving the foundation itself, in my opinion
19:13:08 <fungi> subtle distinction, perhaps?
19:13:12 <cmurphy> hmm okay
19:13:34 <fungi> the services are nto being run by the openstack foundation, they're being run by volunteers
19:13:42 <fungi> er, s/nto/not/
19:13:51 <lsell> but also projects that are not hosted at the openstack foundation, right? i thought that might be cmurphy question
19:13:58 <mordred> yah. I don't think it's so much about being separate from the foundation - as in being separate from the first/primary project (openstack) it grew to serve
19:13:59 <jbryce> it's a good question. we've allowed related/stackforge projects to use git for years
19:14:08 <fungi> sure, that too certainly. what we used to refer to as "stackforge"
19:14:11 <mordred> yup
19:14:43 <mordred> I'd also like to consider the possibility of offering our services more broadly as we think about naming - even if we don't do so immediately
19:14:54 <jbryce> my guess is that the primary consumers would be foundation managed projects
19:15:20 <mordred> so - if, say, drizzle wanted to ressurrect and use winterscale - that we'd be organized such that that would be decently feasible
19:15:28 <mordred> but yes, I agree with what jbryce just said
19:15:29 <fungi> and the possible governance structure corvus has proposed involves representatives from those top-level foundation projects
19:15:30 <jbryce> but in terms of naming...like "osf-infra.org" might be to tightly coupled
19:16:00 <corvus> so in short, a name for a service which provides our traditional infrastructure tooling to all projects under the foundations umbrella, almost certainly projects informally related to those, and possibly, in the future, projects even less directly affiliated.
19:16:09 <mordred> corvus: ++
19:16:18 <fungi> yep
19:16:37 <jbryce> ok cool
19:17:45 <jbryce> so when thinking about branding and naming, there are all kinds of approaches to it
19:18:47 <jbryce> in the thread i saw, there were a lot of domain names flying around, which is a good thing to think about eventually, but i think it might be good to get some of the higher level things we want to communicate first. i'm sure y'all have had some of these discussions already, but it would be helpful for me to hear about it
19:19:12 <jbryce> i put together an etherpad earlier today where we could capture some ideas https://etherpad.openstack.org/p/infra-services-naming
19:21:10 <jbryce> one of the best branding people i worked with always said that great names had some common characteristics they 1) are short, simple to say (or spell) 2) are memorable 3) imply the category and 4) imply the difference within that category
19:21:27 <jbryce> hitting all 4 is really hard to do. especially if you want the domain name for it. = )
19:21:38 <clarkb> no kidding
19:22:12 <jbryce> but i think they're good goals to shoot for, because ultimately, it means you're communicating a lot every time your name gets used anywhere
19:23:07 <jbryce> his favorite example was "thinsulate."  mine is probably "jet ski" but in our space "github" was actually pretty good as well
19:23:36 <mordred> yup
19:24:12 <jbryce> and as you start to work your way towards names, there are different types of names - you can have straight up descriptive names, symbolic names, whimsical names, or "empty vessel" names that have no meaning or are invented words (again because of domain names a lot of times)
19:25:32 <fungi> i recall one company i worked for renamed to a nonsense word because it would be easier to get a trademark on it (we already had the domain name for the old name which was an actual dictionary word)
19:25:32 <jbryce> the 1st 2 kinds are usually faster to build brand equity around than the last 2, but i think they can all work
19:27:28 <jbryce> that spiel is a bit of background about my thoughts in general on naming and branding. basically what i have as goals when trying to pick a name. any feedback on that part?
19:28:15 <mordred> jbryce: sounds good to me and makes sense
19:28:46 <fungi> no questions on my end
19:29:05 <jbryce> coo. if people think that part makes sense then it will give us some goal posts to talk about short listed names when we get to that point
19:29:33 <jbryce> so the etherpad has 3 sections at the top that are really about describing the brand of these services
19:30:06 <jbryce> the first section is basically a place to throw words or phrases that you would love to have associated with the services. i see some good ones in there already
19:30:52 <jbryce> the second section is to try to list out some of the things that would make these services different than other alternatives like github/gitlab/etc (doesn't have to be "better than" just "different than")
19:31:55 <jbryce> and the third section is to list out the kinds people or organizations that should be interested in it and anything that is identifying about them
19:32:52 <jbryce> the #freebrainstorm section is a place to put name proposals no matter how good, bad, taken, impractical they might be and the short list is something to gather top candidates in
19:40:32 <jbryce> there's some really good stuff in those sections
19:41:57 <jbryce> reading through, it makes me think about one of the things we saw leading into the last summit in vancouver. we do some basic advertising for the summit and some of the most effective ads had this theme of "let's do this"
19:42:46 <fungi> mordred sure loves his farm animals
19:42:48 <jbryce> like "let's build open infrastructure" or "let's secure the cloud" or things like that...the collaboration and working on things seemed to be appealing
19:43:08 * mordred hands fungi a box full of what he is pretty sure are bunnies
19:43:33 <mordred> jbryce: yes. I like that. there's another facet of that I'd love to capture but don't have good words for ...
19:43:36 <jbryce> so it's interesting that's an really prevalent idea here too. the collaboration in the sense of enabling collaboration with the tools and services, but also in the sense that the services themselves are a collaboration
19:43:38 <clarkb> I've now got a goat bleat playing in my head
19:43:56 <mnaser> and collaboration across communities imho
19:44:27 <mordred> jbryce: which is where "let's do this" diverges from "jfdi" - to me, "let's do this" is about getting stuff done but not burning the world in the process ... because long-term sustaintability is also important
19:44:28 <jbryce> the services are made up of other tools that were collaboratively developed across communities, they are operated collaboratively, and they enable collaboration
19:44:40 <jbryce> mordred: yeah i agree
19:44:46 <jbryce> it's also an invite
19:45:04 <mordred> yes. let's do this ... together
19:45:40 <mordred> "Let us go then, you and I."
19:46:19 <fungi> when the evening is set out against the sky
19:46:36 <AJaeger> In an open way - "Let us go then, you and I and let's do it public"?
19:46:52 <mordred> AJaeger: ++
19:46:55 <mordred> fungi: ++
19:47:16 <jbryce> "let us git"
19:47:21 <jbryce> let us gate
19:47:29 <fungi> veering close to letsencrypt
19:47:39 <sparkycollier___> Let's git, together
19:47:45 <jbryce> and feel all right
19:47:52 <mordred> fwiw, I mis-remembered the prufrock at first and got myself to ulysses: "Come, my friends, 'Tis not to late to seek a newer world."
19:48:32 <AJaeger> seek - or build?
19:48:37 <mordred> AJaeger: ++
19:48:52 <ianw> is the idea to move to a self-service model, al-la github/gitlab/git* ?  few clicks and you have repo and gerrit etc etc?  or maintain our current status quo of slightly more overview?
19:49:20 <fungi> ianw: i think more self-service has always been a goal, but i don't think we need to tie the two together
19:49:43 <clarkb> I'd worry that if we tied them together the effort required initially may be large
19:49:47 <mordred> yah. I'd like to have some more self-service available - but also have the ability for a project, such as OpenStack, to chose that it desires some amount of centralized oversight
19:50:06 <fungi> as long as the project is also willing to provide that oversight
19:50:07 <mordred> but eventually ... totally agree with clarkb that tying them together at the outset is rife for failure
19:50:10 <mordred> fungi: yes
19:50:47 <ianw> i do worry with more self service we tend towards things open projects often handle badly, such as monitoring for abuse etc
19:50:59 <mordred> ianw: ++
19:51:07 <fungi> right, there will be a delicate balance
19:51:07 <lsell> i really like the "let's do this" messaging but also think it could be incorporated into a tagline if it doesn't fit into the name
19:51:22 <mordred> ianw: I think we should prioritize providing good service over attempting to be fully self-service
19:51:24 <mordred> lsell: ++
19:51:44 <jbryce> lsell: this is a #FREEBRAINSTORM! your favorite part of the process
19:51:47 <mordred> I don't want to say many negaitves, but a non-goal is becoming a github clone
19:52:04 <fungi> anyway, the degree of future oversight is probably mostly orthogonal to the naming exercise
19:52:26 <lsell> oops sorry :)
19:53:38 <mordred> fungi: sake-of-argument - white-glove service is a potential feature we could want to focus on that might influence naming
19:54:18 <fungi> yes, i can imagine ways in which the two would be related, hence my hedge words ;)
19:55:22 <mordred> :)
19:55:49 <clarkb> Our hour is almost up (though not sure we formally made this an hour long meeting), want to amke sure we wrap up with some future direction if we do have to end soon
19:56:13 <jbryce> well...i like the stuff that's going into the etherpad. here's what i would suggest for moving forward from here. over the next couple of days, keep fleshing out the top 3 sections and also put potential names in the #freebrainstorm section
19:56:49 <jbryce> i'll try to get some foundation staffers to look through it with their creative hats on too and throw some additional ideas or alternatives
19:57:17 <jbryce> then next week try to come up with a shortlist of 5-10 names that people like
19:57:49 <fungi> that sounds doable
19:58:28 <jbryce> at that point, we can go a couple of directions...either a vote around it, or start to do some of the next level deeper research on things like domains, trademarks, inappropriate meanings in non-english, etc = )
19:58:30 <lsell> jbryce, could we also add a section in the etherpad with anticipated uses? for example, it was eye opening for me when I thought about the name in context of etherpad.XX.org or storyboard.XX.org etc?
19:59:06 <jbryce> i was going to do that earlier, but......i couldn't find the other etherpad where we had started listing out the services
19:59:08 <lsell> and just to gut check that i'm thinking about it in the correct way...in terms of the broader services
19:59:12 <jbryce> but yes, we should do that
19:59:14 <lsell> ok
19:59:26 <mnaser> lsell: i think that's a good point, we can list a few of the basic services like gerrit/review, etherpad, ethercalc, storyboard, zuul
19:59:44 <fungi> it's potentially just about all the services we're not already separately whiteboxing
19:59:53 <mnaser> https://docs.openstack.org/infra/system-config/systems.html
20:00:02 <ianw> should we setup an indication-only vote to whittle it down to the short-list?  or delegate pruning it to someone(s)?  (both?)
20:00:06 <mnaser> yay for docs
20:00:07 <corvus> also, the domain name may end up typed in a lot of shell commands.  eg: "git clone https://git.openstack.org/openstack/nova"
20:00:11 <mordred> yah - I think we may want to offer some of the services optionally whitelabeled
20:00:34 <mnaser> corvus: yes, that was a big important one for me, openstack is quite easy to type out generally
20:00:36 <fungi> er, whitelabelling, yes. i got my terms confused
20:01:44 <jbryce> so git.thebestfreesoftwareinfrastructure.org is not ideal
20:01:54 <mnaser> ++
20:01:55 <clarkb> mordred: ya in general I think we should assume that all services would be offered not white labeled
20:02:04 <clarkb> and then there would be optional whitelabeling where it makes sense?
20:02:14 <fungi> oh, that's a good point too
20:02:33 <fungi> not every project who wants these things is going to have (or even want) a domain name of their own anyway
20:02:48 <mordred> clarkb: yah. at some point I think it might be a good idea to have a list of "it is possible to provide custom whitelabeled versions of X  Y and Z"
20:02:53 <mordred> fungi: ++
20:02:56 <fungi> so even for teh whitelabelled services we'll likely have one under our default label too
20:03:09 <jbryce> i've got to run. thanks for humoring me on naming theory. feel free to ping me if you have other questions or ideas = )
20:03:11 <clarkb> fungi: yup exactly
20:03:17 <mordred> jbryce: thanks a ton!
20:03:21 <AJaeger> jbryce: thanks!
20:03:28 <clarkb> yes this was helpful
20:03:28 <fungi> thanks! this was great
20:04:15 <fungi> shall we end the meeting or did we want to continue?
20:05:28 <clarkb> seems like we've been idel
20:05:30 <clarkb> I can end it
20:05:32 <clarkb> #endmeeting