15:02:42 <kgriffs> #startmeeting marconi
15:02:43 <openstack> Meeting started Tue Jun  3 15:02:42 2014 UTC and is due to finish in 60 minutes.  The chair is kgriffs. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:47 <openstack> The meeting name has been set to 'marconi'
15:03:17 <vkmc> o/
15:03:25 <kgriffs> o/
15:03:48 <alcabrera> ~o~
15:04:10 <cpallares> \o_O/
15:04:19 <vkmc> *\o/*
15:04:25 <kgriffs> #topic Using the mailing list to offload meeting time
15:04:25 <prashanthr_> lots of 'o' art in progress 0-0
15:04:42 <kgriffs> so, as you may have noticed, a few of us have being trying to use the mailing list more
15:04:44 <sriram> o/
15:05:01 <kgriffs> I think it is a good way to have "the meeting before the meeting" which will make our agenda items go much quicker
15:05:07 <Obulpathi> o/
15:05:36 <tjanczuk> I think ML works better than IRC for longer discussions that require more context.
15:05:42 <kgriffs> +1
15:06:01 <tjanczuk> The price is it takes longer to discuss.
15:06:09 <kgriffs> also, it allows more people in the community to join in the conversations, or at least follow along
15:06:33 <kgriffs> tjanczuk: yep. I think we can find a balance between IRC, ML, and mtgs.
15:07:21 <kgriffs> We should really discuss each topic in all three places, but strive to capture important notes/decisions in the ML if they come up elsewhere
15:07:31 <kgriffs> just my $0.02
15:08:11 <kgriffs> you can also use the ML to vet and idea, and then we can finalize it in our meetings, which are also logged/recorded
15:09:40 <alcabrera> From a communications POV, it makes sense to engage the ML for questions of direction
15:09:46 <alcabrera> are we building the thing that people want to use?
15:09:50 <kgriffs> anyway, I'd like everyone to try to follow subjects starting with [marconi] on the mailing list, and participate in those threads
15:10:45 <tjanczuk> It would be good if the responsiveness to ML topics was similar to IRC ones.
15:11:00 <kgriffs> alcabrera: that's a good point. On that question, we may want to also use the user list (openstack@) to engage folks on usability and operations
15:11:06 <kgriffs> tjanczuk: +1
15:11:08 <alcabrera> good thought, kgriffs
15:12:00 <kgriffs> ok, so let's everyone be more active on the mailing lists. Also, I'd like to see more activity on the Ask site from folks outside the core reviewers team. Just sayin'. :)
15:12:11 <kgriffs> moving on...
15:13:16 <kgriffs> #topic specs process
15:13:22 <kgriffs> malini: can you summarize the discussion so far?
15:13:28 <malini> sure
15:13:41 <malini> Hope everybody had a chance to review the thread in ML
15:13:57 <alcabrera> a bit
15:14:05 <malini> We have most of OS moving the Specs route & I just wanted to pick everybody's brains if Marconi should too
15:14:20 <alcabrera> #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/036509.html
15:14:34 <malini> Specs is good, because it bring a certain formal process in the design phase
15:14:46 <malini> But I think us being a small team, we dont need it yet
15:15:07 <malini> Since we do a lot of design discussions in IRC/ML/meetings
15:15:35 <alcabrera> I have a few thoughts on this
15:15:44 <malini> alcabrera: sure
15:16:01 <alcabrera> I'm not sure how specs are being used across OS
15:16:03 <alcabrera> but
15:16:09 <alcabrera> where specs are most valuable, are not in reference to particular BPs, but rather
15:16:14 <alcabrera> into protcols
15:16:16 <alcabrera> wire or whatnot
15:16:18 <alcabrera> grammars
15:16:21 <alcabrera> for DSLs etc
15:16:23 <alcabrera> and
15:16:26 <alcabrera> for HTTP expected behaviors
15:16:30 <alcabrera> and APIs
15:16:40 <tjanczuk> I think having a spec up front is useful for controversial issues that need discussion. For all other issues it could be done post-mortem as documentation.
15:16:49 <malini> for clarity specs == design docs, in what I have seen for other OS projects
15:16:57 <malini> tjanczuk: +1
15:17:05 <kgriffs> basically, it is a formalization of the blueprinting process
15:17:08 <malini> & tht too , we shud not require it for every bp
15:17:28 <kgriffs> so, instead of editing a wiki page and linking that to a bp, you actually write up specs in text files and they go through the gerrit review process
15:17:33 <kgriffs> iirc
15:17:37 <alcabrera> queue flavors would one area that would warrant a design spec, imo
15:17:46 <alcabrera> **would be one
15:17:46 <kgriffs> tjanczuk: that makes sense
15:17:50 <sriram> alcabrera: +1
15:18:13 <kgriffs> I think there are a few dimensions to this discussion
15:18:32 <kgriffs> first, is which types of work items benefit from formal specs
15:19:24 <kgriffs> second, when you go to write that spec, what level of detail should go into it?
15:20:09 <malini> kgriffs: can we just leave it to the implementor to decide when to write a spec & what shud go in it?
15:20:36 <malini> the person who does the implementation cud write a spec to solicit feedback
15:20:49 <malini> or document why something was done in a specific way
15:20:50 <kgriffs> malini: i think we could give them a lot of flexibility, but I would like to have a page on our wiki (contributor's guide) with some basic guidelines
15:21:27 <kgriffs> anyone can write a wiki page today and link to a bp. the difference with this new process is it goes through formal review
15:21:45 <malini> we will also need some basic stuff done to enable using specs
15:21:50 <vkmc> if we don't provide some basic guidelines we will end up reviewing the way specs has been written instead of focusing on the spec
15:21:51 <malini> add a new github repo etc
15:21:55 <alcabrera> I like the idea of providing guidelines
15:22:03 <Obulpathi> +1 for guidelines
15:22:29 <malini> As a −1 for how to write guidelines, we will end up mandating stuff which wont make sense in each situation
15:22:50 <malini> My idea behind spec is solicit feedback early on, when you are not sure how to implement
15:22:54 <kgriffs> ok, maybe before we forget about it, can someone create a placeholder page on the wiki under "contributor guide"? #link https://wiki.openstack.org/wiki/Marconi
15:23:00 <tjanczuk> Generally speaking I'd rather be reviewing code than specs. For most changes whatever English one puts in the code submission is adequate as a spec.
15:23:10 <vkmc> hm.. thats true
15:23:39 <malini> the whole spec thing sounds uncomfortably similar to detailed design docs
15:23:55 <malini> I wud rather us not have DD for every case
15:23:55 <tjanczuk> Death by waterfall
15:23:57 <kgriffs> yeah...
15:24:01 <kgriffs> hmmm.
15:24:14 <alcabrera> I agree with malini -- if we do anything spec-like, we must tread with caution
15:24:43 <alcabrera> if we need design discussions, the place to do that is a combination of the ML, IRC, and meetings
15:24:43 <Obulpathi> it does sound like design doc to me
15:25:10 <alcabrera> a spec goes stale quickly for new ideas, so is only of value for things that have solidified
15:25:26 <alcabrera> or have some promise of staying stable
15:25:32 <alcabrera> along the lines of semantic versioning
15:25:35 <kgriffs> the goal i think is to have a page to summarize those discussions to act as memory pegs and call out stuff that needs to be followed up on (TBD items)
15:26:08 <malini> kgriffs: +1
15:26:09 <alcabrera> kgriffs: do you think we could achieve such a thing with wikis?
15:26:14 <kgriffs> if we can find a way to do that more consistently with our bp's, i don't think we need the specs process at the moment, at least
15:26:19 <alcabrera> kgriffs: +1
15:26:37 <malini> Lets just revisit using specs  @ K or a future release
15:26:44 <alcabrera> malini: agreed
15:26:48 <kgriffs> I mean, we already do a fair job of it between wiki (marconi/specs/my-bp-name-here) and etherpad
15:26:59 <alcabrera> kgriffs: oh yeah, etherpad too!
15:27:14 <malini> I think it makes sense for other teams working in diff TZ
15:27:21 <kgriffs> maybe we can think about shoring that up since it already seems to work pretty well, and revisit specs another time
15:27:33 <tjanczuk> folks, I need to run in a few minutes, could we just summarize quickly the AMQP status next?
15:27:36 <malini> since flaper87 conveniently works in all TZ, we are covered for now ;)
15:27:45 <alcabrera> haha
15:27:45 <kgriffs> heh
15:27:48 <Obulpathi> lol
15:28:08 <alcabrera> tjanczuk: sounds like a good idea
15:28:10 <kgriffs> ok, so let's do a vote next meeting about specs, and think about ways to be a little more consistent about using wiki specs
15:28:11 <alcabrera> amqp next?
15:28:24 <kgriffs> #action kgriffs to hold vote on specs next meeting
15:28:33 <kgriffs> #topic AMQP driver
15:29:07 <tjanczuk> I've been out for the last week+, I wonder if any progress code or decision-wise has been made on AMQP?
15:29:20 <kgriffs> alcabrera, vkmc?
15:29:24 <kgriffs> flaper87?
15:29:29 <vkmc> tjanczuk, I'm working on adding the support for AMQP
15:29:36 <vkmc> so... we are going for AMQP 1.0
15:29:38 <malini> gtg now
15:29:49 <vkmc> at least, as a first step into it
15:29:54 <kgriffs> malini: thanks! o/
15:30:01 <alcabrera> malini: take care!
15:30:13 <vkmc> maybe we could add support for other AMQP versions in the future
15:30:24 <vkmc> malini, ttyl! :) o/
15:31:02 <vkmc> the main blocker with the implementation of this driver is that the python library for qpid-proton is not available yet
15:31:04 <tjanczuk> We had some discussions about this last time I was here. The gist is I am happy to write Rabbit support (AMQP 0.9). In fact I am doing it this week. The question is, can this be taken into Marconi when all is done?
15:31:33 <tjanczuk> Rabbit has excellent Python library that is ready to go today.
15:32:03 <vkmc> ok, but that is a driver for Rabbit
15:32:04 <vkmc> not for AMQP
15:32:26 <tjanczuk> Yes, this is the driver for Rabbit (the most popular AMQP implementation out there)
15:33:04 <tjanczuk> Besides, AMQP is a red herring here. I care about Rabbit not AMQP. I could as well use MQTT to talk to Rabbit if we choose so.
15:33:13 <alcabrera> so, I feel like this is a question of legacy, and also about what we are willing to fit in the marconi repository
15:33:24 <vkmc> of course, but right now we are focusing on flexibility
15:33:38 <vkmc> adding a driver for AMQP allows us to be broker independent
15:33:45 <alcabrera> on the side of legacy, it is my understanding that 0.9.1 is important to a lot of people, even though 1.0 is the target for newer implementattions
15:34:27 <alcabrera> I say this as an AMQP outsider, so my view might be skewed -- the ML can confirm this better than I
15:34:31 <kgriffs> I think we may just need to bite the bullet and do two drivers, one for each
15:34:35 <vkmc> that would be the first step... later on, we could discuss adding a Rabbit driver to cover AMPQ < 1.0
15:34:53 <alcabrera> I'm happy with the idea of going double-driver in-tree
15:35:07 <alcabrera> given that we have two eager volunteers: vkmc and tjanczuk
15:35:26 <kgriffs> From what I understand, the Rabbit folks would be happy to prioritize their 1.0 support if they see enough demand for it, but I suspect it will be 1-2 years for that to happen
15:35:31 <alcabrera> how do you all feel about this?
15:35:54 <tjanczuk> Rabbit and 1.0 is pipe dream IMO.
15:35:59 <kgriffs> i'd basically call it "RabbitMQ driver" and "AMQP 1.0" driver.
15:36:05 <kgriffs> I'd be fine with having both in-tree
15:36:08 <tjanczuk> kgriffs: +1
15:36:08 <vkmc> alcabrera, +1
15:36:11 <Obulpathi> +1
15:36:18 <tjanczuk> So, if I write a Rabbit driver, can we take it in?
15:36:22 <alcabrera> yes
15:36:41 <kgriffs> tjanczuk: yes, there is the risk that Rabbit will never to 1.0, but if they do we can deprecate the 0.9 driver at that point.
15:37:01 <tjanczuk> Excellent, sounds like we are on the same page. Now I need to drive my kids to school ;)
15:37:16 <tjanczuk> I will be back on openstack-marconi later in the day.
15:37:19 <alcabrera> tjanczuk: take care, and thanks for joining in
15:37:19 <vkmc> sounds good since AMQP < 1.0 and AMQP 1.0 are two different protocols
15:37:40 <vkmc> tjanczuk, o/ ttyl!
15:37:51 <kgriffs> tjanczuk, vkmc: keep the team updated on what parts of the API can be supported, and which cannot.
15:38:15 <kgriffs> we have a little freedom with 1.1, and lots of freedom in 2.0 to make changes if needed
15:38:16 <Obulpathi> tjanczuk: take care!
15:38:21 <vkmc> kgriffs, will do, in fact I have some ideas to discuss after the meeting
15:38:25 <kgriffs> kk
15:38:28 <alcabrera> cool
15:39:16 <alcabrera> any other thoughts on the amqp thread?
15:40:04 <kgriffs> #topic Healthier Community: Let's Adopt a Code of Conduct
15:40:09 <kgriffs> alcabrera?
15:40:19 <alcabrera> yup!
15:40:32 <alcabrera> so here's the situation
15:40:41 <alcabrera> and it ranges outside of marconi, though I wanted to start the discussion here
15:41:02 <alcabrera> openstack's code of conduct is lacking in several ways
15:41:08 <alcabrera> it addresses many of the work related issues
15:41:19 <alcabrera> but does not cover a lot of the social interactions that happen
15:41:26 <alcabrera> lemme grab that link
15:41:40 <alcabrera> #link http://www.openstack.org/legal/community-code-of-conduct/
15:42:00 <alcabrera> the only items that discuss interactions between people, are 2) and 4)
15:42:14 <alcabrera> "Be respectful", and "If we disagree, consult others"
15:42:23 <alcabrera> neither detail what is and isn't acceptable behavior
15:42:35 <alcabrera> and leave it to general interpretation
15:42:43 <alcabrera> a solid code of conduct needs 4 things, as per
15:42:45 <alcabrera> #link http://www.ashedryden.com/blog/codes-of-conduct-101-faq
15:43:07 <alcabrera> the very first section in that link summarizes those requirements
15:43:31 <alcabrera> and one more problem, aside from that
15:43:45 <alcabrera> is that the openstack CoC does not make it clear who to contact if something does come up
15:44:04 <alcabrera> it makes mention of the TC and UC, but I contend that this is not enough
15:44:10 <kgriffs> that's a big one
15:44:15 <kgriffs> accountability is vital
15:44:19 <alcabrera> yes!
15:45:02 <alcabrera> codes of conduct are crucial for growing a healthty community
15:45:12 <alcabrera> and I'd like to see openstack do better in this regard
15:45:23 <cpallares> Yep, especially one growing and changing.
15:45:32 <alcabrera> what do you all think? :)
15:45:57 <kgriffs> I think the current code of conduct is too often ignored.
15:46:01 <Obulpathi> we should submit a feedback ...
15:46:09 <vkmc> you are right that there are vital parts missing on the current code
15:46:17 <vkmc> and yeah... agree with kgriffs
15:46:26 <kgriffs> however
15:46:29 <Obulpathi> asking them to update on the issues .. especially whom to contact when something is wrong
15:46:39 <vkmc> +1 Obulpathi
15:46:44 <kgriffs> i did see some positive signs at the conference that people are becoming more cognizant of this topic
15:47:09 <kgriffs> ...and supportive of making it better
15:47:22 <alcabrera> good to hear
15:47:42 <alcabrera> I like Obulpathi's suggestions - we need action
15:47:44 <kgriffs> however, the movement will need some care and feeding for it to bear fruit
15:47:59 <alcabrera> agreed, kgriffs.
15:48:26 <alcabrera> it is no simple matter, because we need a whole lot of (4) from ashedryden's faq
15:48:38 <alcabrera> Training and reference materials from those that would moderate the community
15:48:39 <vkmc> we also add in the code that people should not have a defensive
15:48:45 <Obulpathi> we also go through CoC for Deabian, Linux, Python and see how they are dealing with these issues
15:48:56 <cpallares> Obulpathi: +1 :)
15:49:19 <cpallares> I think alcabrera had some good suggestions, like the CoC from the Rust community.
15:49:25 <alcabrera> #link http://www.ashedryden.com/blog/codes-of-conduct-101-faq#coc101examples
15:49:29 <alcabrera> good examples ^^
15:49:42 * Obulpathi looking into it
15:50:01 <alcabrera> cpallares: and yeah, the Rust one is great, too!
15:50:14 <kgriffs> alcabrera: Jesse Noller and Alex Gaynor may be good allies here. I think OpenStack can learn from the broader Python community.
15:50:28 <alcabrera> kgriffs: agreed
15:50:41 <kgriffs> I was super impressed by the esprit de corps at PyCon Montreal, for example
15:50:52 <alcabrera> #link http://jessenoller.com/blog/2012/12/7/the-code-of-conduct
15:50:52 <vkmc> s/we also add in the code that people should not have a defensive/we could also add in the code that people shouldn't have a defensive behaviour... having good faith is important too
15:51:30 <alcabrera> vkmc: good point. these conversations can make people uncomfortable. it takes a bit to navigate this space
15:52:17 <alcabrera> so kgriffs made a great point earlier, that even our current CoC is ignored
15:52:52 <alcabrera> we need to understand the need for moderators, and in the interim, I think team-core members should serve as those that would moderate discussions
15:53:05 <kgriffs> saw this engraved on a wall in Atlanta: We rise in glory as we sink in pride." (Andrew Young).
15:53:36 <kgriffs> </random>
15:54:04 <alcabrera> what do you all think of having core serve as moderators for now?
15:54:08 <alcabrera> **serving
15:54:30 <kgriffs> makes a lot of sense for core reviewers to lead by example, as well as be moderators
15:55:03 <vkmc> +1 alcabrera
15:55:17 <alcabrera> cool
15:55:37 <vkmc> core devs not only know about the code, but they also know the community :)
15:55:58 <prashanthr_> vkmc : ha ha nice point :)
15:56:05 <kgriffs> moderators should keep in mind that often people don't realize that the way they are coming across is not constructive. i suppose even the very act of moderating will need to follow the CoC. :D
15:56:23 <alcabrera> kgriffs: definitely! it's not easy! :)
15:56:46 <alcabrera> I speak with experience moderating an IRC community on that point
15:57:17 <alcabrera> I'll take some next actions on this
15:57:34 <cpallares> Perhaps, we should also add review/suggestions etiquette to the CoC, such as if your comment is not constructive or adding to the argument...
15:58:10 <alcabrera> cpallares: good thought!
15:58:21 <alcabrera> I think there might something like that I once saw in the OS wiki
15:58:25 <alcabrera> but yeah
15:58:35 <alcabrera> that needs to be closer to the CoC, or at least linked
15:58:38 <cpallares> That would be nice for the mailing list too.
15:59:16 <alcabrera> I'll figure out who handles CoC things for next week
15:59:17 <kgriffs> ok folks, we are short on time
15:59:21 <alcabrera> and submit feedback
15:59:23 <kgriffs> #topic open discussion
15:59:44 <alcabrera> thanks all for listening and sharing feedback!
15:59:52 <kgriffs> #action megan_w to check trademarks for our shortlist of names
16:00:16 <kgriffs> #endmeeting