16:07:05 <salv-orlando> #startmeeting api wg
16:07:06 <openstack> Meeting started Thu Nov 20 16:07:05 2014 UTC and is due to finish in 60 minutes.  The chair is salv-orlando. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:07:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:07:11 <openstack> The meeting name has been set to 'api_wg'
16:07:53 <salv-orlando> today’s agenda: https://wiki.openstack.org/wiki/Meetings/API-WG
16:08:39 <salv-orlando> am I doing a meeting with myself only?
16:08:57 <elmiko> i hope not
16:08:59 <eglynn> salv-orlando: I'm here too
16:09:02 <dtroyer> o/
16:09:02 <ryansb> I don't think so
16:09:13 <ycombinator_> o/
16:09:56 <eglynn> on https://wiki.openstack.org/wiki/API_Working_Group#Members I'm wondering about the proposed cut-off of Nov 15th
16:10:21 <eglynn> i.e. whether this should be extended to allow laggards to join up and get a vote
16:10:23 <salv-orlando> eglynn: membership cutoff?
16:10:43 <elmiko> eglynn: i think we should definitely extend to allow more folks with interest
16:10:51 <eglynn> salv-orlando: https://review.openstack.org/#/c/131358/5/doc/source/process.rst line 41
16:11:03 <eglynn> elmiko: ++
16:11:22 <dtroyer> so pick another arbitrary date?
16:11:38 <salv-orlando> I tend to think membership should follow the same processes a getting core status
16:11:45 <elmiko> dtroyer: how about by the end of the first point release for kilo?
16:12:02 <eglynn> salv-orlando: currently it's pure self-selection, amiright?
16:12:07 <dtroyer> salv-orlando: core seems a high bar, maybe ATC status?
16:12:18 <elmiko> eglynn: that was my impression
16:12:21 <salv-orlando> dtroyer: sorry I did not meant that one has to be core
16:12:42 <salv-orlando> dtroyer: I meant membership should be granted/revoked using the same principle as the core teams
16:12:43 <dtroyer> elmiko: I do like tying it to part of the release cycle, or a certain time following the summit, as that's probably where the bulk of new interest will come
16:12:58 <eglynn> elmiko: i.e. the kilo-1 date? i.e. Dec 18th ... seems like fair notice
16:13:00 <dtroyer> salv-orlando: understood, but that is still a high bar
16:13:11 <ryansb> I think self-selection with recommended core status is a good system
16:13:11 <salv-orlando> and therefore the group should always be open to accept new members, and kick off inactive members
16:13:16 <salv-orlando> sorry not kick off, kick out
16:13:26 <salv-orlando> phrasal verbs, I’ll never get them right
16:13:27 <adrian_otto> o/
16:13:44 <dtroyer> maybe use review counts as a threshold?
16:13:54 <dtroyer> no reviews == not participating
16:14:03 <salv-orlando> dtroyer: that is a good idea. Still with human oversight rather than automated
16:14:17 <dtroyer> sure, but having at least one metric should be helpful
16:14:24 <salv-orlando> dtroyer: makes sense to me
16:14:25 <eglynn> dtroyer: yep, good to a first approximation at least
16:14:32 <elmiko> i think it would be nice to see folks who are interested either reviewing or showing up to meetings
16:15:29 <dtroyer> is the notion that there is a fixed membership for the release cycle part of what was intended there?
16:15:29 <eglynn> unfortunately no api-wg stats on http://stackalytics.com
16:16:13 <eglynn> I don't know, but the process seems to involve setting the bar at 80% of the votes
16:16:13 <dtroyer> actually, maybe that is only for the first cycle, during L we can look at the history fro Kilo
16:16:35 <salv-orlando> eglynn: that can be sorted fairly easily I think. stackalytics I think uses russellb reviewstats code, I recall it was trivial to add new repos
16:16:36 <elmiko> dtroyer: i thought the intent was to have a list of people who had early committed to the goals of the wg, and use that list as the first group of "core", although i hate to say that, members
16:17:00 <russellb> salv-orlando: nope, stackalytics is separate
16:17:15 <russellb> there is a file in the stackalytics repo you have to hack to add a project i think
16:17:17 <salv-orlando> russellb: ok. Then they’ve copied your idea and you should sue them!
16:17:24 <russellb> :)
16:17:31 <russellb> they made it prettier at least
16:17:32 <salv-orlando> russellb: so it’s not that different from reviewstats
16:17:39 <russellb> but reimplemented
16:18:53 <eglynn> #action eglynn propose stackalytics patch to generate api-wg review stats
16:19:41 <salv-orlando> great. Regarding cut off date for membership, if this is a measure for this release cycle only, I am ok with that. In any case I have no strong opinion
16:19:56 <salv-orlando> and also it’s not like my opinion counts that much ;)
16:20:26 <elmiko> salv-orlando: it counts as much as the rest of our +1s ;)
16:21:36 <salv-orlando> As apparently I am chairing this meeting, I have now to ask you if we have consensus or if we want to go back to the ml
16:21:39 <eglynn> salv-orlando: I'm fine with a cut-off also if punted into the future by a few weeks and clearly signalled on the ML
16:22:40 <salv-orlando> as jaypipes, cyeoh, and everett are not part of the meeting I will follow up the discussion on the maling list and move on with the next topic
16:22:44 <elmiko> aside from consensus here, it sounds like we need a patch to the https://review.openstack.org/#/c/131358/5/doc/source/process.rst review
16:23:02 <jaypipes> salv-orlando: thx man, sorry I can't participate right now :(
16:23:46 <salv-orlando> #info decision on membership cut-off date and process deferred to mailing list
16:24:19 <eglynn> elmiko: yep if no one objects on the ML to kilo-1 as the new date, that could be rolled into the next version of that patchset
16:24:35 <elmiko> eglynn: i'm gonna add a comment to that review as well
16:24:42 <eglynn> elmiko: cool, thanks!
16:25:19 <salv-orlando> #topic API impact reviews
16:25:24 <adrian_otto> sorry if I missed it earlier, but is there a link to this gerrit review queue you can share?
16:25:44 <salv-orlando> https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
16:26:07 <salv-orlando> adrian_otto: This is the gerrit review list for spec with an api impact flag
16:26:17 <dtroyer> adrian_otto: the overall gerrit queue is at https://review.openstack.org/#/q/project:openstack/api-wg,n,z
16:26:36 <adrian_otto> tx
16:27:49 <salv-orlando> any comment on specs with API impact flag?
16:28:38 <adrian_otto> how will API WG members become aware of reviews with that flag set?
16:28:56 <ryansb> adrian_otto: there's a gerrit query
16:29:00 <eglynn> manually running that query?
16:29:09 <eglynn> yeap, that's what I assumed
16:29:13 <ryansb> https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
16:29:20 <adrian_otto> what about a system by which we can learn about them passively?
16:29:45 <eglynn> so should we concentrating on first creating the guidelines, as opposed to applying them to APIImpact reviews?
16:29:47 <ryansb> how would you want that to work. Do you just want an email every X days with a rollup of apiimpact reviews?
16:29:47 <adrian_otto> thanks ryansb
16:29:58 <elmiko> i have also been telling the members of our project(Sahara) that they should post to the ML with [api] to request more eyeballs
16:30:02 <adrian_otto> something like that would be fine.
16:30:27 <adrian_otto> I worry that we are focusing in our various areas of interest, and that important issues even properly flagged might not be noticed
16:30:54 <elmiko> adrian_otto: good concern, at the same time though we aren't trying to create a gating process through the api-wg
16:31:14 <adrian_otto> Agreed, I am not suggesting a gate
16:31:17 <elmiko> i think it's important for the individual projects to take initiative in contacting the wg for help
16:31:18 <dtroyer> eglynn: I'd say yes, but getting acquainted with the reviews out there now is useful to see where the current churn is and will help get the right people involved sooner.
16:31:37 <salv-orlando> I think even without guidelines the api wg team should strive to look at these apiimpact specs and make sure we don’t end with two projects doing the same thing in two different ways
16:31:51 <elmiko> salv-orlando: +1
16:32:27 <elmiko> i really like ryansb's idea of posting to the ML every X days with a list of reviews
16:32:39 <adrian_otto> if part of our role was to act like a bird dog in situations where the guidelines are totally missed… perhaps that could result in a good outcome
16:33:04 <elmiko> agreed
16:33:05 <adrian_otto> we can use a relatively high value of X to start with… maybe 7?
16:33:13 <ryansb> Not sure if automatic mail to the whole ML is a great idea
16:33:23 <adrian_otto> something you can opt in to?
16:33:29 <ryansb> Much rather have folks sign up (maybe to another ML?)
16:33:52 <elmiko> ryansb: that makes sense
16:33:57 <ryansb> I think this is bikeshedding though, so can we take this to openstack-dev after the meeting?
16:34:11 <elmiko> will it be too burdensome for infra to create/manage one more ML?
16:34:14 <salv-orlando> I have a script that reminds me everyday of the reviews I should do, tells me if somebody updated that review, and also tells me what to review according to the day of the week
16:34:20 <elmiko> ryansb: yea
16:34:27 <salv-orlando> so I don’t think we need any ml… there’s also a tool called gerrymander
16:34:35 <salv-orlando> which pretty much does exactly this
16:35:39 <ryansb> salv-orlando: ah, I'd forgotten gerrymander. Would you be able to share your script?
16:36:37 <salv-orlando> it’s somewhere on github.com/salv-orlando
16:37:13 <adrian_otto> so if we are lost in the bike shed, please lead us back to the house
16:37:41 <ryansb> I'll scavenge later. Let's move on. The next thing on the agenda seems to be https://review.openstack.org/#/c/131358/5
16:38:16 <salv-orlando> #topic process for merging guideline changes
16:38:58 <eglynn> sounds a bit heavyweight TBH, all that voting
16:39:32 <eglynn> and the TC approval would give me pause also
16:39:38 <salv-orlando> I think point #2 sums up fairly well the concept of lazy consensus. But I would add that -1s for spelling errors or grammar corrections can be ignored
16:39:50 <eglynn> (seeing as TC seem to want to get out of the business of blessing things)
16:40:28 <elmiko> eglynn: i dunno, if we are talking about guidelines for all projects i tend towards the more conservative approach. but i'm curious to hear alternative ideas.
16:41:33 <eglynn> elmiko: if the consensus is that the TC will actively engage and either approve or give constructive feedback, then cool
16:42:05 <elmiko> eglynn: +2 that would be awesome. i agree about not just using them as a blessing operation for the guidelines.
16:42:08 <salv-orlando> eglynn: I don’t know… if the TC wants to be in the business of operators’ happiness maybe they should have a say on API guidelines. Or on other hand, they can trust the API wg
16:42:09 <ryansb> I think that's a lot to ask of the tc. A veto system would probably be more workable
16:42:19 <salv-orlando> ryansb: that too is not such a bad idea
16:42:19 <ryansb> (for guidelines)
16:42:35 <elmiko> ryansb: i think it would need to be veto with explanation though, not just a blanket
16:42:39 <salv-orlando> like the TC would be able to stop something when they think it’s a terrible idea
16:42:52 <salv-orlando> elmiko: yes they would not be like the US at the UN
16:42:55 <eglynn> salv-orlando: yep, I think they should just trust the WG as the "domain experts"
16:43:07 <elmiko> salv-orlando: lol, true that ;)
16:43:23 <eglynn> ryansb: yep, silence means consent ... I like it! :)
16:43:30 <dtroyer> I think the blessing from the TC would be of the form "WG is doing good work, we like that" rather than release-level approval
16:43:32 <adrian_otto> are we striving for unanimity in voting? Why?
16:43:45 <dtroyer> eglynn: ++
16:44:17 <salv-orlando> ok so what can we put as action items or info items for this topic?
16:44:19 <elmiko> adrian_otto: according to the review we are striving for 80% approval
16:44:35 <eglynn> adrian_otto: coz we, as a community, value consensus ... though perhaps in this case, we really do need to be opinionated?
16:44:53 <adrian_otto> this seems more complicated than it needs to be
16:44:55 <ryansb> dtroyer: I'm not in the business of saying how TC should operate, but I do think that asking for a lot of approvals/supervision isn't a fair demand on them
16:45:23 <elmiko> adrian_otto: maybe, what would you like see for approval process?
16:45:36 <dtroyer> ryansb: exactly, they have been actively trying to back away from that sort of thing (see defcore)
16:46:06 <salv-orlando> ryansb: I think dtroyer eas just saying that the TC will prefer to delegate the task of blessing guidelines to the api group
16:46:07 <elmiko> dtroyer, ryansb, doesn't that just add weight to the silence/veto-with-explanation option?
16:47:03 <eglynn> the graduation debates on say zaqar would give me pause on baking pass/fail release-level TC approval into the workflow
16:47:08 <eglynn> elmiko: ++
16:47:25 <ryansb> to be clear, I'm totally in favor of silence-or-veto
16:47:37 <eglynn> ryansb: cool
16:47:48 <salv-orlando> also, about this veto thing… adding it as part of the process is ok, but in any case even if we did not do that
16:48:02 <elmiko> cool, sounds like we need another patch to that review
16:48:14 <salv-orlando> it’s not like if somebody like monty, for instance, came and told us: this is terrible, we’d ignore him/her because they’re not part of the group
16:48:38 <dtroyer> elmiko: implicitly, yes.  From what I've seen though is that if TC is unhappy with something they'll either work individually to address the issue first
16:49:35 <elmiko> salv-orlando: good point, but in that case i would still expect changes to percolate through the review process
16:49:52 <salv-orlando> make sense to me.
16:50:20 <elmiko> dtroyer: good info, i haven't worked directly with TC so i'm a little blind in terms of how they operate when something is important to them
16:50:42 <elmiko> i just like the idea of codifying the process for transparency sake
16:50:47 <salv-orlando> so can we be cool and agree that we welcome contribution and feedback from the TC, but we probably think it will be too much of a workload for them to have their approval as a prerequisite for every guideline
16:50:59 <elmiko> salv-orlando: +1
16:51:09 <salv-orlando> and that the api wg will however accepts vetos (with explanations) from the TC?
16:51:28 <eglynn> the important thing is for us not to get into a situation whereby the TC turn around to us at the end of kilo and say: "wait a minute, that's not what we were expecting at all!"
16:51:48 <dtroyer> salv-orlando: I'd suggest just removing line 49.  the WG relationship to the TC should be described somewhere (I haven't looked) and that ought to cover this
16:51:50 <eglynn> so we should build a "timely feedback" requirement into the silence-or-veto IMO
16:52:06 <elmiko> eglynn: yea, that would be bad. but how do we increase their involvement without either loading them up to much, or making them the gate for all changes?
16:52:29 <eglynn> elmiko: maybe milestone checkpoints?
16:52:38 <elmiko> eglynn: i like that
16:52:48 <salv-orlando> anybody disagrees with dtroyer’s observation?
16:52:50 <dtroyer> elmiko: I think some time before a release we get n the TC agenda and say "this is our RC, comments?"
16:53:16 <eglynn> dtroyer: +1 on removing
16:53:26 <adrian_otto> time check
16:53:36 <salv-orlando> #info attendees suggest to remove line 49 from https://review.openstack.org/#/c/131358/5/doc/source/process.rst (mandatory tc approval)
16:53:43 <elmiko> dtroyer: +1 to remove and clarify elsewhere
16:53:45 <adrian_otto> +1
16:53:53 <adrian_otto> I voted in Gerrit accordingly
16:53:59 <eglynn> #info stackalytics patch: https://review.openstack.org/136046
16:54:05 <salv-orlando> #info attendees also suggest to clarify TC relationship with API WG elsewhere
16:54:10 <elmiko> dtroyer: and yea, i like the idea of giving them a time window in which we ask if they are cool with everything
16:54:11 <salv-orlando> thanks eglynn
16:54:11 <adrian_otto> plus grammar is spelled wrong.
16:54:35 <adrian_otto> unless that's a spelling from a language I don't speak
16:55:19 <salv-orlando> 5 minutes to go
16:55:48 <salv-orlando> #topic open discussion
16:56:10 <salv-orlando> this is where one usually brings up crazy ideas or rants about random things...
16:56:18 <dtroyer> https://review.openstack.org/#/c/131640/ was on the agenda, seems uncontroversial, should we #info stamp it?
16:56:33 <elmiko> just as a follow-up from summit, i have been making some progress on implementing a swagger generator for sahara. i'm hoping to have a poc within a few weeks
16:58:13 <salv-orlando> dtroyer, yes if nobody disagrees with that. I have to admit I wilfully skipped it.
16:58:30 <dtroyer> salv-orlando: np
17:00:23 <salv-orlando> time’s up!
17:00:30 <eglynn> thanks folks for a productive meeting!
17:00:41 <salv-orlando> #info no attendees disagrees with approving 131640
17:00:48 <salv-orlando> thanks for your time and goodbye
17:00:52 <salv-orlando> #endmeeting