20:02:29 <pcalarco> #startmeeting Fedora Insight
20:02:29 <zodbot> Meeting started Tue Aug 23 20:02:29 2011 UTC.  The chair is pcalarco. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:02:41 <pcalarco> #chair stickster asrob
20:02:41 <zodbot> Current chairs: asrob pcalarco stickster
20:02:43 <stickster> #meetingname Insight
20:02:43 <zodbot> The meeting name has been set to 'insight'
20:02:56 <pcalarco> #topic Roll call
20:03:01 * stickster o/
20:03:07 <pcalarco> is here
20:04:15 <asrob> hi
20:04:45 <pcalarco> are we it?  I see nirik online
20:05:05 <nirik> kinda busy today... but lurking around some.
20:05:24 <pcalarco> nirik: okay Hi nirik
20:05:29 <pcalarco> #chair nirik
20:05:29 <zodbot> Current chairs: asrob nirik pcalarco stickster
20:05:43 <pcalarco> #topic review of last meeting
20:05:59 <pcalarco> #link http://meetbot.fedoraproject.org/fedora-meeting/2011-08-16/insight.2011-08-16-20.04.html
20:06:59 <pcalarco> any updates from last week?
20:07:01 <stickster> #info stickster has features_extra and strongarm modules now part of puppet manifest for all insight hosts (dev, stg, prod)
20:07:15 <pcalarco> Great!
20:07:38 <stickster> #action stickster Finish setting up pull of fedora-insight-features on stg and prod hosts (30 min for stg, 4 hrs for prod)
20:07:54 <pcalarco> stickster: is there any future module puppet work remaining at this point?
20:08:06 <pcalarco> ah ok
20:08:10 <stickster> pcalarco: Just the git repo work
20:08:34 <pcalarco> ok, great, thanks for that good work, stickster!
20:08:35 <stickster> That's not terribly difficult -- but I need some uninterrupted time to test on staging before I get it anywhere near the production host :-)'
20:09:19 <stickster> #info stickster also enabled the Features module on both hosts, which is next step down that path
20:09:24 <pcalarco> my action item was to clean up the Insight Calendar use case page into priorities as we discussed last week
20:09:29 <pcalarco> #link https://fedoraproject.org/wiki/Insight_use_cases_for_calendar
20:09:55 <pcalarco> Thanks, asrob for responding to this on logistics
20:10:00 <asrob> no problem
20:10:35 <stickster> pcalarco: I read through the first part of the page but got interrupted
20:10:49 <pcalarco> have you had a chance to think about which modules might be involved, and if they are drupal 7 ready?
20:11:23 <stickster> Am I understanding "Team meetings" right that the goal is to have zodbot (or some bot) interface with the calendar to take care of team meeting schedules?
20:11:43 <pcalarco> boy, that would be nice
20:12:03 <nirik> well, that would be great, but also replace the wiki page for irc meeting schedules too.
20:12:25 <stickster> pcalarco: It would -- but the question is whether Drupal has an interface (in 6 or 7) that supports that
20:12:45 <stickster> My understanding is that an external API is a D8 target but not available yet
20:13:09 <nirik> zodbot can read rss feeds... so if there's a '15min before meeting' and a 'meeting time' feed it could announce those...
20:13:21 <pcalarco> I think the next step might be to iterate over the requirements more specifically, and identify modules that can be used, and identify any gaps in functionality
20:13:42 <stickster> nirik: Sure. But what I mean is, maybe we should separate that from being able to remotely input information into Insight
20:13:55 <nirik> sure, agreed.
20:13:57 <stickster> Read and announce, I'm totally down with that.
20:14:31 <stickster> And I like the zodbot-scheduling idea a lot too, I just hesitate because I think D6/D7 core are not yet capable of that level yet
20:14:56 <stickster> Although...
20:14:58 <asrob> is there a zodbot API or something like that?
20:15:14 <nirik> yeah, thats rainbows. I think we really need to get a base workable thing before we try for fancy.
20:15:32 <stickster> asrob: Not really, but there *is* an xmlrpc available, you just have to provide a lot more of the HTTP request info... nothing pretty and programmatic yet
20:15:36 <nirik> asrob: it's a supybot. It's got a lot of modules.
20:15:52 <asrob> I see
20:15:54 <stickster> asrob: Sorry, I was answering "Drupal API," not "zodbot API." My fault.
20:16:05 <stickster> Listen to nirik, he's always been smarter than I.
20:16:12 <asrob> :)
20:16:21 <stickster> And he reads more carefully, too.
20:16:36 <stickster> Did I mention he's more handsome? And has more hair.
20:16:48 <asrob> :))
20:16:58 * nirik blushes.
20:16:58 <pcalarco> :)
20:17:21 <asrob> hm, xmlrpc, just a note: http://groups.drupal.org/node/50008
20:17:44 <stickster> asrob: OK, hrmph. :-(
20:18:13 <asrob> and http://drupal.org/project/services
20:18:15 <stickster> http://drupal.org/project/services
20:18:17 <stickster> ha!
20:18:23 <stickster> That's looking up a bit.
20:18:30 <stickster> asrob: My bet is that will be absorbed into D8
20:18:43 <stickster> Or something like it
20:19:02 <asrob> yeah, it's possible, there is an web services iteration ;)
20:20:13 <stickster> OK, so enough on the xmlrpc angle -- the point is, pcalarco, we should probably separate this out a bit
20:20:49 <stickster> pcalarco: So the team meeting use case is something more like "check and schedule on the web"
20:21:03 <stickster> With the IRC part moving out to a longer term use case
20:21:33 <stickster> Or maybe keeping the "zodbot reads RSS and announces" in the short term, and only moving the "zodbot can schedule for you" part into longer-term.
20:21:38 <pcalarco> stickster: agreed; this could start as manual and automation/integration follow
20:22:24 <pcalarco> asrob, stickster: do we know what modules we're likely needing to consider for Calendar functionality?
20:22:25 <stickster> Assuming our feature workflow does perform like it should... people will basically be able to work on the parts of Insight they care about most.
20:22:40 <stickster> Jeez, I don't know. I would assume Event and Calendar.
20:23:04 <asrob> event is not necessary
20:23:33 <pcalarco> so next steps would be to get those packaged and on stg and then play around with them to see their functionality?
20:23:42 <stickster> Ugh, Event looks like it's perpetually in "dev" status
20:23:49 <stickster> asrob: Ah, good news!
20:23:59 <asrob> calendar and date, but if we switch to D7 then date not sure to have to use
20:25:08 <asrob> hm, yes, we should use calendar and date modules on D7 as well
20:25:13 <stickster> #topic Use cases and modules
20:25:41 <stickster> #info asrob advises Calendar + Date are probably most likely targets for "Team meeting" use case
20:25:47 <asrob> +1
20:26:30 <stickster> #action pcalarco Separate out "Use web to check and schedule," "Zodbot reads RSS and announces meetings," and "Zodbot can schedule things for users with the right permissions" items
20:26:48 <pcalarco> +1
20:27:21 <stickster> What else do we need to know for that use case right now?
20:27:27 <stickster> Else we can move on to the next one
20:27:36 <pcalarco> what do we need to do to start testing?
20:27:56 <stickster> pcalarco: I think that's a general workflow question answered here: https://fedoraproject.org/wiki/How_to_develop_for_Insight
20:28:17 <stickster> pcalarco: We should probably try to get through the other use cases, at least the short term ones you've put together here
20:28:36 <asrob> cool, date and calendar are already packaged
20:28:39 <pcalarco> sounds good
20:28:41 <stickster> asrob: Yup!
20:29:00 <pcalarco> Ok, Fedora Release Schedule is next
20:29:01 <stickster> #action stickster Review and update https://fedoraproject.org/wiki/How_to_develop_for_Insight to match new feature pulling capability
20:29:37 <stickster> I need to fix that page since it will be possible to simply push changes to a git branch and have the server pull them down.
20:29:52 <pcalarco> How is this different than the team meetings, other than a different meeting type?
20:30:32 <pcalarco> a release schedule may not have a specific time
20:30:33 <stickster> pcalarco: Good question. It looks like on the back end, there might be a difference, but to a user, it's all the same -- they're looking for a certain kind of event, whether it's an event or a release milestone.
20:31:04 <stickster> +1, no specific time. But otherwise it can all be represented on the same calendar view of "things happening today/this week/this month"
20:31:16 <pcalarco> yes, +1
20:31:49 <stickster> pcalarco: Preferably, the change I would make here is we don't want someone to have to enter in dates. Ideally, they would come from a URL provided either by us or by a user with permissions like rbergeron
20:32:12 <stickster> When the Fedora schedule changes for some reason, like a slip, the dates would automatically adjust in the Insight calendar.
20:32:40 <pcalarco> so if we had a node that could represent EventType, and these defined for TeamMeeting, ReleaseSchedule, FedoraEvent, we'd be golden?
20:33:08 <stickster> At a minimum those would do, I think
20:33:56 <asrob> I like this
20:34:16 <asrob> these calendar idea will be interesting :)
20:34:29 <asrob> +s
20:34:54 <pcalarco> stickster: how will the module parse dates out from a URL?
20:35:09 <asrob> another good question ;)
20:35:10 <stickster> pcalarco: From the .ics that rbergeron already produces, for instance
20:35:21 <pcalarco> ah, okay :)
20:35:26 <stickster> e.g. http://people.fedoraproject.org/~rbergero/schedules/f-16/f-16-key.ics
20:35:49 <stickster> (or one of the ICS files, not necessarily that one)
20:35:50 <pcalarco> how clever
20:36:43 <pcalarco> does the Dates module support ICS parsing then?
20:37:03 <stickster> pcalarco: I have no idea
20:37:18 <asrob> I think, yeah, they(date and calendar) handle it
20:38:17 <stickster> asrob: Yeah, Views + Calendar looks like it may work
20:38:19 <pcalarco> #info for release schedule, Calendar and Date modules would ideally parse ICS files for date population in the calendar
20:38:35 <asrob> and tada... http://drupal.org/project/parser_ical ;)
20:39:21 <pcalarco> asrob: nice!
20:39:32 <stickster> asrob: That looks like another "mostly done" project though.
20:39:40 <asrob> yep
20:39:42 <stickster> Views + Calendar are probably our best bet.
20:39:45 <pcalarco> yes, no v.7 branch
20:40:37 <stickster> pcalarco: OK, so anything else we need to capture for this use case?
20:40:44 <pcalarco> #info Views and Calendar likely modules for Release Schedule use case
20:40:59 <pcalarco> no, I think we can move on to Events
20:41:34 <pcalarco> the only difference here, I thought, might be a filter on Region
20:42:07 <stickster> So that implies a property that the other date-types don't have
20:42:47 <pcalarco> Actually Team meetings might share this as well, thinking of the Ambassador regional meetings, for example
20:42:48 <stickster> Which is fine. We'll just need to keep that in mind, because it will add a filtering step only when the user is looking for events, and shouldn't affect the other types like meetings and release schedule items.
20:42:55 <stickster> pcalarco: Hm, good point
20:43:29 <stickster> Well, I think that will work itself out in the wash, basically.
20:43:36 <stickster> No need for us to cover implementation details here in this meeting.
20:43:39 <pcalarco> +1
20:43:43 <asrob> +1
20:43:45 <stickster> The use case makes sense to me.
20:43:56 <pcalarco> if needed, we could simply apply all regions to the release schedule
20:44:06 <stickster> True
20:44:30 <pcalarco> anything left on Events?
20:44:34 <stickster> --
20:44:35 <asrob> -
20:45:03 <stickster> pcalarco: wrt. the TZ support for Insight... I have a feeling Drupal already does this as part of core. And the Calendar should basically take care of that too.
20:45:22 <pcalarco> Ok, so then the use cases below that I thought might be longer term, starting with timezone support.  Would we get this in Calendar + Views?
20:45:26 <stickster> Were you thinking of something more complicated than being able to enter a meeting in either your TZ or a different TZ (including UTC)?
20:45:38 <pcalarco> nope, that was it basically
20:45:52 <pcalarco> then the attendees could localize this into their local time
20:46:09 <stickster> asrob: Speak up if you think differently... but my recollection is that the core + Calendar + Date all handle this pretty readily.
20:46:10 <asrob> +1, that would be nice
20:46:20 <pcalarco> that's great if Calendar would help with this
20:46:34 <stickster> My user profile has a TZ attached. And if I look at a Calendar, it ought to be shown in my TZ.
20:46:42 <asrob> stickster, yeah, and in D7 you can choose your TZ
20:46:52 <stickster> asrob: Can I do that in D6? I thought I could.
20:47:08 <asrob> stickster, yeah, you can
20:47:19 <asrob> Date + Calendar ;)
20:47:40 <stickster> Yup, I see the TZ setting in my user profile on Isnight.
20:47:53 <stickster> So this shouldn't be too much of an issue, pcalarco
20:48:09 <stickster> Certainly we should make sure the UI is such that people can enter meetings at either UTC or their local time
20:48:15 <stickster> (or heck, any TZ)
20:48:34 <pcalarco> great, move on to next?
20:48:40 <asrob> yeah
20:49:20 <pcalarco> so, I also thought there might be need for additional fields for shipping things like EventBoxes and Ambassador Kits related to Events
20:49:40 <pcalarco> not sure if that needs to follow later or can be integrated up front
20:50:08 <stickster> Hm, this does sound like a later follow-on... but something where we could attach fields early on, but then have them actually *do* something using a Trigger later
20:50:46 <stickster> Eventually, it would be great if someone could register their Event and the proper tickets would be entered for them (or they're redirected properly with everything pre-filled into a ticket)
20:50:59 <pcalarco> +1
20:51:54 <asrob> hm, this is like a webshop?!
20:52:09 <stickster> That's a heftier bunch of requirements, but it would be an interesting problem to solve :-)
20:52:42 <asrob> because we can use the whole drupal commerce module or (some) part of it
20:53:13 <stickster> Perhaps.
20:53:24 * stickster thinks we can get the easy stuff out the door first :-)
20:53:34 <asrob> :)
20:53:38 <stickster> pcalarco: We should probably leave some time here for asrob to talk about D7
20:53:56 <pcalarco> yes, I think we could actually finish here
20:54:07 <asrob> thanks
20:54:09 <pcalarco> agreed to hand over to asrob?
20:54:15 <stickster> +1
20:54:20 <pcalarco> #topic Drupal 7 discussion
20:54:51 <asrob> so, there was an annoying bug in token module, it didn't support field tokens
20:55:26 <asrob> but it changed, so there is a field token support
20:55:35 <asrob> what does it mean?!
20:56:00 <asrob> today, I built our Insight instance on D7
20:56:23 <asrob> it works but there are two problems
20:56:54 <asrob> 1. there is no D7 version from authfas module
20:57:06 <asrob> 2. there is no D7 version from mediawiki_api
20:57:13 <asrob> that's all
20:57:36 <asrob> everything else is working well
20:57:40 <pcalarco> ok, any new topics?
20:57:55 <stickster> asrob: I can probably make authfas work in D7 without too much trouble
20:58:01 <stickster> Just a matter of learning the new API
20:58:11 <stickster> As for mediawiki_api... not so easy
20:58:43 <stickster> asrob: I'll take that on, but it will probably take me a while to get to it due to $DAYJOB constraints
20:59:00 <stickster> #action stickster Read up on D7 API to see how much work is required to port authfas module
20:59:22 <asrob> yeah, but if we can change to D7, that would be great, we would win a lot
20:59:46 <abadger1999> stickster: gonna jump in here but you can put me off until after the meeting if you like -- would openid serve your auth needs?
21:00:27 <abadger1999> stickster: We wouldn't have to maintain authfas if openid was suitable and we can point it at fas's openid provider.
21:02:28 <stickster> abadger1999: openid is part of Drupal core... but can we support group memberships with that?
21:02:49 <stickster> abadger1999: authfas allows us to have groups of content editors, writers, admins, etc. by tying to FAS groups
21:03:12 <abadger1999> stickster: I don't know.  Is that something you can find out?
21:03:21 <stickster> Drupal supports an arbitrary number of roles where each role can have different permissiosn.
21:03:24 <stickster> *permissions.
21:03:58 <stickster> abadger1999: I think this is an OpenID question, not a Drupal question... I don't know much about OpenID and whether you can pass lists of values with it.
21:04:25 <stickster> abadger1999: The idea is to *not* keep duplicate group assignment info in the Drupal database, but use what's already in FAS instead.
21:04:57 <stickster> I would tend to think OpenID would authenticate, but you'd have to then assign people to groups in Insight
21:05:21 <abadger1999> <nod>
21:05:31 <abadger1999> I don't know openid very well, so I don't know.
21:06:31 <stickster> pcalarco: I think we're over time, I'm basically done
21:06:40 <pcalarco> we are about 5 minutes after our hour; do we want to keep discussing this, or have other topics?
21:06:52 <stickster> asrob: I wouldn't mind switching to D7... but remember we'd have to get a *lot* of packages built for D7 then :-\
21:06:55 <pcalarco> stickster: yes, anything else from anyone?
21:07:17 <stickster> #action stickster Find out whether openid is capable of passing group membership data
21:07:26 <asrob> pcalarco, you can close it
21:07:33 <pcalarco> #endmeeting