18:25:04 #startmeeting opendev-messaging 18:25:04 Meeting started Mon Oct 22 18:25:04 2018 UTC and is due to finish in 60 minutes. The chair is clarkb. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:25:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:25:06 ah 18:25:08 The meeting name has been set to 'opendev_messaging' 18:25:37 #link https://etherpad.openstack.org/p/infra-to-opendev-messaging Early thoughts on what we want to communicate opendev is and how that may affect opendev services 18:26:15 Long story short we want to effectively communicate what Opendev is to avoid perpetuating the existing confusions around the things that openstack infra does 18:26:33 ++ 18:26:45 In particular one concern is that if we say "openstack infra is now opendev" we haven't changed the message that we are the openstack infra team. We have only said we have a new name 18:26:56 i read through the etherpad and think the basics in there make sense. i think one question i still have is how broad is the "bigger than openstack" world we want to address 18:27:05 On the flip side we don't want to communicate that openstack is now on its own, they are still a user and an important one 18:27:12 corvus had some good words to that effect during our discussion at the ptg, and i'm trying to remember how he phrased it now 18:27:39 (that it's not simply a rebranding exercise) 18:28:08 fungi: i have forgotten everything before saturday :( 18:28:13 from an initial messaging standpoint, would something like "Community hosted tools and infrastructure for developing and maintaining open source software." capture the sentiment or would it be required that we call out OpenStack in the services offered? 18:28:51 jbryce: in my head I've seen as an implementation detail that it would be good to keep scope small to start with the intent of going broader 18:28:53 iamweswilson: that hits it for me 18:29:06 iamweswilson: ++ 18:29:10 my suggestion would be that we start with what we wanted OpenDev to be and flesh out the messaging and the brand, and then find the use cases that we need to address individually (like the openstack one) 18:29:11 jbryce: zuul and airship and starlingx are friendly projects that would benefit from this work that will understand the bumps along the way when we hit them 18:29:44 so anyone developing any open source software? (not arguing just asking) 18:30:06 good clarification sparkycollier 18:30:21 i think we want to underscore that we're about more than "just" open source software, but also provide open tools to help with open collaboration 18:31:00 spaykcollier: my guess is that would be the intent over time, but it will take time for us to practically reach that goal 18:31:24 sparkycollier: conceptually yes - although I don't think we want the flood gates to open on that immediately ... largely because we need to figure out how nodepool capacity is funded 18:31:30 yah - what lsell said 18:31:37 lsell: ++ and I do think that keeping the scope smaller to start will help keep things at a reasonable size while we figure out the transition 18:31:37 i'm thinking that the first step is to communicate to existing community / users about the changes, including the long-term vision and any short-term implications for their work 18:31:41 if you're looking for somewhere to publish the freely-licensed source code for this thing you've written, but aren't really looking to get together with like-minded people on improving it together, then this would work for you but there are a lot of other services out there which might be more what you're looking for 18:31:58 fungi: ++ 18:32:07 in other words, we're not just trying to get cloud/infrastructure software? Like if you develop open source for mobile phones or drones or tractors that's all welcome? (I'm not arguing against just wanting to be clear) 18:32:41 sparkycollier: in short, yes 18:33:00 agreed Fungi - I guess I'm searching for what wouldn't be a fit... seems like it's more like things that don't really want "our" collaboration model (as opposed to is/is not "cloud:) 18:33:01 i'm guessing one of the goals in the short term is also to recruit more contributors, in order to serve that larger audience 18:33:18 thanks! 18:33:20 sparkycollier: I think what we'll see is that the tools we provide likely aren't suited to tractor software dev so they will go elsewhere, but if they wanted to try and make that use case work with us then they should bne able to 18:33:27 lsell: yes 18:33:34 keep in mind that we likely wouldn't go out of our way to set up whitelabeled per-project services for most projects, just provide a means for them to use the services we offer under the opendev.org domain 18:33:34 lsell: + 18:33:46 lsell: in particular if we look at it from the current openstack-infra team perspective that may indicate to airship that they shouldn't get involved 18:33:58 when we think it would be awesome for them to interact as necessary to facilitate their needs 18:34:07 and recruiting more contributors benefits the openstack community, which is an important part of the message :) 18:34:40 (note airship has been doing a good job of being involved, that may have been a bad example) 18:34:52 we should add these goals to the etherpad (and any others that people think of) 18:35:24 clarkb: I think more that the companies who are interested in, say, airship, might have a vested interest in helping with opendev even if they don't care about, say, openstack 18:35:36 sparkycollier: to me it's less about software for a particular industry or a particular technology, and more about what your collaboration style is as a project 18:35:37 for some values of airship and openstack 18:35:49 fungi: ++ 18:36:04 one other tactical question, in the etherpad it mentioned it will take some time to transition git and gerrit...are you thinking weeks, months, a year? just trying to gauge when we want to communicate what 18:36:30 i expect some services to take us upwards of a year to migrate 18:36:34 others may disagree 18:36:54 it is related to how much pain existing users are willing to experience 18:36:55 lsell: months at best i'd guess. year is plausible. 18:37:13 I expect a good chunk of work to happen early train cycle to ease the pain openstack experiences 18:37:46 but maybe openstack is willing to ride it out earlier and we can psuh on big moves sooner 18:38:00 so part of the desire here is to be able to start communicating/discussing about that transition without tripping over the fact that that we haven't said 'opendev' except around the virtual water-cooler :) 18:38:07 corvus: ++ 18:38:15 is the thought to start communicating the name change more broadly while services are being over or wait until all is complete? 18:38:20 corvus: answered my Q 18:38:38 iamweswilson: ya we want to communicate it today so that we can take a step by step approach without confusing or surprising users 18:38:43 yeah, we just wanted to have a clear message we can all get behind first, i think 18:39:09 so we're not all going in different directions with how we're describing this, and causing more confusion 18:40:01 makes sense 18:40:05 i'm trying to turn these into goals on line 6 of the etherpad if anyone wants to check my work 18:40:16 jbryce: the goals you are capturing lgtm 18:40:17 well....starting on line 6 18:41:27 * fungi hates the term "best practices" (we could just say practices?) but otherwise i like it 18:42:26 what about "better than not good" practices? 18:42:31 ha 18:42:40 so i think we should do a messaging doc like we've done with the pilot projects to settle in on a few phrases we can use in all the comms 18:42:52 things like the one-liner from iamweswilson 18:42:57 (i spent enough time in places where it just meant the otherwise ineffective things you do to avoid being sued or fired) 18:42:58 but also maybe one that's a few sentences 18:43:18 jbryce: a few sentences would be valuable for existing users I expect 18:43:18 looking for my thumbsup enoji 18:43:32 since they already have some familiarity with the tooling and get the top level one liner 18:43:35 and then we can add in a few q&a that we know are important like the relationship to openstack projects, some of the next steps, timing, impact to existing services 18:44:00 jbryce: i like it 18:44:08 and then use those to start communicating broadly 18:44:10 iamweswilson's one-liner makes for a great intro, given lots of people won't read past the first sentence anyway 18:44:14 was very helpful with zuul 18:44:19 sounds like a good idea. make sure we capture the goals, any anticipated concerns, etc. today and then we can start a draft messaging doc for review 18:44:20 me too. I think that avoids trying to capture everything in a single message and instead rely on qa to dig into details 18:44:21 and then the details can follow it nicely there 18:44:21 jbryce: agreed. It would be great to surface that into a simple landing page to start with on the marketing side 18:44:45 i also think that we should think about some marketing to potential contributors 18:44:47 in terms of timing and channels, it sounds like a community email in the relatively near future is first on the list, and then do we want to communicate this again at the berlin summit? 18:45:29 lsell: we might also want to bring it up in the board meeting? 18:45:30 jbryce: by "marketing to potential contributors" you mean people to help us run it? or projects to start making use of it? 18:45:36 as we start talking about the transition, it will probably re-expose the whole concept of the infra team to some people (and first time exposure for others), so making it clear that they can come participate and what that looks like would be good 18:45:37 lsell: I worry berlin might be too early and give the impression we are ready for the hoard. But the board meeting might be a good venue there 18:45:38 the former 18:45:41 are we expecting opendev.org to host the simple landing page or will that live elsewhere? 18:45:51 fungi: the former of your options 18:45:52 jbryce: thanks, yes that would be amazing 18:45:58 jbryce: ++ that is a good point. I know we have had confusion over the fact that our infrastructure is community run 18:46:09 good point on the board meeting, maybe we should schedule time for opendev during the project updates section in the afternoon 18:46:11 i know we have the docs, but i think we need something kind of higher level 18:46:56 and i think it would be useful to actually feature some of the people who work on it as examples...almost like user stories except for from a infra engineer standpoint instead 18:46:58 lsell: i expect some fairly simple landing page at the root of opendev.org but probably lots of other documentation related to the service too. i don't think we've discussed it at length though 18:46:59 lsell: i like the idea of having a page where folks have quick access to this info and updates... maybe we can use opendev.org for that for now, and as it becomes less important, evolve that into the "about" page under opendev.org ? 18:47:01 infraneer? 18:47:25 corvus: agreed 18:47:38 also agree on the landing page 18:47:48 ++ 18:48:11 infranaut? 18:48:24 i think the benefit to talking about it in berlin -- being clear about what's happening now and the vision for the next year -- is that people are still very confused by all the projects hosted on openstack git 18:48:35 infranaut is good = ) 18:48:41 also - genericaly, having some words about what the infra team is and is not might be helpful to define the concept for people at their companies too ... I know there is frequently confusion for folks about "ci" teams being synonymous with QA teams 18:48:43 jbryce: that's a good idea -- that can also help us with the message that this is something anyone can contribute to, even as a part-time thing (which will be obvious when we feature a bunch of stories about us part-timers :) 18:48:54 we got this feedback in china last week, they were talking about the big tent and how many projects are in openstack. so we have an opportunity to almost bring up the misconception and talk about how we're addressing it 18:49:20 lsell: ++ 18:49:26 some of us also still liked the possibility of using the "collaboratory" term to describe the general suite of services we're providing 18:49:30 mordred: the user stories might help address the what it is part of that? 18:49:47 lsell: cool, as long as we know that we won't have much to show for it from a technical pov by berlin 18:49:59 technical/implementation even 18:50:09 the message in Berlin would be less of "now you can all use OpenDev" and more about what's to come 18:50:12 corvus: right that is my concern with broadly advertising it at berlin 18:50:28 hard to balance having a message around what we want to do with the risk of it seeming like vaporware 18:50:29 yep, there are pitfalls there, so we may have to walk a fine line 18:50:44 fungi: interesting about collaboratory. what would be the difference in meaning between opendev services and collaboratory services? 18:50:46 fungi: it does help that we already do things for openstack (and others) 18:51:02 opendev is the name, collaboratory is a term 18:51:34 so "the opendev collaboratory" would be a collaboratory of services provided by opendev 18:51:54 We have ~9 minutes left on the allotted hour. Happy to go longer if people can, but want to make sure we capture the next steps if people can't 18:52:01 I might not be dug in enough, but the two terms confuse me a bit. 18:52:12 collaboratory is a nice word that encapsulates what we're trying to do from a process pov. however, if you don't already know that, you still have to explain what a collaboratory is. so it might be helpful to sort of fix the idea in people's minds, but we still pretty much have to explain the whole deal. 18:52:39 clarkb: agreed 18:52:51 yes worth having bigger discussion, but sounds likeit won't come into play until farther down he line when there are more services 18:54:28 sounds like next steps are to work on a collaborative messaging doc, similar to what we did for zuul, and also a draft email for community lists. perhaps foundation marketing folks can take the lead on the messaging doc and then infra folks can take the lead on the email draft? 18:55:05 lsell: I expect the email draft may end up quoting significant parts of the messaging doc with some email specific introductions. But I'm happy to work on the email side of things 18:55:05 should we plan to review the draft messaging document next week, or how quickly do we need to move? 18:55:06 lsell: those lgtm. They're all captured in the etherpad as well 18:55:42 that seems like a fine timeline to me 18:55:44 lsell: next week is probably about the right speed. I think corvus may get dns running this week? so we'd be moving at roughly the same pace there? 18:56:25 and yeah, getting our new dns infrastructure up isn't really a user-facing change so safe to work on before we have something to more clearly communicate 18:56:45 assuming we can agree on Berlin messaging, we should probably have something on opendev,org by then, right? Even if a simple logo and one-liner? 18:56:59 iamweswilson: yes that should be doable 18:57:02 i think that's reasonable 18:57:14 I'm happy to help with that 18:57:20 iamweswilson: DNS is step 0 then we can reuse existing infra hosting like with zuul-ci.org to get something up 18:57:48 ++ to all above :) 18:59:11 sounds like we've got a good set of steps to move it forward. this is exciting! = ) 18:59:16 alright seems like we may be winding down. I can help with drafting both the main doc and the email and coordinate between infra/opendev and the foundation. 18:59:30 thanks!!! i think this was very helpful 18:59:31 perfect! thanks all 18:59:33 thanks for setting this up! 19:00:04 thank you everyone 19:00:07 #endmeeting