Agenda:

• Handling of student employees
• Sharing of code, data & content
  • code update notifications
  • user support
• Sharing/pooling programming resources & expertise
• Producing aggregated search results
• Possible solutions:
  • Possibility of merging the two projects into one portal service -- pros and cons
  • other solutions/approaches

Issues:

• User populations that cross boundaries:
  • Student employees
  • Faculty
• Aggregating search results
• Announcement double-entry
• Calendar sharing
• Common code & libraries

Proposed solutions:

• Merge two portals into one with different "store fronts":

  Pros	Cons
  Seamless user experience	What to use host name, logo, etc?
  Sharing of code & accessing shared libraries is easier	May have too many tabs/fragments to load
  One set of announcements, no duplication	May have too many tabs to display
  Unified look and feel	We may want different looks for SNAP and student portal
  Leverage the technical and hardware resources	Which community controls the announcements, layout, look, etc?
  Redundancy	Differences in design philosophies
  Aggregated search results	Increased usage load
  Best practices	Governance/control/decision making?

• Shared database:
  • Common user lists, groups, announcements, channels, permissions store
  • Allows us to setup the two portals as backups for each other (possibly?)
  • SNAP would have to move to MySQL: a big job, but doable
• Somehow link the databases
• Setup data feeds (may only be possible in batch mode)
• Make AdCom code and libraries available with update notifications
• Make Student Portal code and libraries available with update notifications