19:03:11 #startmeeting winterstack_naming 19:03:12 case in point ^ 19:03:12 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:03:15 The meeting name has been set to 'winterstack_naming' 19:03:30 Colleen Murphy proposed openstack-infra/puppet-cgit master: Update Gemfile for Zuulv3 https://review.openstack.org/571987 19:03:36 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 jbryce: sounds good 19:03:50 ++ 19:07:02 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 that sounds like an accurate summary to me 19:07:40 Colleen Murphy proposed openstack-infra/puppet-cgit master: Update Gemfile for Zuulv3 https://review.openstack.org/571987 19:08:11 yup that sounds right to me 19:08:33 ok cool 19:09:13 and this name should stand on its own from the openstack project or openstack foundation 19:09:37 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 yes 19:09:56 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 my yes was to jbryce but also yes to ianw 19:10:10 me too 19:10:23 ianw: my understanding is that we're talking about the actual hosted instances of the tools 19:10:58 ++ thanks for clarifying 19:11:18 yes 19:11:49 o/ 19:11:54 (late but better than ever) 19:11:55 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 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 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 it's about serving those projects, but not about serving the foundation itself, in my opinion 19:13:08 subtle distinction, perhaps? 19:13:12 hmm okay 19:13:34 the services are nto being run by the openstack foundation, they're being run by volunteers 19:13:42 er, s/nto/not/ 19:13:51 but also projects that are not hosted at the openstack foundation, right? i thought that might be cmurphy question 19:13:58 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 it's a good question. we've allowed related/stackforge projects to use git for years 19:14:08 sure, that too certainly. what we used to refer to as "stackforge" 19:14:11 yup 19:14:43 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 my guess is that the primary consumers would be foundation managed projects 19:15:20 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 but yes, I agree with what jbryce just said 19:15:29 and the possible governance structure corvus has proposed involves representatives from those top-level foundation projects 19:15:30 but in terms of naming...like "osf-infra.org" might be to tightly coupled 19:16:00 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 corvus: ++ 19:16:18 yep 19:16:37 ok cool 19:17:45 so when thinking about branding and naming, there are all kinds of approaches to it 19:18:47 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 i put together an etherpad earlier today where we could capture some ideas https://etherpad.openstack.org/p/infra-services-naming 19:21:10 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 hitting all 4 is really hard to do. especially if you want the domain name for it. = ) 19:21:38 no kidding 19:22:12 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 his favorite example was "thinsulate." mine is probably "jet ski" but in our space "github" was actually pretty good as well 19:23:36 yup 19:24:12 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 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 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 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 jbryce: sounds good to me and makes sense 19:28:46 no questions on my end 19:29:05 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 so the etherpad has 3 sections at the top that are really about describing the brand of these services 19:30:06 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 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 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 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 there's some really good stuff in those sections 19:41:57 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 mordred sure loves his farm animals 19:42:48 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 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 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 I've now got a goat bleat playing in my head 19:43:56 and collaboration across communities imho 19:44:27 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 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 mordred: yeah i agree 19:44:46 it's also an invite 19:45:04 yes. let's do this ... together 19:45:40 "Let us go then, you and I." 19:46:19 when the evening is set out against the sky 19:46:36 In an open way - "Let us go then, you and I and let's do it public"? 19:46:52 AJaeger: ++ 19:46:55 fungi: ++ 19:47:16 "let us git" 19:47:21 let us gate 19:47:29 veering close to letsencrypt 19:47:39 Let's git, together 19:47:45 and feel all right 19:47:52 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 seek - or build? 19:48:37 AJaeger: ++ 19:48:52 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 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 I'd worry that if we tied them together the effort required initially may be large 19:49:47 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 as long as the project is also willing to provide that oversight 19:50:07 but eventually ... totally agree with clarkb that tying them together at the outset is rife for failure 19:50:10 fungi: yes 19:50:47 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 ianw: ++ 19:51:07 right, there will be a delicate balance 19:51:07 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 ianw: I think we should prioritize providing good service over attempting to be fully self-service 19:51:24 lsell: ++ 19:51:44 lsell: this is a #FREEBRAINSTORM! your favorite part of the process 19:51:47 I don't want to say many negaitves, but a non-goal is becoming a github clone 19:52:04 anyway, the degree of future oversight is probably mostly orthogonal to the naming exercise 19:52:26 oops sorry :) 19:53:38 fungi: sake-of-argument - white-glove service is a potential feature we could want to focus on that might influence naming 19:54:18 yes, i can imagine ways in which the two would be related, hence my hedge words ;) 19:55:22 :) 19:55:49 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 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 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 then next week try to come up with a shortlist of 5-10 names that people like 19:57:49 that sounds doable 19:58:28 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 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 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 and just to gut check that i'm thinking about it in the correct way...in terms of the broader services 19:59:12 but yes, we should do that 19:59:14 ok 19:59:26 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 it's potentially just about all the services we're not already separately whiteboxing 19:59:53 https://docs.openstack.org/infra/system-config/systems.html 20:00:02 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 yay for docs 20:00:07 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 yah - I think we may want to offer some of the services optionally whitelabeled 20:00:34 corvus: yes, that was a big important one for me, openstack is quite easy to type out generally 20:00:36 er, whitelabelling, yes. i got my terms confused 20:01:44 so git.thebestfreesoftwareinfrastructure.org is not ideal 20:01:54 ++ 20:01:55 mordred: ya in general I think we should assume that all services would be offered not white labeled 20:02:04 and then there would be optional whitelabeling where it makes sense? 20:02:14 oh, that's a good point too 20:02:33 not every project who wants these things is going to have (or even want) a domain name of their own anyway 20:02:48 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 fungi: ++ 20:02:56 so even for teh whitelabelled services we'll likely have one under our default label too 20:03:09 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 fungi: yup exactly 20:03:17 jbryce: thanks a ton! 20:03:21 jbryce: thanks! 20:03:28 yes this was helpful 20:03:28 thanks! this was great 20:04:15 shall we end the meeting or did we want to continue? 20:05:28 seems like we've been idel 20:05:30 I can end it 20:05:32 #endmeeting