Insight notes from FUDCon Blacksburg 2012-01-15

Non-goals:

 * Groupware - we are not trying to (re)invent a system for appointments.
 * No zodbot integration yet.
 * Not a separate server calendar.fp.o -- this will be at Insight

Justin O'Brien

 * Keeps a personal schedule of events that he's interested in
 * Only want to see the events he cares about
 * Useful to filter based on location
 * Or tag things as either relevant or not (disappear/retain)
 * Might plan up to a year out, but nowadays more like a month
 * list may be more useful than the standard 30-day calendar view, when you are looking a few months out
 * also for some kinds of meeting needs, a linear timeline with milestones might be helpful
 * John Poelstra also used a list along with a "You are Here" point in a list of milestones, which he found useful

Robyn Bergeron

 * Is there some hierarchy calendar can provide? "I want to see everything in this list or that one"
 * preferences should be "sticky" for the user
 * can we pull information from other places, or do they have to be manually entered?
 * RSS feeds, .ics files import are possible and would be useful (is it push or pull?)
 * When Fedora schedule is updated, she runs a script that writes the rendering out to her fedorapeople.org space
 * Creates the big master version, as well as specific task lists for certain teams
 * eg. http://people.fedoraproject.org/~rbergero/schedules/f-17/
 * Robyn should not have to enter things twice
 * Need to import ICS from her site on some schedule, so Insight is always up to date
 * Only thing Robyn adds is to update fp.o/wiki/Schedule with the 7-8 major project milestones (Alpha, Beta, GA, freezes, etc.)
 * Fedora meeting channel -- is there a way to handle this as meetings?
 * Need to "schedule" the meeting channel as a resource; meeting owners need to find easily when #fedora-meeting is available
 * AGREED: Meeting channel automation doesn't gain us enough for the pain right now
 * Future idea: Send configuration info to Zodbot to allow him to run meeting channel (topic, etc.)
 * should the view change based on whether one is logged in or not? Generic view=unauthenticated; customized view=authenticated
 * how much granularity for generic view?
 * if you're not logged in, we don't know what your role is or where you are located
 * generic list of high-level project milestones and Events shown to unauthenticated users
 * Robyn uses TaskJuggler to organize these
 * Robyn would apply a specialized tag to TJ tasks so they could come out on the non-authenticated, general users view
 * based on FAS information, add these roles to authenticated users' profiles; we would be selective for these, because there are thousands of them

Jared Smith

 * Tagging by region/geo
 * When schedule slips happen, make sure we don't have duplicate entries for project milestones
 * jsmith and asrob to investigate which modules we need to consume .ics files

General Notes

 * We want to change the user's page/view based on group membership, *not* require the user to go to many different pages to find information for their different groups.


 * We want to replace the wiki Events page, not push/pull with it. If we can't get at least the same level of functionality from Insight, we should give up ;-)


 * What should the user be able to do when authenticated?
 * Project calendar
 * Users can't change the project schedule directly, but we want to encourage people to contact Robyn with suggestions or input
 * Send input to a FH ticket where the user can fill out details -- that way the idea is tracked, and FPM can grab the ideas when fixing the next schedule -- use a URL-template to send the user to the right place
 * "people" oriented calendar
 * Contact the person/team who owns an event
 * Auto-CC the list
 * user preference: allow the user to add other team meetings that they do *not* belong to, but may want to follow; checkboxes for personalization
 * for new users, reuse the six main groups on the 'Join' page to start with
 * also offer the ability to geo-limit or show all geo regions
 * Add or edit event
 * when events are added, user might not be the owner, but usually they are, or at least on the team; we could present an 'owner' field, where they could fill this in, but this would need to be verified
 * Include either choices or taxonomy entries for region, team, etc.
 * what about geo-tagging?
 * Remove event
 * Don't build a lot of rules around this. If you're authenticated you can remove things. Like a wiki, trust people to do the right thing.
 * Filter to show just meetings, just events, or both


 * needed: whitelist insight origination email address (insight@fp.o?) to be able to send email to mailing lists
 * Will need to pre-announce opening of meeting calendar, so people have chance to get the wiki page right/reliable at a known zero point
 * Idea is to enable workflows around both events and meetings -- email notices in advance for milestones, etc


 * of the three use cases, which should we do first? Events perhaps has the highest payback, because: 1) it has dollars associated with it; 2) it impacts a larger number of people; 3) high visibility external to the Project


 * adding Team Meetings after this is not very much additional technical implementation; the stakeholders are different, but it increases the scope of what calendar is used for with relatively little additional effortWhat is a FAD like?


 * the Release Schedule gets quite a bit different, so this should likely follow the first two

Next Steps
Critical items:


 * 1) project management
 * 2) * define tasks, assign them, track them
 * 3) communication
 * 4) * we need to engage members of the FP and recruit others who have Drupal skills to this effort
 * 5) * Maria can help with raising awareness of Insight across the FP
 * 6) technical capacity
 * 7) * we need more people to do the technical development/implementation


 * start with defining data model, content types, taxonomies, etc. before actual presentation and workflow from user perspective


 * calendar module in D7 is 3.0 alpha release 2, so this is still unstable, and will need to be tested, but this is a six month project, so let's assume to move ahead on D7 implementation for this

Actions:

 * 1) Evaluate packaging details above -- make sure other modules we know we need are in production status (or acceptable otherwise)
 * 2) start articulating data model needs, content type, taxonomies for Events
 * 3) figure out what Drupal module(s) we might need to support automation (emails out based on event dates, etc.)
 * 4) establish insight@fedoraproject.org alias and start added to the lists for Event cases

LATER: also push outbound notifications to Fedora twitter/identi.ca accounts; find someone to do this separately; note that notices to this will be shorter than the verbose email list info