14:00:17 <maxamillion> #startmeeting
14:00:17 <zodbot> Meeting started Wed May 13 14:00:17 2015 UTC.  The chair is maxamillion. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:50 <maxamillion> #meetingname Fedora Infrastructure/Rel-Eng Cross-team
14:00:50 <zodbot> The meeting name has been set to 'fedora_infrastructure/rel-eng_cross-team'
14:01:06 <maxamillion> #meetingtopic Fedora Project Planning Tools Discussion
14:01:20 <stickster> o/
14:01:24 <maxamillion> stickster: \o
14:01:33 <pingou> o/
14:01:37 <pingou> sorry ó/
14:01:41 <maxamillion> #rollcall
14:01:47 <stickster> pingou: That's for your awesome hair?
14:01:47 <maxamillion> (is that a meetbot command?
14:01:48 <maxamillion> )
14:01:59 <maxamillion> it would appear not
14:02:02 <pingou> stickster: yeah, I had forgot to brush :)
14:02:04 <stickster> maxamillion: '#topic Roll call' is what I use
14:02:10 <maxamillion> #topic Roll call
14:02:29 * jkurik is here
14:02:48 * bochecha is lurking, bit busy
14:02:52 * nirik is lurking in the back, pre-coffee.
14:02:54 <stickster> maxamillion: Also, I worry that meetingname with the '/' may confuse file saving -- try '#meetingname infra-releng-crossteam'
14:03:06 <stickster> Although I guess we could just see if it breaks and fix it... but if we lose the log, ugh
14:03:10 <maxamillion> #meetingname infra-releng-crossteam
14:03:10 <zodbot> The meeting name has been set to 'infra-releng-crossteam'
14:03:14 <maxamillion> stickster: thanks
14:03:23 <maxamillion> stickster: this is the first time I've run an irc meeting :X
14:03:24 <stickster> maxamillion: No worries. The #meetingname is what's used for the actual filename on the log storage
14:03:32 <maxamillion> ahhhh
14:03:36 <maxamillion> good to know
14:03:43 <bochecha> stickster, not only, it's used for storage in the teams/ folder
14:03:51 <stickster> maxamillion: And you can feel free to #chair a bunch of people so they can help you with tagging stuff for the meeting minutes
14:03:58 <stickster> bochecha: good to know!
14:04:13 <bochecha> but there should be another set of files saved anyway in the "dump it all" folder
14:04:13 <maxamillion> #chair stickster nirik dgilmore pingou
14:04:14 <zodbot> Current chairs: dgilmore maxamillion nirik pingou stickster
14:04:41 <maxamillion> I say we give people 1 more minute to join and then I'll get moving
14:04:58 * mattdm is here
14:05:09 <maxamillion> #chair mattdm
14:05:09 <zodbot> Current chairs: dgilmore mattdm maxamillion nirik pingou stickster
14:05:17 <stickster> ha, mattdm has All The Chairs
14:05:19 <dgilmore> hola
14:05:31 <maxamillion> alright lets get going ...
14:05:35 <maxamillion> Hello everyone and welcome to the Fedora Project Proposal Planning Meeting. If everyone could take a quick couple of minutes and read over the wiki page that's been setup here, I'd appreaciate it: https://fedoraproject.org/wiki/Infrastructure/Meetings/ProjectPlanProposal
14:05:41 <maxamillion> #info https://fedoraproject.org/wiki/Infrastructure/Meetings/ProjectPlanProposal
14:06:19 * threebean is here
14:06:30 <maxamillion> threebean: welcome
14:06:38 <threebean> maxamillion: sorry for being late :)
14:06:47 <maxamillion> threebean: no worries
14:06:58 <maxamillion> Once everyone has done reading that wiki page we should all be on a somewhat similar playing field of understanding about the proposal and can discuss further.
14:07:04 * mattdm ♥s kanban
14:07:06 <maxamillion> Things I would like to accomplish in this meeting is:
14:07:11 <maxamillion> 1) Find out if this sounds like something everyone would like to see happen or if I'm just crazy. (which is totally fine if I am)
14:07:16 <maxamillion> 2) Select one of the proposed solutions to get packaged up and to a Proof of Concept in either the Fedora Cloud OpenStack environment or somewhere in the Fedora staging infrastructure.
14:07:25 <maxamillion> From there I think the scope of work can be sorted out and we would be able to move forward with something or just know that this isn't something the broader Fedora community is interested in.
14:08:04 <maxamillion> Is anyone from Docs or QA here? ... I was hoping folks from those groups would be able to join as well
14:08:30 <stickster> randomuser might be around
14:08:57 * lmacken rolls in late after his keyboard started freaking out and required a hard-reset ;(
14:09:28 <threebean> I have to admit I'm surprised we're talking about planning tools at the cross-team scope.  For some reason I thought this was more just about the releng group.
14:09:57 <threebean> heh, it's pretty clear in the fedocal description.  I must've just missed that part.
14:09:59 <stickster> threebean: I think the idea was that other groups with projects might find such tools useful, and help with them
14:10:04 <maxamillion> threebean: I'd like to propose it cross-team and if that's just insane then we can limit it back ... but my hope is that this would be something that everyone in Fedora land could benefit from
14:10:54 <maxamillion> but if other teams just have no desire for it, then I don't want to try and force people into it
14:11:14 <maxamillion> lmacken: ttomecek1: in case you didn't see -> https://fedoraproject.org/wiki/Infrastructure/Meetings/ProjectPlanProposal
14:11:24 <lmacken> yeah I saw and commented on it yesterday
14:11:32 <nirik> I'm not opposed, but would prefer to see it actually in action working in a group like releng before deciding. :) It seems pretty abstract to me at this point...
14:11:37 <mattdm> I think solving immediate problems for rel-eng is a good scope, keeping in mind possible benefits cross-project, and planning to scale as other groups see success and opt in
14:11:58 <stickster> maxamillion: Just to clarify, the goal isn't to require teams to use a set tool, but rather make it available so people can e.g. share strategies for effective work?
14:12:01 <maxamillion> lmacken: ah, +1
14:12:07 <maxamillion> stickster: correct
14:12:13 <threebean> yeah, I'm interested in possibly seeing it in place for the apps group, but I'd like to see it in practice too.
14:12:29 <mattdm> I know that both Cloud and Server WGs have talked about using a kanban board for planning, but got stuck on no one had time to effectively package up the tools
14:12:32 <maxamillion> stickster: and include them in the converations so that if they have input or concerns, it can be taken into consideration for the work to be done and/or the tooling to be selected
14:12:38 <mattdm> maxamillion++
14:12:38 <zodbot> mattdm: Karma for maxamillion changed to 3:  https://badges.fedoraproject.org/badge/macaron-cookie-i
14:12:47 <maxamillion> :D
14:12:49 * pingou feels like a perfect use-case for a quick vm on the infra cloud
14:13:10 <stickster> It sounds like our more immediate problem, then, is actually figuring out what to use, based on a combo of (1) how fast it's wanted/needed, (2) how difficult to package, (3) how maintainable long-term
14:13:36 <maxamillion> nirik: that's fair, I have every intention to get this moving towards a PoC ... one of my biggest concerns is either 1) integration with trac ... or 2) migration capabilities between the two
14:13:58 <ttomecek> maxamillion, thanks for the link; haven't seen it
14:14:12 <maxamillion> ttomecek: certainly
14:14:25 <maxamillion> mattdm: well hopefully I can help with that
14:14:39 <lmacken> so, we can run a command and get a board running on openshift.... why not do that for a prototype to test out some releng/app flows?
14:15:49 <maxamillion> lmacken: I'm good with that if others are also, this is my first adventure into this type of project and just somewhat had the idea in my head that if it was going to be for Fedora, it needed to be hosted by Fedora
14:15:50 <stickster> lmacken: Would it be worth A/B{,/C...}'ing a few apps to see if there are benefits for one vs. another?
14:15:59 <nirik> so releng is on board with being a POC? :) Also, I guess this would mostly apply to f23 planning/flow?
14:16:34 <stickster> maxamillion: Yeah, I think lmacken is talking about just some testing, if we are looking to use it long-term we'd have to see whether to keep on OpenShift or host long-term
14:16:40 <lmacken> maxamillion: we rely on openshift for some apps, the flock ones for example.
14:16:47 <maxamillion> lmacken: ah, rgr
14:16:50 <threebean> (as far as tools go..) kanboard has a documented API.. but I can't find one for cantas ->  http://kanboard.net/documentation/api-json-rpc
14:16:50 <stickster> lmacken: yeah, that :-)
14:17:27 <stickster> That taiga.io looked pretty neat too
14:17:32 <mattdm> Once we're actually using something, I think we need infrastructure commitment for DR, uptime. If the flock apps go down for a week, it would be _bad_, but wouldn't impede work. If people are relying on this for release-related activities, though....
14:17:34 <nirik> well, I'd definitely want to host in house longer term, so we can make sure we have things like backups or being in charge of our own downtime, etc... but doesn't matter too much at all for POC..
14:17:54 <nirik> mattdm: +1
14:18:07 <maxamillion> mattdm: +1
14:18:42 <stickster> nirik: +1 too
14:18:47 <dgilmore> I would like something with an API
14:18:50 <mattdm> yes +1 nirik :)
14:19:12 <bochecha> taiga is python, which seems nicer for us, and it has a plugin for gogs, which means it should be possible to make a plugin for pagure as well?
14:19:12 <threebean> taiga++ http://taigaio.github.io/taiga-doc/dist/api.html
14:19:13 <dgilmore> so that we could have processes update tickets/cards/whatever they are called automatically
14:19:13 <stickster> Ha, http://taigaio.github.io/taiga-doc/dist/api.html
14:19:18 <stickster> threebean: You beat me to it :-D
14:19:24 <dgilmore> for things like TC/RC compose's etc
14:19:32 <stickster> bochecha: I was looking at that too -- looks like easy integration capabilities
14:19:35 <bochecha> as in, it listens to push events in gogs to update the tickets tracked in taiga
14:19:37 <maxamillion> so I think taiga.io is probably the most full featured in this area but it's also still under active development (public beta at this time), it is written in python3 and is aiming at a lot of accessibility functionality as well as a command line ncurses based client (for those of us who care about that sort of thing)
14:19:57 <stickster> maxamillion: Wait, I think I hear threebean singing kumbaya
14:20:03 <maxamillion> :)
14:20:05 <threebean> :p
14:20:09 <pingou> pagure has both web-hooks and fedmsg so we should be able to make both talk to each other
14:20:17 <dgilmore> though long term for TC/RC requests I want it to be all automated and hands off. and it will likely beoutside of this
14:20:49 <threebean> agpl!  https://github.com/taigaio/taiga-front/blob/master/LICENSE
14:20:56 <maxamillion> taiga.io was recommended to me by Nick Coghlan and I've been really impressed with it ... it's lack of stable release is really my only concern at this time
14:21:09 <maxamillion> threebean: you consider that a positive or negative thing?
14:21:11 <bochecha> threebean, that's a good thing, right? :)
14:21:20 <threebean> positive.. but we have to do gymnastics if we hotfix it.
14:21:25 <maxamillion> threebean: +1
14:21:35 <maxamillion> (I never know which way people are leaning when it comes to that stuff)
14:21:50 <lmacken> any python3 app gets my vote ;)
14:21:53 <threebean> our in house agpl projects come with an extra clause that says we have N days to get you the source if we hotfix a prod problem.
14:21:56 <pingou> as long as we don't need to hotfix we're fine :)
14:21:59 <lmacken> (100% language bias)
14:22:31 <nirik> yeah, agpl is a bit nerve wracking if the upstream isn't responsive to do new releases...
14:22:50 <mattdm> What about using taiga's hosted service?
14:22:55 <misc> why, since the hotfix will be in ansible and published ?
14:23:13 <misc> ( I can see why this was annoying for the puppet days, but now...)
14:23:21 <jkurik> does the license applies on plugins as well ? (if we would like to integrate with trac i.e.)
14:23:31 <maxamillion> mattdm: is that something we're open to? (I don't know if there's any policy preventing it, etc)
14:23:42 <lmacken> misc: yeah, it's really not that annoying ;) <3 agpl
14:23:51 <nirik> misc: because you have to make 100% sure all patches/hotfixes are not only public, but linked to from the app and such.
14:23:54 <nirik> it's just a pain
14:24:13 <misc> nirik: maybe by default have a theme that go to ansible repo :)
14:24:25 <stickster> maxamillion: No ban on it, and we've done other hosted services. It basically becomes a "watch vigilantly" thing because an outside hosted service could change (q.v. Transifex)
14:24:36 <misc> ( bonus point that it increase discoverability of the said repo )
14:24:44 <maxamillion> alright
14:25:01 <nirik> well, if it becomes integral to us making fedora it means that other people duplicating us would also have to buy the service, which is poor, IMHO.
14:25:07 <stickster> nirik: *nod
14:25:07 <misc> and because outside service do not always support openid :/
14:25:12 <maxamillion> so it seems we've more or less decided on tiago ... lets get an actual vote going
14:25:19 <stickster> misc: Or integration with our other services
14:25:33 <maxamillion> #idea Use Taigo as the PoC project planning tool
14:25:35 <misc> stickster: fedmsg, yeah :)
14:25:37 <nirik> if we package it and make playbooks available it's a lower barrier to anyone wanting to do the same. ;)
14:25:38 <maxamillion> (did I do that right?)
14:25:55 <stickster> yup
14:26:00 <maxamillion> stickster: thanks
14:26:04 <stickster> My guess is Taiga is probably a lower barrier to package due to being Python
14:26:22 <stickster> But I haven't dug into it to see if/how much bundling
14:26:23 <maxamillion> alright, so +1 from me (but I likely have a bias because its my favorite so far)
14:26:43 <mattdm> nirik: true. However, let's not make that a barrier for *ourselves*. If y'all feel comfortable doing that and supporting it, cool. :)
14:26:50 <stickster> Having a language our crew is well-versed in is a *big* plus and something I didn't expect, frankly... so I was pleasantly surprised
14:26:58 <mattdm> taiga is also the prettiest :)
14:27:05 <maxamillion> stickster: it doesn't appear to have bundling, but the different components are all in different github repos so it'll end up being a list of packages that when combined equal taiga
14:27:18 <maxamillion> stickster: +1
14:27:20 <stickster> maxamillion: That doesn't seem like such a bad thing, either
14:27:21 <maxamillion> mattdm: it is pretty :)
14:27:22 <mattdm> maxamillion in docker :)
14:27:22 <nirik> we already need python3 for mailman3...
14:27:35 <nirik> so, some work already can be overlapping here.
14:27:51 <threebean> +1 to taiga, let's do it.
14:27:57 <maxamillion> nirik: python3 is coming to epel7, yes? (which is of concern for hosting Infra bits on RHEL7, iirc)
14:28:00 <lmacken> +1
14:28:06 <stickster> nirik: Right, do we know who has the ball for Python3 for EPEL right now and how far along that is?
14:28:08 <nirik> maxamillion: yes. review filed.
14:28:11 <stickster> Whoops, *jinx
14:28:13 <maxamillion> nirik: +1
14:28:30 <nirik> stickster: there's a review, need a reviewer... abompard_ hopefully, if not, I can try and do it. ;)
14:28:40 <stickster> abompard_: You've been summoned! :-D
14:29:37 <pingou> should we run a test instance in the cloud first? Before looking into the packaging work?
14:29:42 <mattdm> package in fedora, run in docker on rhel7 :)
14:29:45 <threebean> pingou: +1
14:29:57 <threebean> and we can start developing the extensions we need before packaging is even done.
14:29:58 <mattdm> How about hosted service for the _test_ instance?
14:30:01 <maxamillion> alright, we have 4 +1's ... I think that's right at half of the group ... but no -1's ... sooo maybe? :)
14:30:05 <threebean> we'll need a fas auth plugin, and fedmsg publication
14:30:11 <mattdm> Oh I'm also +1 if we're counting :)
14:30:14 <stickster> pingou: +1
14:30:39 <stickster> #agreed Let's run a test instance of Taiga in the cloud first, before packaging
14:30:40 <nirik> sure, +1
14:30:41 <jkurik> As it has API, I'm also +1
14:30:41 <maxamillion> threebean: I'm also thinking we'll want a trac integration plugin
14:30:59 <maxamillion> stickster: "in the cloud" ... Taiga.io hosted or OpenShift?
14:31:00 <dgilmore> sure +1
14:31:07 <pingou> maxamillion: or pagure depending on where we host the work
14:31:15 <pingou> but either one would be nice
14:31:15 <maxamillion> pingou: +1
14:31:21 <threebean> maxamillion: ok - although I'm not sure what trac integration would even mean.  let's talk more on it.
14:31:28 * nirik thinks thats a detail.... do the Proof of concept wherever it's easiest to stand up
14:31:40 <stickster> maxamillion: seems to me with Openshift we will find any installation/deploy issues early?
14:31:42 <pingou> maxamillion: I'd host it in our cloud, gives us a better clue on how to install/manage it
14:31:47 <threebean> maxamillion, stickster: for "the cloud" let's do the Fedora Infra private cloud for now.  we have maximum control there to set things up as we need.
14:31:53 <threebean> "our cloud" == "fedora infra private cloud"
14:31:58 <threebean> where copr and jenkins and koschei all live now.
14:32:00 <pingou> threebean +1
14:32:01 <stickster> nirik: Yeah, I'm bascially +0 to Openshift, it's really up to the people who know what they're doing :-)
14:32:11 <maxamillion> threebean: mostly such that track tickets get turned into cards in Taiga, either as a migration plan or an integration point
14:32:12 * nirik notes tho we haven't announced yet, our new cloud is ready for business. ;)
14:32:19 <mattdm> KILL TRAC WITH FIRE
14:32:21 <misc> well, problem is deploying in openshift is hardly reusable outside of it
14:32:30 <dgilmore> I would be happy to drop trac
14:32:31 <stickster> OK, ignore me then :-)
14:32:57 <nirik> it's possible pagure+taiga could replace trac... hard to say at this point.
14:32:58 <mattdm> only jwb loves trac
14:33:00 <maxamillion> stickster: well, the install on OpenShift is basically just "pip install $foo" ... we can't install rpms there
14:33:17 <maxamillion> nirik: +1
14:33:22 <stickster> :-P
14:33:27 <pingou> maxamillion: so I've heard! :d
14:33:38 <misc> I like trac too
14:33:47 <maxamillion> oh ok good, for some reason I thought a bunch of people <3'd trac and this would be an lively conversation
14:33:57 <jwb> mattdm is trolling.  i hate no piece of software more than trac
14:34:03 <jwb> i like libtool more than trac.
14:34:06 <stickster> jwb: You want to MARRY trac
14:34:11 <dgilmore> jwb: that is saying something
14:34:22 <pingou> jwb: did you propose yet? :)
14:34:30 <maxamillion> #action maxamillion to write up plans, requirements, and tasks needed to implement Taigo in Fedora OpenStack Cloud (whatever we're calling it)
14:34:41 <stickster> poor jwb, walks into this meeting and all he gets is abuse
14:34:59 <threebean> #agreed jwb to take over maintenance of fedorahosted/trac
14:35:03 <pingou> maxamillion: there were a bunch of names proposed on the infra list, you can pick from that list :)
14:35:05 <stickster> HEY NOW
14:35:05 <maxamillion> #action once the plans are written up on the wiki, send out an email to the rel-eng list with an update and continue the discussion there
14:35:22 <jwb> threebean, oooohh... please?  then i could shutter it immediately.
14:35:27 <threebean> jwb: :)
14:35:50 <maxamillion> jwb: I promise I didn't schedule this meeting with the intention of you being trolled
14:35:50 <stickster> 301 --> HADES
14:36:13 <jwb> maxamillion, it's ok.  i'm used to it.
14:36:21 <maxamillion> OK, so other than those two action items can anyone think of anything else they would like to see on there? any concerns? $other?
14:36:36 * mattdm lols
14:37:16 <threebean> yeah.  fas, fedmsg, and trac integration will be necessary bits.
14:37:34 <maxamillion> threebean: +1
14:37:34 <threebean> once we get a test instance setup, we'll need to socialize how it should be used.
14:37:55 <pingou> sounds good
14:37:58 <maxamillion> #action the scope of the Taiga work will need to include fas, fedmsg, and trac integration
14:38:06 <nirik> also badges! :)
14:38:20 <maxamillion> #link http://taigaio.github.io/taiga-doc/dist/api.html
14:38:50 <mattdm> actually yes please do include badges. that's part of decause's plan for contributor onboarding
14:38:50 <maxamillion> #action Taiga integration with Fedora Badges will also be needed (potentially an opportunity for new types of badges here)
14:38:56 <maxamillion> +1
14:39:28 <stickster> #undo
14:39:28 <zodbot> Removing item from minutes: ACTION by maxamillion at 14:38:50 : Taiga integration with Fedora Badges will also be needed (potentially an opportunity for new types of badges here)
14:39:38 <maxamillion> :(
14:39:44 <stickster> #info Taiga integration with Fedora Badges will also be needed (potentially an opportunity for new types of badges here)
14:39:47 <stickster> :-)
14:40:03 <maxamillion> ah
14:40:04 <maxamillion> +1
14:40:14 <stickster> '#action <person> <do this>'
14:40:14 <threebean> well... wait a minute.  I thought we were talking about rolling this out for some groups (releng, infra, etc..)
14:40:30 <threebean> and where we need help with on-boarding is mostly in other groups.
14:40:47 <maxamillion> threebean: first swing will just be rel-eng, but we'd like to be able to accomodate all groups
14:40:59 <maxamillion> (Infra can join the party too if they like)
14:41:10 <stickster> The question is how many new-ish contributors are going to jump into kanban boards
14:41:12 <threebean> more badges for the infra team aren't needed.  we're over-represented in the badges system as is.
14:41:16 <stickster> That seems rather a large assumption
14:41:24 <lmacken> the boards could potentially be just widgets within the hubs in the future?
14:41:26 <stickster> mattdm: Care to elaborate?
14:41:32 <threebean> not a blocker -- of course we can do badges.
14:41:34 <mattdm> threebean: I think rel-eng onboarding is pretty important too
14:41:35 <maxamillion> stickster: that was always the direct route for newcomers in OpenShift land and it went well
14:41:46 <mattdm> yeah I'mhappy with it as an info rather than immediate action :)
14:41:52 <maxamillion> stickster: https://trello.com/openshift
14:41:54 <stickster> maxamillion: But were those newcomers all people contributing code to OpenShift?
14:42:13 <mattdm> I think this will be a lot friendlier to new users than trac ever was
14:42:18 <stickster> maxamillion: Better question -- what did that uptake look like for not-code things?
14:42:21 <maxamillion> stickster: mostly, it was meant as an onboarding for people who wanted to get into the code ... users we just sent to the documentation
14:42:27 * nirik just added badges for completeness. We need to get a lot more done before we get there. :)
14:42:45 <maxamillion> mattdm: +1
14:42:49 <stickster> maxamillion: Right, that's my point (maybe threebean's, not sure) -- I don't see the link between this and decause contributor onboarding
14:43:10 <mattdm> stickster I think don't underestimate how big this stuff is in the world of software developers we'd _like_ to attract as future contributors
14:43:29 * stickster still thinks we are missing the big picture of not-developers.
14:43:32 <mattdm> trello.com has _more users that fedora_.
14:43:47 <maxamillion> stickster: I don't see how it will be a code vs not-code contribution divisor ... kanban is used by a number of documentation teams and ops teams with great success (OpenShift being the example I'm most intimately familiar with)
14:43:56 <stickster> But -- that's a discussion that is probably veering off topic, so we can defer it for now
14:44:01 <mattdm> maxamillion: +1
14:44:24 <maxamillion> stickster: I think it's relevant if you'd like to continue discussion there
14:44:42 <maxamillion> I've already got both #1 and #2 things I had hoped to get out of this meeting answered
14:45:17 <stickster> maxamillion: OK, that's cool -- I thought you were saying OpenShift didn't get a lot of not-code stuff through kanban, which would make me wonder whether we'd need to address that gap in other ways.
14:45:50 <stickster> But if that's not the case, and we think we *can* get other people interested this way, then I'd feel even *more* strongly that this is a useful project ;-)
14:45:53 <maxamillion> stickster: not from the community, no ... but I think a lot of that is because we had a hard time attracting documentation writters
14:46:16 <stickster> maxamillion: And *that* gets into an orthogonal discussion, so I won't reply to it directly :-)
14:46:28 <maxamillion> stickster: I think this is a good example of a not-code board, it's ansible playbooks and deployment automation related so it's still technical, but not specifically code https://trello.com/b/Qb18IWHF/openshift-ansible (though I might be splitting hairs there)
14:46:34 <mattdm> fwiw I had great success with this for non-coding tasks at $previousjob
14:46:35 <maxamillion> stickster: :)
14:47:24 <stickster> maxamillion: So what else do we need to close on in this meeting?
14:47:45 <maxamillion> stickster: nothing, I just didn't know if we were done discussing the not-code contributor considerations topic
14:47:53 <dgilmore> there is non developer use cases for project management in Fedora
14:48:06 <dgilmore> i could see FAMSCo using it
14:48:25 <stickster> dgilmore: No doubt
14:48:37 <maxamillion> #topic Open Floor comments, concerns, or $other related to the Project Planning Tools Discussion
14:48:52 <mattdm> do you want me to ask if cloud wg or server wg are interested in being early adopters? or are we too early for that?
14:49:05 <mattdm> jwb want to switch the council away from trac? <- not kidding
14:49:08 <dgilmore> mattdm: we can approach the Working groups
14:49:13 <stickster> mattdm: We should probably first do our prototype testing
14:49:22 <pingou> I think it's nice if there is something to show while asking
14:49:22 <maxamillion> mattdm: I think we .... what stickster said
14:49:32 <dgilmore> pingou: sure
14:49:32 <stickster> mattdm: No sense in getting hopes up if it turns out it completely sucks (which seems unlikely, but still...)
14:49:33 <mattdm> okay I'll wait :)
14:49:45 <maxamillion> yeah, if we could give a demo or something while saying "hey, you interested?" I think would speak volumes
14:49:51 <stickster> maxamillion: +1
14:49:51 <maxamillion> stickster: +1
14:49:56 <stickster> No, +1 YOU
14:49:59 <maxamillion> :D
14:50:25 <mattdm> (actually, I could see doing a demo of this as a video chat council meeting, once it gets far enough for that)
14:50:27 <abompard> stickster: And I will answer the call!
14:50:33 <stickster> abompard: \o/
14:50:44 * randomuser suddenly realizes the meeting he wanted to attend has mostly already happened
14:50:47 <maxamillion> mattdm: that would be great!
14:51:09 <maxamillion> mattdm: is there a preferred video chat platform by the council? (just curious so I can be sure to have it setup and working)
14:51:18 <mattdm> randomuser: tl;dr we're going to try taiga.io
14:51:22 <stickster> randomuser: The notes are awesome, kind of like Avengers 1.5: Tony Builds a New HQ
14:51:33 <randomuser> cool
14:51:34 <maxamillion> I realize that was presumptuous(sp?) ... but I figured I'd be the one who makes the pitch
14:51:37 <mattdm> maxamillion: we used google hangouts. It was more a matter of expedient than preferred :)
14:51:43 <maxamillion> mattdm: fair
14:51:59 <maxamillion> alright, anything else before we close the meeting?
14:52:37 <stickster> I wish my other meetings were this good :-)
14:52:39 <mattdm> maxamillion i made a taskwarrior item for myself to check in with you about that later :)
14:52:45 <maxamillion> mattdm: +1
14:52:52 <maxamillion> stickster: awwww, thanks :D
14:53:05 <maxamillion> alright, I'm going to call it ...
14:53:10 <stickster> Oh, I was talking about hassling jwb
14:53:19 <maxamillion> heh
14:53:22 <maxamillion> fair enough
14:53:26 <maxamillion> #endmeeting