14:09:05 <puiterwijk> #startmeeting Regcfp flock 2017
14:09:05 <zodbot> Meeting started Wed Apr 19 14:09:05 2017 UTC.  The chair is puiterwijk. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:09:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:09:05 <zodbot> The meeting name has been set to 'regcfp_flock_2017'
14:09:09 <bexelbie> i.e. we need to get Bobster here because they are important for X, Y, Z, even if they aren't directly "speaking"
14:09:12 <puiterwijk> #chair bexelbie mizmo stickster
14:09:12 <zodbot> Current chairs: bexelbie mizmo puiterwijk stickster
14:09:32 <mizmo> #info day 1 - talks + level settings
14:09:33 <stickster> bexelbie: If I understand Patrick's perspective right... he is looking for specifics that will help him update the regcfp application so we can open registration ASAP.
14:09:47 <mizmo> #info day 2, day 3- "do" events - hackfests, workshops, etc.
14:09:56 <bexelbie> stickster, I understand that but we were discussing the CFP
14:10:01 <stickster> yup yup
14:10:04 <bexelbie> if we want to move onto reg we can
14:10:04 <mizmo> #info day 4 - conclusions, show and tell
14:10:06 <stickster> just level setting for meetbot sake
14:10:23 <bexelbie> #info - this is one proposal
14:10:40 <bexelbie> #info Council would like to see an emphasis on "do" and not on "talk"
14:10:47 <mizmo> #action add field to regcfp for talk proposers to indicate "who needs to be in the room for this to be successful"
14:10:51 * stickster thinks we need to be past proposals at this point and on to "this is what we're doing"
14:11:00 <bexelbie> #info Council would like to make sure we have the right people at flock to be able to be productive and achieve goals
14:11:17 <bexelbie> stickster, there are no other proposals, but I figured the folks in this meeting might have feedback
14:11:24 <bexelbie> barring that, we will adopt that methodology :)
14:11:28 <stickster> I'm +1 on more do and less talk
14:11:51 <bexelbie> Any issues with the day1-4 and more do less talk concept?
14:11:51 <mizmo> we are close to the point last year that the CFP due date was in terms of time before flock 2016
14:11:54 <stickster> I think a CFP full of status report presentations would not achieve what the Council is looking for, nor help us get the right people to Flock to move initiatives forward
14:12:19 <stickster> So in terms of regcfp, puiterwijk, are there specific track names or something we would need to have settled?
14:12:34 <mizmo> bexelbie: not at all, only thing is i wonder if the slots should be longer for 'do' slots
14:12:45 <bexelbie> puiterwijk, perhaps you could share what fields we capture in the current app?
14:12:46 * stickster doesn't have a running app in front of him to recall what it looked like last year -- but beyond that, regcfp has had plenty of commits in the meantime
14:13:04 <bexelbie> mizmo, That is the plan
14:13:30 <mizmo> bexelbie: so if we're not doing big all group talks in the mornings, that's going to change our plan with the venue right
14:13:34 <bexelbie> I believe we will need to have a 'how much time do you need' field - and we can put in some choices
14:13:38 <puiterwijk> bexelbie: currently we capture a title, summary and a trackname
14:13:40 <mizmo> because right now we've booked the large keynote room every morning until lunchtime
14:14:12 <bexelbie> mizmo, we can review that; I don't believe we will have a significant number of large talks on days2-3
14:14:15 <puiterwijk> We could use "trackname" for options of "how long does this last"
14:14:17 <bexelbie> but we have been talking about a few ideas
14:14:26 <bexelbie> puiterwijk, yes +1
14:14:39 <puiterwijk> So you'd have a "track" of "90 minutes", a "2 hour" "track", etc
14:14:42 <bexelbie> I can take an action item to develop that list and send it out to flock-planning
14:15:30 <mizmo> will choose-your-own-timeslot-length result in a nightmare in the backend trying to build out the schedule?
14:15:40 <puiterwijk> mizmo: I'm pretty sure it will
14:15:58 <bexelbie> I don't know about that - we can modify things as needed to a degree - and we may find that we can group things better
14:15:59 <puiterwijk> Unless you have things like "60 minutes" "120 minutes", etc.
14:16:05 <mizmo> maybe better to just say, hackfest is 2 hours, workshop is 90 min and have them pick between
14:16:18 <bexelbie> I strongly suggest we have multiple options, but from a fixed list
14:16:30 <puiterwijk> mizmo: might be easier to say that everything's a multiple of some time unit
14:16:34 <bexelbie> Council discussed the idea of allowing from some long sessions, like all day or half day even
14:16:46 <bexelbie> s/from/for/
14:16:56 <mizmo> but how do you build a schedule from that? what if you dont have enough things that require the same length of time such that concurrently you have 90 min, 60 min, and 120 min things
14:17:25 <mizmo> the number one complaint i saw going through old blog reports from flocks was that people had a hard time getting to all the talks they wanted because they were at the same time
14:17:28 <bexelbie> I have a feeling we can make it work but elongating things if needed, especially if we do increments of 60
14:17:40 <bexelbie> There is no way to fix that
14:17:47 <bexelbie> as we can program flock to be perfect for everyone
14:17:50 <bexelbie> hopefully with do
14:17:54 <mizmo> no, but having things with different durations at the same time would make that worse
14:17:55 <bexelbie> and the list of people
14:17:58 <bexelbie> we can try to optimize
14:18:14 <stickster> It sounds like, if we're going to re-orient the way sessions are done, we need both (1) to decide how/whether to use track names; and (2) advance word to the community on expectations for Flock talks (i.e. don't submit typical "Overview of Fedora $SUBTEAM" and expect accpetance)
14:18:22 <bexelbie> But forcing everythig to the same time length is worse
14:19:01 <mizmo> im not saying force to the same time length, but my points are
14:19:01 <mizmo> 1) does the proposer even know how long they need? have they given the talk before?
14:19:11 <bexelbie> I am thinking we would have talk X, Y and workshop, X, Y, Z (maybe X=1hour, Y=2 Hour, z=4 hour)
14:19:22 <bexelbie> mizmo, the majority shouldn't be talks
14:19:27 <mizmo> 2. it'll be a cluster to have different time length things running at the same time. can we make blocks of time ("wed afternoon") when all the 60 min things take place, and a different block where all the 90 min things take place?
14:19:28 <bexelbie> we want more focus on "do"
14:19:36 <mizmo> when i say "talk" i mean "schedule item"
14:19:44 <stickster> "session"
14:19:50 <mizmo> better word
14:20:01 <bexelbie> if you have a plan for a work session, you should have a rough idea how long you need, in my opinin
14:20:07 <bexelbie> yeah, you may get surprised, but you should have an idea
14:20:13 <mizmo> the other thing is, you know, i've given the same inkscape workshop in 30, 45, and 2 hours - yout ell me how long you want the workshop to be
14:20:13 <bexelbie> we need to spend X hours working on this
14:20:17 <bexelbie> or Z hours planning
14:20:31 <mizmo> so session proposers might not know how long it should be
14:20:42 <bexelbie> mizmo, I suspect you know which of those three times are optimal though
14:20:50 <bexelbie> relative to your goals with this instance
14:20:55 <mizmo> bexelbie: nope it entirely depends on the audiences wants / needs
14:20:57 <stickster> probably depends on audience
14:21:00 <stickster> *jinx
14:21:11 <bexelbie> but you know the audience and the goals of offering the workshop - you have to guess
14:21:17 <stickster> But in this case at least we know the audience is mainly hard core contributors
14:21:27 <stickster> Anyway -- we're getting bogged down on time slots here
14:21:49 <stickster> Can we say, Day 1 is 60 minute blocks, and Day 2-3 are 2 hour blocks?
14:22:08 <bexelbie> I'd rather not commit like that - we may want to accept differently
14:22:16 <bexelbie> why can't we just suggest people pick a slot when submitting?
14:22:20 <bexelbie> we will build the schedule the way that makes sense
14:22:29 <stickster> bexelbie: so let the submissions determine? I'd be OK with that
14:22:33 <bexelbie> yes
14:22:36 <stickster> as long as we get underway ASAP
14:22:38 <puiterwijk> bexelbie: do you mean that people select a duration, or an actual slot in the schedule?
14:22:41 <mizmo> are you going to have flexibility to grant someone a time block that is different than what they asked for?
14:22:47 <bexelbie> puiterwijk, duration - not slot
14:22:52 <bexelbie> mizmo, yes
14:22:55 <puiterwijk> Right.
14:23:01 <mizmo> (if so i would note that in the regcfp ui, eg you may not get what you asked for depending on proposals)
14:23:05 <bexelbie> mizmo, we can negotiate
14:23:19 <bexelbie> mizmo, I would strongly discourage us from doing it without talking to the submitter
14:23:29 <bexelbie> the change may render their goal impossible
14:23:32 <bexelbie> we have to ask
14:23:40 <bexelbie> this should hopefully be a rare situation
14:23:49 <mizmo> so the wording i'd suggest: "What time duration would you like to request for this session?" which could set expectations appropriately
14:23:57 <bexelbie> yes
14:23:58 <stickster> yep
14:24:02 <puiterwijk> Sounds good
14:24:35 <stickster> puiterwijk: are there other CFP related questions that need to be drilled down/figured out here?
14:24:38 <puiterwijk> Okay, so is that going to be the main changes for the CFP we envision? If yes, maybe let's go to registration?
14:24:52 <bexelbie> puiterwijk, and the "who needs to be ehre" question
14:24:56 <bexelbie> here
14:25:00 <mizmo> well again, in terms of my kiddo's legos, i'm concerned you're going to end up with a set of legos that are: 20x 4-squares, 3x 6-squares, and 2x 8-squares and not be able to build anything close to resembling a house (or schedule)
14:25:02 <stickster> #agreed Ask question "What time duration are you requesting for this session?" in regcfp UI
14:25:16 <stickster> #agreed Ask question "Who needs to be in this session?" in regcfp UI
14:25:31 <bexelbie> mizmo, then we can talk to the legos that don't fit and work with them
14:25:34 <mizmo> "Who needs to be present at this session for it to be successful?" <= wording?
14:25:41 <stickster> #undo
14:25:41 <zodbot> Removing item from minutes: AGREED by stickster at 14:25:16 : Ask question "Who needs to be in this session?" in regcfp UI
14:25:50 <bexelbie> mizmo's wording with (name and FAS ID)
14:26:02 <stickster> #agreed Ask question "Who needs to be in this session? (include name/FAS ID)" in regcfp UI
14:26:06 <mizmo> just a freeform text field right
14:26:07 <stickster> darn it
14:26:15 <stickster> #undo
14:26:15 <zodbot> Removing item from minutes: AGREED by stickster at 14:26:02 : Ask question "Who needs to be in this session? (include name/FAS ID)" in regcfp UI
14:26:27 <stickster> #agreed Ask question "Who needs to be present in this session for it to be successful? (include name/FAS ID)" in regcfp UI
14:26:30 <puiterwijk> mizmo: sure. Or maybe a multi-valued field with multiple names.
14:26:47 <bexelbie> puiterwijk, if you can pull out FAS ids for easy reporting that wouldl be awesome
14:26:50 <puiterwijk> Though free text is more fleible
14:27:00 <stickster> #agreed Flock team will work out schedule based on CFP entries, and by working with various submitters where needed so the schedule-tetris works
14:27:00 <mizmo> puiterwijk: multi-value would definitely make it easier for us in reading what people submitted
14:27:03 <puiterwijk> bexelbie: If we go with a field per username, I should be able to
14:27:11 <mizmo> schedule tetris! that is exactly what i was grasping for
14:27:13 <puiterwijk> Guess I'll do that
14:27:16 <stickster> mizmo: :-)
14:27:17 <bexelbie> puiterwijk, I have faith in you producing what is possible to produce, knowing we need both freeform and fas ids :)
14:27:45 <puiterwijk> Okay. So, let's say that that's CFP for now, and move on to registration
14:27:59 <bexelbie> puiterwijk, can you refresh on what fields we ask for now?
14:28:01 <mizmo> (we need dates for CFP too right?)
14:28:08 <stickster> bexelbie: what's the deal with cost for registration? ISTR there was talk about a scaled cost, q.v. https://github.com/puiterwijk/regcfp/issues/199
14:28:14 <stickster> mizmo: yes
14:28:32 <stickster> when do we need CFP to open?  IMHO needs to be lickety-split, since you're asking people to plan for travel
14:28:47 <bexelbie> How about May 1 to June 15 with decisions by July 1
14:28:52 <bexelbie> that leaves 2 months for ticket purchases
14:29:07 <mizmo> yeh we have a month until the 3-month prior sweet spot for airline prices
14:29:27 <stickster> for the record... I blame our runway on waiting on Red Hat decision on a related event, and in the future, we shouldn't (won't) make that mistake again ;-) Let them catch up to the community rather than vice versa
14:29:48 <puiterwijk> Well, we probably want to open registration before CfP. And that leaves me with about 1 week to get both done.
14:29:57 <bexelbie> puiterwijk, what is reasonable?
14:30:06 <bexelbie> puiterwijk, I also think they can open at the same time, if needed
14:30:08 <puiterwijk> bexelbie: that depends on what we end up requiring for registration
14:30:28 <puiterwijk> bexelbie: sure. I meant the <= operator
14:30:32 <stickster> bexelbie: Do we really need six weeks for CFP? I think that's wildly optimistic about CFP-closing/scheduling time needed
14:30:51 <stickster> I think with some advance warning *now* we could shorten the CFP period itself to 3, maybe 4 weeks at most
14:31:11 <bexelbie> as we are asking people to decide who needs to be there we need to allow time for them to all catch up
14:31:19 <bexelbie> I think 4 weeks is a minimum
14:31:19 * puiterwijk notes that my experience with other events (GUADEC) has given about 30% of submissions on CfP open, and 50% on Cfp close day... If we just have CfP open for three days, that might be optimal!
14:31:27 <puiterwijk> (part of that is a joke)
14:31:28 <stickster> lol
14:31:34 <stickster> score one puiterwijk
14:32:44 <stickster> puiterwijk: So the question is, is a week *enough* to get both done?
14:32:54 <puiterwijk> So, would it be an idea to collect requirements for registration? Once I have that info, I might be able to estimate a time period for that, and then we can see what's reasonable
14:32:58 <mizmo> lol
14:33:02 <mizmo> 4 weeks seems a reasonable duration then? and we can plan for lots of reminder pings on the community blog, social, etc
14:33:08 <stickster> puiterwijk: bexelbie: See my question above regarding registration and $
14:33:22 <mizmo> puiterwijk: what do we have now from last year?
14:33:24 * stickster points to https://github.com/puiterwijk/regcfp/labels/Module-Registration
14:33:31 <bexelbie> stickster, I saw it - before we touch on cost and funding, can puiterwijk please share what we are asking for for data in the app so far?
14:33:37 <mizmo> i remember there were a lot of fields about what region you were from for funding right
14:33:56 <stickster> https://github.com/puiterwijk/regcfp
14:34:07 <bexelbie> The council wants funding to be a separate feeling process from registration - it is not just a checkbox
14:34:36 <stickster> bexelbie: ^ if you scroll down to "Customising the registration form" you'll see the functionality
14:34:46 <puiterwijk> mizmo: info we collect now: email, name, country, subsidy request, invite letter, vegetarian, dietary, volunteer, family, shirtsize, roomshare, roommate, hotel booked, brno bus, ircnick, blog, twitter, badge extra line
14:35:02 <puiterwijk> bexelbie: ^
14:35:47 <bexelbie> We'd like to add, "what are your goals in attending" or something to that effect
14:36:00 <bexelbie> kind of the counterpoint to "who needs to be there" in the CFP
14:36:02 <puiterwijk> Right. Adding fields there is pretty trivial, as that's just config
14:36:24 <mizmo> puiterwijk: what happens if someone fills in an email that bounces?
14:36:46 <bexelbie> There has been some discussion about doing stickers instead of shirts this year, so that data may not be needed
14:36:48 <puiterwijk> mizmo: they don't fill in an email address. We pick email from FAS
14:37:10 <stickster> +1
14:37:25 <puiterwijk> We have a FAS username. And if people don't maintain their email address in FAS... there's further problems
14:37:35 <bexelbie> puiterwijk, they aren't core contributors then :P
14:37:57 <bexelbie> ready to talk about reg and funding? (did you see my field addition?)
14:38:19 <stickster> #agreed Add field for "What are you goals in attending Flock?" in registration
14:38:23 <puiterwijk> bexelbie: yep, saw your "what are your goals" field addition. That's where I mentioned that adding a field is just config
14:38:29 <bexelbie> puiterwijk, cool
14:38:37 <bexelbie> stickster, thanks for minuting
14:38:51 <puiterwijk> So, the reg and funding/payment stuff
14:38:57 <stickster> #link https://github.com/puiterwijk/regcfp/issues/199
14:38:59 <bexelbie> The council would like to have a registration fee/ticket price
14:39:29 <puiterwijk> Okay. And that's a set value, so not like GUADEC a value the people can pick themselves, with a reasonable default?
14:39:36 <bexelbie> right now I am working to determine how we take the money
14:39:39 <puiterwijk> (just to be sure)
14:39:48 <bexelbie> so we will probably have multiple ticket values
14:39:56 <bexelbie> the idea is that price scales based on the region someone is from
14:40:00 * stickster suggested using the Big Mac Index to scale the fee, see the ticket above
14:40:02 <bexelbie> however, I don't think we are going to try to enforce this
14:40:05 <puiterwijk> bexelbie: I currently support paypal and "pay on site" out of the box. If you want anything else, I'd need info very soon
14:40:14 <bexelbie> so we will develop a set of price points and put country suggestions
14:40:29 <bexelbie> puiterwijk, I am trying to get paypal cleared by RH
14:40:35 <bexelbie> puiterwijk, so soon :)
14:40:48 <puiterwijk> bexelbie: okay, if it's paypal, I can have it set up in a few minutes, so that's less problematic :)
14:40:58 <bexelbie> perfect
14:41:02 <puiterwijk> The "soon" is more if I need to add an additional payment provider - adding those is always quite tricky
14:41:04 <bexelbie> I will let you know when approval is reached
14:41:13 <bexelbie> puiterwijk, absolutely
14:41:24 * puiterwijk shivers at deadling with payment providers
14:41:27 <puiterwijk> dealing*
14:41:42 <bexelbie> also, we are going to offer a "would you like to add more $$ to help subsidize the travel of other contributors"
14:41:49 <mizmo> puiterwijk: picking email from FAS is an issue
14:42:05 <puiterwijk> So, regarding the country prices: do we want to ask for country, and then prefil default, or just have a table and people enter the amount themself?
14:42:12 <puiterwijk> mizmo: how so?
14:42:15 <bexelbie> puiterwijk, will that be a problem?
14:42:24 <puiterwijk> bexelbie: which one?
14:42:28 <mizmo> puiterwijk: sometimes people don't use the email address they have associated with FAS (i don't), there was an issue last year where notifications were going to that email address and the speaker didn't get them until the last minute
14:42:30 <mizmo> puiterwijk: so her travel had to be booked la$t minute
14:42:31 <bexelbie> I am ok with offering a table and having people fill in the amount (the adding more $$)
14:42:42 <bexelbie> but ideal might be
14:42:46 <mizmo> puiterwijk: i think it might be better to have an email field pre-populatedbased on FAS and allow them to change it
14:42:51 <bexelbie> drop down of tickets and country suggestions (user picks one)
14:42:59 <stickster> mizmo: we'll simply need to let them know in the form, then. making more room for human error seems silly to me
14:43:00 <bexelbie> then a box for extra amount if any
14:43:05 <bexelbie> and calculate that for the payment amount
14:43:21 <stickster> mizmo: having FAS email going to something unchecked is dangerous. What happens if there's an unexpected change to SSH key or login info?
14:43:22 <puiterwijk> bexelbie: okay, that's reasonably simple to do
14:44:03 <stickster> So maybe we can put a reminder that says, "Please make sure <your FAS email> (link to FAS) is correct so we can reach you."
14:44:05 <bexelbie> mizmo, I think that speaker whomever they were should have been cancelled if they were non-responsive - FAS email working should be a requirement in life - stickster's comment too :)
14:44:14 <bexelbie> puiterwijk, cool
14:44:24 <puiterwijk> mizmo: last year we also allowed non-FAS accounts. That'll no longer be an option this year.
14:44:34 <bexelbie> puiterwijk, +1
14:45:09 <puiterwijk> stickster: I am assuming that "<your fas email>" would be the actual email address, and then a link to change it after?
14:45:17 <stickster> puiterwijk: sure
14:45:23 * stickster entering ticket in github for this :-)
14:45:29 <puiterwijk> +1 thank you
14:45:54 <bexelbie> puiterwijk, one Q - with funding we are going to allow for someone to indicate they can't even afford the ticket price - can your system accept that they registered but haven't paid yet?
14:45:55 <puiterwijk> bexelbie: I was mostly concerned if we need to be very strict at enforcing the price point against all malicious users :-)
14:46:09 <puiterwijk> bexelbie: yes.
14:46:10 <bexelbie> puiterwijk, we have to have faith in our community to be honest
14:46:12 <bexelbie> puiterwijk, cool
14:46:33 <puiterwijk> bexelbie: that's actually exactly what "pay on site" does :)
14:46:37 <bexelbie> puiterwijk, if we have data to preset hte dropdown we can use - awesome - otherwise honest rules the day
14:46:50 <bexelbie> puiterwijk, ahh,
14:46:52 <stickster> https://github.com/puiterwijk/regcfp/issues/200
14:46:56 <bexelbie> we'd like all tickets to be paid online
14:47:00 <bexelbie> in advance
14:47:13 <bexelbie> if someone cannot pay online, then we can work on exceptions
14:47:30 <bexelbie> and for people who are asking for funding they may want to delay paying until the decision is made
14:47:31 <puiterwijk> bexelbie: right, agreed. I just meant to indicate the system can handle not-paid registrations
14:47:33 <bexelbie> so we don't have to do refunds
14:47:36 <stickster> yeah, we definitely don't want "bring cash with you" :-D
14:47:37 <bexelbie> puiterwijk, ok
14:47:49 <bexelbie> stickster, well we do - but for other reasons :P
14:47:51 <puiterwijk> And people can also pay (more) later
14:48:00 <mizmo> stickster: my email situation is a mess but I definitely check fas email way less frequently than my main rht acct, too many automated messages
14:48:22 <mizmo> stickster: i suspect thats the issue for others too - they hesitate to point it at their main email account because of the volume
14:48:50 <mizmo> stickster: the other thing is buried in the automated messages its hard to notice an email
14:48:55 <mizmo> so you might get it but miss it
14:49:10 <mizmo> but at the least telling people specifically what email account notices will go to would be an improvement
14:49:29 <bexelbie> puiterwijk, if we decide to allow email editing is that a huge challenge? if not, can we take the email discussion to email?
14:49:39 <stickster> bexelbie: +1
14:49:59 <stickster> bexelbie: mizmo: See link above, https://github.com/puiterwijk/regcfp/issues/200 -- you can use that too
14:50:38 <puiterwijk> bexelbie email editing is a reasonable challenge, especially since the email address is (in the current system) the unique identifier, and there's no email verification system. But I could do that in a limited time
14:50:48 <bexelbie> puiterwijk, are fas email changes imported into this tool, or do we just point emails at fas@fedoraproject.org?
14:51:01 <puiterwijk> bexelbie: fas@fedoraproject.org is what I'd do
14:51:14 <bexelbie> puiterwijk, would it be practical to move to fas as unique ID since they are now required?
14:51:15 <puiterwijk> Since those are unique, and they change immediately when you update email in FAS
14:51:38 <stickster> is fas required for all regcfp instances, or is this more a Fedora constraint?
14:51:47 <puiterwijk> bexelbie: yes, but that'd require a bunch of changes. So it's doable, just not 100% if that'd take a day or two
14:51:47 <mizmo> rather than verify you could just suggest "if this email doesn't work, email flock-planning" (or whatever) and handle it manually
14:52:02 <puiterwijk> stickster: it now does OpenID, and for Fedora I'm pointing it to id.fedoraproject.org
14:52:07 <stickster> gotcha
14:52:15 <stickster> OK, let's move on past the email thing, 8 min left
14:52:40 <stickster> are there other topics still to figure out for regcfp to be ready to register ~May 1?
14:52:42 <puiterwijk> Okay, so with the things that we discussd just now, I think getting it before May should be doable.
14:53:06 <bexelbie> Funding requests
14:53:19 <puiterwijk> Right. You said you want that to be a separate feeling
14:53:40 <bexelbie> not to force a solution, but one option would be to run a second instance of reg tuned for the funding
14:53:49 <bexelbie> then we can just use the fields structure to accomplish it
14:53:52 <bexelbie> but here is the goal
14:53:54 <bexelbie> and you tell me
14:54:19 <bexelbie> we want to display the expected cost of the person's funding level to them.  This will involve some basic math fields on things like hotel rooms (nights x rate), etc.
14:54:28 <bexelbie> we will also need to ask them to input things like estimated airfare costs
14:54:35 <bexelbie> and have a checkbox about whether they can afford the ticket or not
14:54:36 <bexelbie> then
14:54:58 <bexelbie> we want to ask them, what if anything they can afford to pay.  The idea is to take our funding from 0% or 100% to a more flexibile number
14:55:15 <bexelbie> for example, if I live in Czech Republic (shocking, I know) and I could afford a 100 EUR flight to a flock in France
14:55:23 <bexelbie> I might pay that 100 EUr towawrd my flock in the US
14:55:39 <bexelbie> so after that we need to be able to later bill the people who are accepted if they are paying anything
14:55:49 <bexelbie> we also want to add some information on things that will not be covered
14:55:57 <bexelbie> for both funded and non-funded people
14:56:09 <bexelbie> we would add more links to this screen to re-emphasize data we will have on the main site
14:56:21 <bexelbie> like "only X meals are provided, average meal cost is Y - be prepared" ...etc.
14:56:31 <bexelbie> does that make sense?
14:57:20 <bexelbie> and for the record, someone has already told me they may apply for funding and choose to pay 100% just to get out of having to make their own travel reservations :P
14:57:53 <puiterwijk> bexelbie: that makes sense, and I think I have some ideas. But you want to have a separate feeling for it?
14:58:01 <puiterwijk> bexelbie: that's possible? I need to remember that! :)
14:58:10 <bexelbie> puiterwijk, a separate feeling meaning - it shouldn't be a check box
14:58:22 <bexelbie> if you can do all of this in one app - go for it
14:58:24 <puiterwijk> bexelbie: ah, okay. So a separate form inside the same system would be fine?
14:58:26 <stickster> bexelbie: right, not like "do you need funding Y/N"
14:58:28 <bexelbie> if you want to have an expanding page element that is great
14:58:37 <bexelbie> puiterwijk, yeah that is great
14:58:46 <puiterwijk> Right, okay.
14:58:46 <mizmo> (do you want a mockup puiterwijk?)
14:58:47 <bexelbie> like I said, I am not pushing a solution - just stating the end goal
14:58:51 <puiterwijk> mizmo: yes, please!
14:59:00 <mizmo> i can work on it today
14:59:12 <puiterwijk> bexelbie: yep, thanks for that. I think this should be reasonable
14:59:12 <stickster> bexelbie: are you + team prepared for eventuality of someone reneging on the bill?
14:59:42 <bexelbie> stickster, bills gotta get paid before travel gets booked
14:59:44 <puiterwijk> bexelbie: I am going to assume that after people submitted a request, the details will be worked out out of the system? Or do we need to do all of that inside there too?
14:59:47 <stickster> bexelbie: gotcha
14:59:48 <bexelbie> if someone needs to change their terms they can talk to us
14:59:56 <stickster> sounds reasonable to me
15:00:00 <bexelbie> puiterwijk, what do you mean?
15:00:18 <stickster> like booking travel and settling the bill?
15:00:31 <puiterwijk> bexelbie: well, I am going to guess that most funding requests aren't just "approved" or "rejected", but there's a dialogue between council and the person requesting funding?
15:00:42 <puiterwijk> Or is it just "rejected, sorry, try again next year" or "approved, here is the money"?
15:00:47 <bexelbie> puiterwijk, yeah - but in the end we need to be able to have the person pay
15:00:49 <puiterwijk> (I have never been involved in this for Fedora)
15:00:54 <bexelbie> so doing that via the system would be great
15:01:01 <bexelbie> as for everything else, we can do it externally
15:01:12 <bexelbie> we just need to downlaod the data and if needed adjust amounts being requested from the person
15:01:18 <puiterwijk> bexelbie: You mean pay for their conference ticket? Or ?
15:01:23 <bexelbie> it'd be nice to have the system be able to know if someone paid
15:01:27 <bexelbie> puiterwijk, conference ticket
15:01:33 <bexelbie> and funding co-pay, if any
15:01:36 <puiterwijk> Ah, right. It can display that, that's fine
15:01:49 <bexelbie> basically, we look to the system for bookkeeping
15:01:57 <puiterwijk> Okay.
15:02:13 <puiterwijk> So, if people co-pay for flight tickets, they'd just pay via the same paypal system as the conference ticket?
15:02:39 <bexelbie> puiterwijk, yes
15:02:47 <puiterwijk> Okay. That's fine, and doable
15:02:48 <bexelbie> just a different amount
15:02:52 <puiterwijk> Right.
15:03:04 <stickster> puiterwijk: bexelbie: Have you guys considered the idea that if this gets more complicated than paypal (i.e. Red Hat says no to that), we don't necessarily want to invest in rewriting EventBrite?
15:03:22 <bexelbie> stickster, we've basically rewritten eventbrite already
15:03:38 <bexelbie> all it does is collect data and trigger tickets
15:03:44 <bexelbie> taht is what this does, aiui
15:03:55 <bexelbie> if they say no to Paypal we may not want to invest in building a new payment gateway
15:04:00 <puiterwijk> stickster: I had not. I was working under the assumption paypal would work. If not, we need to figure out some other way
15:04:00 <bexelbie> but we haven't discussed that yet
15:04:37 <stickster> All I'm saying is, we need to keep the development effort here reasonably sized -- the requirements may not be as complex as it sounds
15:05:03 <stickster> I'm not sure I'd classify regcfp as "rewrite of EventBrite" given their feature list https://www.eventbrite.com/features/
15:05:04 <puiterwijk> stickster: yeah, I think most of the requirements aren't very complex, outside of the payment gateway thing
15:05:22 * bexelbie is expecting to get Paypal ... but we shall see
15:05:38 <stickster> OK
15:05:50 <puiterwijk> bexelbie: do we have any clue when we have certainty on that?
15:05:54 <stickster> I think the ~May 1 start date will help us keep the development constrained to the right size
15:05:56 <bexelbie> not yet
15:06:01 <puiterwijk> Okay
15:06:18 <bexelbie> if we get closer and don't have a confirmed answer we will come up with an interim solution
15:06:25 <puiterwijk> I'll get in touch regarding requirements from my side if we want to use it
15:06:29 <bexelbie> I'd rather not contingency plan today for something that may not be needed
15:06:34 <bexelbie> puiterwijk, perfect
15:06:34 <stickster> bexelbie: might help to lay the reg deadline down... if that doesn't work, then I would advise "seek forgiveness later rather than permission now"
15:06:54 <puiterwijk> bexelbie: worst case we could register people as "will pay later", and then see about gateway implementation.
15:06:54 <bexelbie> stickster, basically what I said above :)
15:07:20 <stickster> *jinx
15:07:21 <bexelbie> puiterwijk, I presume that if we had an answer by next week this time we are still good?
15:07:31 <puiterwijk> bexelbie: yes.
15:07:36 <bexelbie> puiterwijk, ok, cool
15:07:48 <puiterwijk> bexelbie: as long as the person having access to the paypal account has a reasonable turnaround time :)
15:08:06 <bexelbie> puiterwijk, absolutely
15:08:17 <puiterwijk> Since I do need the owner of the account to get me an API key to request payments under that account
15:08:39 <puiterwijk> (and yes, I do require a very limited set of permissions. But without that, there's not much integration I can do)
15:08:53 <bexelbie> puiterwijk, of course
15:09:11 <puiterwijk> Okay, good. Just wanted to make sure you're aware that that'll be required :)
15:09:26 <bexelbie> puiterwijk, I've integrated with PP before
15:09:29 <puiterwijk> For some reason paypal won't let me send payment requests as someone I don't know yet!
15:09:30 <bexelbie> it is icky - but do-able
15:09:37 <bexelbie> puiterwijk, for shame
15:09:44 <puiterwijk> bexelbie: yeah, I know. I've done it a couple of times now.
15:10:03 <puiterwijk> At least they now have limited API keys. They didn't have those in the past
15:10:27 <puiterwijk> Anyway, that's the questions I need answered at this moment I think
15:10:47 <mizmo> #action mizmo to mock up travel request mini-form for registration form
15:11:00 <puiterwijk> mizmo++ thank you
15:11:14 <stickster> puiterwijk: bexelbie: mizmo: Should we reassemble in ~1 week to see how things are going?
15:11:20 <bexelbie> stickster, sure
15:11:24 <mizmo> puiterwijk: is there a running instance now that i can take some screen grabs from?
15:11:29 <puiterwijk> stickster: sounds good
15:11:36 <mizmo> stickster: +1
15:11:43 <stickster> #action puiterwijk set up check-in for next week at mutually convenient time
15:11:48 <puiterwijk> mizmo: I don't think I've ever turned regcfp.fedorainfracloud.org down... If I have, I'll see :)
15:12:03 * mizmo tries it
15:12:14 <puiterwijk> mizmo: seems like I have turned it off :). I'll get you something in a few minutes
15:12:22 <mizmo> ok thanks!
15:12:51 <puiterwijk> Let's call it a meeting then, so nobody can suddenly drop a new requirement! :)
15:13:16 <puiterwijk> Unless anyone has any further questions/remarks?
15:13:43 <mizmo> i'll send the minutes to flock-planning@ ?
15:14:01 <puiterwijk> mizmo: that'd be great
15:15:00 <stickster> lol
15:15:05 <puiterwijk> If nothing else, let's close out. Thanks everyone for coming, and if there's any further questions, I'll be around
15:15:12 <stickster> +1 good to go
15:15:14 <puiterwijk> #endmeeting