From Fedora Project Wiki

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

User input

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
    • 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
    • define tasks, assign them, track them
  2. communication
    • we need to engage members of the FP and recruit others who have Drupal skills to this effort
    • Maria can help with raising awareness of Insight across the FP
  3. technical capacity
    • 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

Retrieved from "https://fedoraproject.org/w/index.php?title=Insight_notes_from_FUDCon_Blacksburg_2012-01-15&oldid=268692"