18:00:07 <SlickNik> #startmeeting trove
18:00:08 <openstack> Meeting started Wed May  7 18:00:07 2014 UTC and is due to finish in 60 minutes.  The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:11 <openstack> The meeting name has been set to 'trove'
18:00:41 <kevinconway> o/
18:00:46 <glucas> o/
18:00:46 <amrith> \0
18:00:52 <yogesh_> o/
18:00:52 <peterstac> \o
18:01:00 <iccha1> o/
18:01:01 <abramley> 0/
18:01:02 <mattgriffin> o/
18:01:06 <mat-lowery> o/
18:01:19 <dougshelley66> o/
18:01:22 <robertmyers> o/
18:01:22 <cweid> o/
18:01:27 <imsplitbit> o/
18:01:33 <esmute> 0/
18:02:08 <SlickNik> Agenda:
18:02:10 <SlickNik> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
18:02:27 <vipul> o/
18:02:42 <SlickNik> Last meeting logs:
18:02:45 <SlickNik> #link http://eavesdrop.openstack.org/meetings/trove/2014/trove.2014-04-30-18.02.html
18:03:01 <denis_makogon> o/
18:03:16 <SlickNik> #topic How do Gerrit changes get approved?
18:03:19 <cp16net> |o|
18:03:30 <kevinconway> >o<
18:03:30 <SlickNik> mat-lowery: take it away
18:03:36 <esp> o/
18:03:36 <esmute> i am curious about this too
18:03:37 <esmute> :P
18:03:41 <mat-lowery> Goal: To clarify the Gerrit change approval process used by Trove core (for the benefit of core and non-core).
18:04:07 <mat-lowery> Should I just reproduce the text from the agenda?
18:04:20 <mat-lowery> All of my arguments are there. :)
18:04:38 <SlickNik> That's not necessary.
18:04:47 <juice> o/
18:05:10 <SlickNik> I was giving this a lot of thought this week.
18:05:19 <SlickNik> And a couple of things that made sense to me.
18:05:32 <mat-lowery> Does Trove core use a systematic process of reviews and approvals to prevent starvation? Ultimate goal: Reduce time between submittal and merge.
18:05:58 <SlickNik> It's good idea to align on a process to prioritize and review changes
18:06:28 <SlickNik> But I was looking at the reviewday tool
18:06:32 <SlickNik> #link  http://status.openstack.org/reviews/
18:06:57 <cp16net> i'd like to be able to just see the reviews for the projects i care about in that review day tool
18:07:01 <cp16net> instead of EVERY project
18:07:12 <kevinconway> project:openstack-trove in the search bar?
18:07:13 <cp16net> doesnt seem to have a anchor you can use either
18:07:14 <vipul> I don't think there is a common tool / process that core uses.  It might be good to pick one that we agree to
18:07:17 <SlickNik> A lot of the top reviews there are actually waiting on changes from the submitter.
18:07:21 <mat-lowery> cp16net: You can run it locally but it takes forever.
18:07:36 <kevinconway> oh… no more search bar
18:07:47 <vipul> SlickNik: yea it's surprising so many with -1 and -2 show up at the top
18:07:55 <cp16net> kevinconway: this is an entirely differnt tool for reviews
18:08:33 <mat-lowery> ReviewDay uses a scoring algorithm based on Launchpad bug priority and age of Gerrit change.
18:08:35 <amrith> review.openstack.org supports search customization.
18:08:37 <vipul> i've often used: https://launchpad.net/trove/+milestone/juno-1 as a way to pick higher priority bugs/bps to focus on
18:08:40 <amrith> my url is https://review.openstack.org/#/q/-label:CodeReview-2+AND+-label:+Verified-1+AND+status:open+AND+is:watched,n,z
18:09:35 <amrith> that gives you just the projects taht you watch
18:09:40 <amrith> and you can set in your lp profile
18:09:49 <iccha1> I think it might be good to review some of the review stats at every meeting to see how trove is doing . This is outdated, but if you look at http://russellbryant.net/openstack-stats/trove-reviewers-30.txt, it has some useful metrics like changes abandoned in the last 30 days, or queue growth in last 30 days
18:10:03 <SlickNik> mat-lowery: Also a lot of reviews on reviewday that haven't yet passed unit-tests.
18:10:21 <SlickNik> Doesn't make sense prioritizing some of those.
18:10:59 <amrith> SlickNik, if you look at the URL I posted, it eliminates anything with a -2 or fails verified
18:11:00 <denis_makogon> http://www.stackalytics.com/report/reviews/trove-group/open
18:11:02 <amrith> that may be what you want
18:11:07 <mat-lowery> SlickNik: Understood. I'm not selling ReviewDay but rather a prioritized queue (based on something that makes sense) that every core (and non-core) can/must use.
18:11:24 <SlickNik> iccha1: Yes, the reviewstats tool hasn't been run since the gerrit upgrade. :(
18:11:33 <SlickNik> mat-lowery: Got it.
18:11:34 <iccha1> i like the query amrith , thats something which used in glance too.
18:12:07 <SlickNik> So sdague has a couple of good blog articles about this too
18:12:13 <amrith> Also for those who want to customize their search, this page is helpful. #link https://review.openstack.org/Documentation/user-search.html
18:12:25 <SlickNik> #link https://dague.net/2014/04/30/helpful-gerrit-queries-gerrit-2-8-edition/?utm_campaign=OpenStack+Now&utm_source=hs_email&utm_medium=email&utm_content=12695477&_hsenc=p2ANqtz-9twO0GbtB202VDA5wExXeBMIfQwnXdSBfuSj807F74UdfhZwJCsNKrVKI0pi-PqqRJQru8eyayQjntiU8sG1CaO4f1pA&_hsmi=12695477
18:12:44 <mat-lowery> My argument for a priority goes like this: If a priority exists, there's no need for "Hey core, please review <change>" which I find inefficient and unfair. It seems that bugging the channel for reviews is OK to some. Why?
18:13:17 <robertmyers> mat-lowery: well sometimes it is a blocking bug
18:13:28 <SlickNik> mat-lowery: I find it okay because of a couple of reasons
18:13:32 <robertmyers> so we should get eyes on it
18:13:36 <mat-lowery> robertmyers: Understood in those circumstances.
18:13:47 <mat-lowery> But otherwise, you're cutting the line. :)
18:13:59 <imsplitbit> is there necessarily a line?
18:14:01 <SlickNik> Rarely do I prioritize a review above all others based on a poke
18:14:20 <SlickNik> And it helps to get a conversation started.
18:14:25 <SnowDust> :)
18:14:32 * esp visualizes a fight at walmart
18:14:32 <juice> I think as a team we would be more efficient with a priority list
18:14:47 <juice> right now our focus is like a disco ball rather than a magnifying glass
18:14:59 <iccha1> if everyone has the same pripirty list, wont the bottom ones be starved?
18:15:02 * amrith thinks about focusing on a disco ball
18:15:07 <cp16net> yeah i am in agreement we need to be better about it
18:15:10 <esmute> juice: as we get more members and more patches, having a process with priority will help
18:15:24 <esmute> +1 juice
18:15:33 <juice> iccha1: the ones at the bottom will not stay there forever
18:15:34 * robertmyers review are on top
18:15:39 <SnowDust> iccha1 : right
18:15:40 <mat-lowery> iccha1: If the scoring is is age-influenced, then older (even low priority ones) rise to the top
18:15:44 <juice> they will actually move up because we cleared the ones the at the top
18:16:18 <juice> I think core should decide priority - we can use launchpad to set priority and all work from the same list
18:16:18 <esmute> and priority should be last (or way down) if they dont pass jenkins
18:16:29 <iccha1> +1
18:16:46 <cp16net> there are some reviews where the bp has not been approved
18:16:52 <juice> I don't know if it is feasible to come up with search criteria that will do this for us
18:17:06 <vipul> so the problem with just looking at patch age.. is that there are patches that exist for things that we have disagreement on
18:17:09 <juice> cp16net: then those reviews should have a low priority
18:17:10 <iccha1> priorities should be around - first go look at reviews you have already reviewed and folks has posted patchset on
18:17:13 <vipul> cp16net: +1
18:17:19 <SlickNik> vipul: +1
18:17:48 <juice> in fact we don't need to know the priority for all reviews
18:17:52 <esmute> vipul, in that case, the core can -2 these patches bringing them down in priortiy
18:18:01 <juice> we just need to know which ones are the top priority (e.g. top 5)
18:18:10 <juice> the rest are unprioritized
18:18:13 <esmute> i know some cores -2 patches when they need more clarity and discussions
18:18:25 <SlickNik> esmute: It's not that easy. The patch might be a good idea, but it might be −1'ed to fix some issues.
18:18:33 <SlickNik> In that case a −2 might be a bit harsh
18:18:34 <vipul> esmute: that could work.. if we ignore -2's and factor in age
18:19:21 <vipul> obviously there is isn't a simple answer here... needs a longer discussion
18:19:28 <vipul> who's going to be in ATL!?
18:19:30 <mat-lowery> So the priority queue is liked in general. Just that the scoring isn't as Trove core would like? Is that fair?
18:19:30 <dougshelley66> so i kind of made the assumption that core would be looking for reviews that are +1 under "V" and had at least 1 +1 under "CR"
18:19:35 <vipul> sounds like a good place to discuss this
18:20:09 <mat-lowery> dougshelley66: Thus my argument that -1's should not be left and then the reviewer disappears.
18:20:11 <amrith> vipul, was question re: ATL targeted at core or all?
18:20:17 <mat-lowery> That's the next point: Gerrit etiquette.
18:20:22 <vipul> anyone who wants to discuss this amrith
18:20:27 <amrith> I'll be there
18:20:31 <amrith> in ATL and to discuss this
18:20:35 <SlickNik> dougshelley66: I know that we look for +1 from Jenkins (i.e. it has to pass the unit tests), but there's no requirement for it having a +1 under CR
18:21:02 <dougshelley66> SlickNik - i wasn't saying that was a requirement, just figured that would be a trigger
18:22:14 <mat-lowery> To wrap this item up, is core going to hammer out a scoring algorithm in ATL?
18:22:14 <dougshelley66> mat-lowery right; how to enforce the policy that you can't -1 and run
18:22:23 <SlickNik> Another thing to keep in mind here is that we have some items that are just easy approves: Changes to help strings that make sense, changes to global-requirements, localization changes.
18:23:00 <mat-lowery> Perhaps number of +1's can bump the item up in score too aka easy approves.
18:23:55 <vipul> #link https://wiki.openstack.org/wiki/ReviewWorkflowTips
18:24:06 <vipul> looks like there are a number of tools available to help with this
18:24:19 <SlickNik> My personal preference is to approve those sort of changes soon, so that it doesn't affect the size of the review pipeline.
18:25:09 <mat-lowery> I'll check out all of these review tip links but the point, as juice made was to have the queue be presented to you (no work from the reviewer about a query) then work from the top
18:25:24 <denis_makogon> mat-lowery, we cant enforce contributors to post only one type of marks if patch already has N +1's
18:25:35 <cp16net> vipul: oh nice
18:25:39 <SnowDust> ok then I'll submit my patch with friends bumping it up wid their +1?
18:25:49 <cp16net> thanks for sharing those tools maybe that can help me
18:27:21 <mat-lowery> We're nitpicking a proposed algorithm. My point: At least have an algorithm.
18:27:27 <mat-lowery> And everyone follow it.
18:28:14 <mat-lowery> I will not be in ATL. Is there some kind of discussion list I should add this to? (And move on to next item.)
18:28:40 <dougshelley66> given that list of tooling that vipul provided, i assume this is a solved problem? wouldn't every project have the same issue?
18:28:58 <esmute> I am in all for having a priority-based process for review like ReviewDay. We can keep making adjustment as we need (ie improve our scoring algorythm etc)
18:29:15 <vipul> dougshelley66: i don't thnk it's a solved problem.. the tools may help pick reviews based on different criteria.. i am not sure if that's the criteria for us
18:29:36 <vipul> we should still discuss what our priority queue is made up of
18:29:42 <SlickNik> esmute: I hope we don't end up developing a review solution instead of a datastore service :)
18:29:54 <vipul> SlickNik: weren't you going to propose a 'pod session' to talk about this
18:29:57 <SlickNik> #action SlickNik to come up with a proposal on how to prioritize reviews to be discussed in ATL, and on IRC.
18:30:04 <dougshelley66> vipul: ok but i don't konw if i'm clear why all the projects couldn't tackle this issue in the same manner
18:30:05 <SlickNik> Yes, I was.
18:30:06 <kevinconway> but what about review neutrality?
18:30:20 <kevinconway> if we allow service providers to create "fast-lanes" for reviews what next?
18:30:46 <vipul> dougshelley66: good point.. i don't honestly know how other projects do it
18:31:25 <mat-lowery> May I move on to next point which is to discuss how all of us can keep (high-quality) code moving through the system?
18:31:50 <iccha1> vipul: we had the same problem in glance
18:31:55 <SlickNik> vipul: Yes, I'm working on scheduling a pod session to discuss this issue in ATL.
18:31:55 <denis_makogon> so, can we proceed to next topic?
18:32:04 <SlickNik> Stay tuned for more info regarding that.
18:32:23 <SlickNik> mat-lowery: go for it.
18:32:25 <iccha1> SlickNik: mark wash from glance had tried to take some steps with the same
18:32:57 <mat-lowery> as dougshelley66 put it succinctly: you can't -1 and run. Do we all agree? There's an obligation to respond to follow-ups.
18:33:06 <amrith> +1
18:33:10 <dougshelley66> +2
18:33:15 <dougshelley66> :)
18:33:34 <denis_makogon> mat-lowery, agreed, -1 without any reason seems invalid
18:33:34 <ramashri> +1
18:33:43 <kevinconway> what if we have committment issues?
18:33:53 <robertmyers> kevinconway: lol
18:34:08 <esp> mat-lowery: you can follow up with your reviewers right?
18:34:11 <dougshelley66> robertmyers: you are just encouraging him :)
18:34:18 <mat-lowery> denis_makogon: not without reason. leaving a -1...then the committer disagrees or needs clarification or whatever...and the original reviewer never returns
18:34:21 <amytron> dougshelley66:  +1
18:34:31 <juice> mat-lowery: what was the next point
18:34:43 <robertmyers> dougshelley66: agreed
18:35:07 <SlickNik> If running comprises not ever responding, then I agree with that sentiment. :)
18:35:34 <denis_makogon> mat-lowery, in this case, if noone followed same thoughts, -1 can be easily ignored
18:36:04 <esp> mat-lowery: my point from above is that at times if I don’t agree with a -1, I have to follow up with the review to clarify
18:36:06 <SlickNik> But this is an async process, so I'd imagine that stuff can come up between when I make a comment and when the other involved party replies.
18:36:21 <kevinconway> what do you expect from a -1 followup?
18:36:23 <SnowDust> good one denis_makogon
18:36:28 <kevinconway> pushing up new code get's rid of those
18:36:29 <SlickNik> So if it takes me, maybe a day to reply to a comment in gerrit because of this, I think that's acceptable.
18:36:44 <esp> kevinbenton: :) that works too
18:37:00 <esp> sorry ^ kevinconway
18:37:08 <mat-lowery> kevinconway: I hope you're kidding.
18:37:21 <mat-lowery> But I have seen it.
18:37:25 <mat-lowery> Or what looks like it.
18:37:26 <vipul> mat-lowery: +1 please dont' just push up a new patch set..
18:37:32 <vipul> at least reply to the comment
18:37:48 <vipul> it's insane trying to figure out if all previous reviewer comments have been addressed
18:37:49 <imsplitbit> kevinconway: +1 :)
18:37:53 <SnowDust> esp: Kevin bent on ?
18:37:58 <juice> mat-lowery: keeping clean code through the project I think was the next topic
18:38:08 <iccha1> SlickNik: I think we need metrics, how many reviews done by cores per day, non cores per day, how many patches get abandoned per day and why, etc. The question is are there enough reviews being done first, and then if yes are the right review sbeing looked at
18:38:09 <juice> I think we are on a tangent right now
18:38:09 <esp> SnowDust: yeah I didn’t get enough coffee..
18:38:18 <kevinconway> i'm not suggesting pushing up new code just to get rid of -1 votes
18:39:04 <juice> (high-quality) is what you said
18:39:05 <kevinconway> i'm just curious why -1 is such a point of contention here
18:39:15 <kevinconway> -1 is a community member saying "change this i don't like it"
18:39:23 <SlickNik> btw, I've seen some behaviour in the new gerrit that doesn't get rid of the −1 even if a new patchset is pushed up.
18:39:38 <peterstac> I have too
18:39:40 <kevinconway> but -1/+1 don't carry any great weight. you can agree or disagree. core makes the adult decisions
18:39:41 <SlickNik> So this might be a moot issue, not that review.o.o has moved to the new gerrit version.
18:39:44 <juice> kevinconway: no ones is disagreeing with -1 - the disagreement is using a -1 without comments
18:39:45 <SlickNik> now*
18:39:46 <mat-lowery> juice: My only point by adding high-quality was not to imply fast tracking code for the sake of speed. We can have good reviews and still get things merged.
18:40:32 <iccha1> i think this conversation is running in too many parallel directions :)
18:40:43 <juice> mat-lowery: sure we shouldn't sacrifice speed for quality is what you are saying
18:40:50 <esp> iccha1: +1
18:41:06 <SnowDust> esp: +1
18:41:18 <juice> whoops - other way around in my last comment
18:41:18 <kevinconway> SnowDust: -1
18:41:27 <esp> I don’t think anyone disagrees with the things being brought up
18:41:35 <SlickNik> Okay, let me try to give this some definition
18:41:40 <amrith> all: are we attempting to solve with a broad "policy" that which should be solved by individual interactions when a particular problem occurs? Is this a widely prevalent problem impacting a number of reviews? if yes, I see the point in the policy. If this is a fringe, how about core periodically do some coaching and address that way?
18:41:51 <juice> go for it slicknik - bring 'er to a close
18:42:47 <SlickNik> I don't think anyone disagrees with any of the points mentioned in the Gerrit Ettiquette section.
18:43:00 <SlickNik> #startvote No leaving -1s and then disappearing. A reviewer that leaves a -1 has an obligation to respond to follow up questions? yes, no
18:43:01 <openstack> Begin voting on: No leaving -1s and then disappearing. A reviewer that leaves a -1 has an obligation to respond to follow up questions? Valid vote options are yes, no.
18:43:02 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:43:10 <SlickNik> #vote yes
18:43:12 <mat-lowery> OK. Then if this is just a reminder of the etiquette, I'm happy
18:43:18 <amrith> #vote yes
18:43:23 <kevinconway> wait is this that you have to leave a comment or if you -1 you have to -1 every update?
18:43:23 <ramashri> #vote yes
18:43:24 <dougshelley66> #vote yes
18:43:25 <mat-lowery> #vote yes
18:43:27 <SnowDust> kevinconway : waiting for an adult decision 4 ur -1
18:43:28 <vipul> #vote yes!
18:43:28 <openstack> vipul: yes! is not a valid option. Valid options are yes, no.
18:43:37 <esp> #vote yes
18:43:41 <esmute> #vote yes
18:43:42 <denis_makogon> #vote yes
18:43:44 <cp16net> #vote yes
18:43:48 <esmute> lol too excited about this one vipul
18:43:48 <glucas> #vote yes
18:43:48 <esmute> ?
18:43:52 <juice> #vote yes
18:43:58 <SlickNik> #endvote
18:43:59 <openstack> Voted on "No leaving -1s and then disappearing. A reviewer that leaves a -1 has an obligation to respond to follow up questions?" Results are
18:44:00 <openstack> yes (11): juice, SlickNik, glucas, esp, esmute, amrith, denis_makogon, mat-lowery, cp16net, ramashri, dougshelley66
18:44:03 <SlickNik> So just as I thought.
18:44:08 <juice> :)
18:44:14 <cp16net> i think this should be obvious and its a silly vote though.
18:44:16 <denis_makogon> lol, no way )
18:44:18 <kevinconway> -1
18:44:20 <SlickNik> Are all the other ones similar, or is there a contentious issue?
18:44:28 <SlickNik> cp16net: Yes, I feel the same way.
18:44:39 <esmute> cp16net: humans by nature like winning
18:44:41 <mat-lowery> OK. So the lesson for me is to personally bug the people who are not following etiquette.
18:44:49 <iccha1> So another point is when we look at stackalytics Core team size: 5 (1.3 per core per day) reviews and Total reviewers: 31 (0.6 per reviewer per day). [http://www.stackalytics.com/report/contribution/trove-group/30] So maybe we need to just do more reviews too?
18:44:54 <mat-lowery> I tried Gerrit itself. No response.
18:44:55 <abramley> !sftp
18:44:56 <openstack> abramley: Error: "sftp" is not a valid command.
18:44:59 <SlickNik> I'm not going to start a vote on them unless someone feels a dire need to talk about one of those rules.
18:45:02 <abramley> Ooops - sorry
18:45:17 * amrith wonders why abramley is banging sftp
18:45:22 <mat-lowery> SlickNik: no need
18:45:28 <vipul> iccha1: +1 I think that's the main issue
18:45:39 <vipul> iccha1: size of core team and core team cycles spent on reviews
18:46:21 <cp16net> +1
18:46:23 <mat-lowery> more reviews off a prioritized list :)
18:46:43 <vipul> and a lack of a prioritized list :p
18:46:43 <SlickNik> iccha1: I think you bring up a good point here.
18:47:26 <SlickNik> iccha1: We need to do a better job of tracking the stats, so that we know when we are slipping or if we need to grow core to cope with the review demand.
18:47:49 <juice> cinder has similar stats
18:47:53 <juice> actually even less
18:48:03 <iccha1> SlickNik: +1 and bring it up every meeting to keep tabs on the queue
18:48:34 <mat-lowery> iccha1: +1
18:48:44 <kevinconway> iccha1: ugh. do we have to read previous meeting minutes into record too?
18:48:56 <SlickNik> #action SlickNik to look at what stats to monitor for trove review health and include it in the aforementioned "review" proposal
18:49:27 <SlickNik> I think we've beat this down for now.
18:49:33 <cp16net> i think thats a good idea to keep everyone in the know
18:49:37 <cp16net> +1
18:50:07 <SlickNik> I'm going to put something together and will discuss with folks at ATL and on IRC. So stay tuned.
18:50:25 <mat-lowery> thanks SlickNik
18:50:32 <iccha1> sounds like a plan!
18:50:37 <SlickNik> mat-lowery: Thanks for bringing it up!
18:50:45 <SlickNik> #topic Meetings next week
18:51:00 <SlickNik> So a lot of us are going to be in ATL next week for the summit.
18:51:14 <denis_makogon> yup
18:52:03 <SlickNik> So I'm canceling the two Trove meetings for next week, since there will be a lot going on.
18:52:12 <SlickNik> We'll meet again the week after that.
18:52:18 <dougshelley66> ok
18:52:18 <cp16net> sounds good
18:52:42 <SlickNik> I'll send folks reminders on email / IRC.
18:52:57 <SlickNik> I'll be on IRC on and off during the summit.
18:53:19 <cp16net> i'll be online all the time
18:53:28 <cp16net> doesnt mean i will respond tho
18:53:42 <SlickNik> So if something comes up, feel free to message the trove channel.
18:53:58 <SlickNik> That's all I had to say about that. :)
18:54:07 <SlickNik> #topic Open Discussion
18:54:21 <SlickNik> Any takers?
18:54:22 <amrith> SlickNick ... Mid-Cycle Meetup Question
18:55:04 <SlickNik> go for it
18:55:07 <amrith> SlickNik, I'm trying to get a list of attendees for the mid-cycle meetup. if you'll be attending, please either drop me a note email or pm.
18:55:26 <cp16net> word
18:55:38 <SlickNik> Sounds good.
18:55:43 <cp16net> amrith: is there a date for this?
18:55:57 <dougshelley66> aug 20-22
18:56:01 <amrith> yes, let me check. dougshelley66 may know it off top of head
18:56:04 <cp16net> awesome thanks
18:56:05 <amrith> yes, he does ;)
18:56:11 <cp16net> is there a wiki link with more info
18:56:12 <cp16net> ?
18:56:14 <amrith> location: cambridge, MA
18:56:17 <amrith> no wiki link yet
18:56:22 <cp16net> ok coo
18:56:23 <amrith> good point
18:56:33 <amrith> cp16net, coo to you too ;)
18:56:39 <cp16net> something like we had for the last one would be good
18:56:43 <vipul> amrith: you might want to do the evite thing hub_cap did
18:56:55 <vipul> that way whoever gets approved to go.. can just sign up
18:57:01 <cp16net> #action amrith make a wiki page for the midcycle meetup
18:57:12 <amrith> cp16net, add one for eventbrite as well
18:57:17 <amrith> #action that is
18:57:59 <amrith> SlickNik, ... that's it for me ...
18:58:04 <SlickNik> #action amrith to set up an eventbrite event for the mid-cycle meetup
18:58:11 <amytron> amrith:  if you have questions on how we planned the last one, let me know
18:58:12 <SlickNik> (pro-tip: anyone can do it)
18:58:22 <SlickNik> Sounds good.
18:58:25 <SlickNik> Anyone else?
18:58:25 <amrith> amytron, thx. was going to do that.
18:58:37 <amytron> SlickNik:  i made the PTL do it last time ;)
18:58:58 <amytron> but you're right, anyone can do it :)
18:59:11 <SlickNik> Okay, cool.
18:59:15 <SlickNik> #endmeeting