Insight notes from FUDCon Blacksburg 2012-01-15
From FedoraProject
Contents |
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
- Project calendar
- 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:
- project management
- define tasks, assign them, track them
- 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
- 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:
- Evaluate packaging details above -- make sure other modules we know we need are in production status (or acceptable otherwise)
- start articulating data model needs, content type, taxonomies for Events
- figure out what Drupal module(s) we might need to support automation (emails out based on event dates, etc.)
- 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
