Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Notes

There is a need to maintain the lifecycle of portlets. From beginning to end there needs to be ownership of content and an understanding of maintenance from anyone wanting to develop content in the portal. Also, who should be contacted if the portlet fails? An agreement with the help desk or support team?

Discussion about looking to extend portlet manager to possibly incorporate this.

Metadata

  • Functional Owner
  • Technical Owner
  • Planned outages and custom error messages

Actual Data

  • On what layouts?
  • How many users have added it to their layout?

Things to consider

  • Support arbitrary number of CPDs in global CPD registry; add a global CPD; more default metadata?  Support for arbitrary metadata
    • Bring metadata into portal for monitoring and support workflow; notify the right people;
    • Framework needs to capture the data; then what we do with it is up to institution.
  • Policy question - what should the default metadata grow to be?
  • The portal is usually considered to be 24 X 7 but the content it displays is not, i.e. weekly database maintainence
    • Consider that the framework is able to handle this?

Other Additional Data

Peoplesoft Portal has a content registry that may be worth looking into as something to model against. Hopefully looking for screenshots or more information on this since not all universities have this.

A Portlet?

Maybe a portlet to view the data and metadata. It could also quickly produce reports that export this data.

New Portlet Vetting Process

From Yale:

  • Call to portal team to describe proposed content
  • Portal team will facilitate new content
  • Standard set of questions - governance
    • Sla
    • Expectations
    • Registry information
    • How the real estate is used
    • What layout
    • Is there an existing layout
    • Can this new content be combined with existing content
    • SDR
    • Performance review - how do we certify new content?
    • What happens if they have been showing an error page and is not fixed?  What do you do? Disable? Delete?
    • Centralized portlet developers
    • Distributed content providers
    • Ideally content will be delivered through an ESB

From Wisconsin - Note from meeting should be reviewed

  • Service team - leader is a product manager - public face but not highly technical; gathers information; can it use existing infrastructure or needs something new?
  • Info passed to tech team for additional evaluation
  • Topics
    • Who will do the work
    • How paid for
    • Guidelines for content
    • Branding
    • Look and feel
    • Performance
  • QA Environment
    • Content provider responsible for testing and final QA
    • Load testing runs automatically
  • Before go-live
    • Help desk document
      • Who to contact
      • Documentation for knowledgebase - internal and external
      • How should calls be handled

Related JIRA Issue(s)

...

Wiki Markup
h2. Notes

There is a need to maintain the lifecycle of portlets. From beginning to end there needs to be ownership of content and an understanding of maintenance from anyone wanting to develop content in the portal. Also, who should be contacted if the portlet fails? An agreement with the help desk or support team? All content should have a functional and technical stakeholder.


Discussion about looking to extend portlet manager to possibly incorporate this.

h2. Metadata

* Functional owner, including contact information
* Technical owner, including contact information
* Support plan, e.g. central Help Desk, including contact information
* General SLA information
* Planned outages and custom error messages

h2. Actual Data

* On what layouts?
* How many users have added it to their layout?

h2. Things to consider

* Support      arbitrary number of CPDs in global CPD registry; add a global CPD; more      default metadata?  Support for      arbitrary metadata
** Bring      metadata into portal for monitoring and support workflow; notify the right      people;
** Framework      needs to capture the data; then what we do with it is up to institution.
* Policy question - what should the default metadata grow to be?
* The portal is usually considered to be 24 X 7 but the content it displays is not, i.e. weekly database maintainence
** Consider that the framework is able to handle this?

h2. Other Additional Data

Peoplesoft Portal has a content registry that may be worth looking into as something to model against. Hopefully looking for screenshots or more information on this since not all universities have this.

h2. A Portlet?

Maybe a portlet to view the data and metadata. It could also quickly produce reports that export this data for external reporting options.


h2. New Portlet Vetting Process

From Yale:
* For new content, a call      to portal team to describe proposed content
* There are Portlet and Content Developers. The later is expected to NOT develop and deploy JSR-168 Portlets, but instead provide a backend service that generates XML (e.g. REST,  Web Service)
* <!-- 		@page { size: 8.5in 11in; margin: 0.79in } 		P { margin-bottom: 0.08in } 	--><!-- 		@page { size: 8.5in 11in; margin: 0.79in } 		P { margin-bottom: 0.08in } 	-->\\
All new content looking to be published to Portal is considered a new project (or sub-project). The Portal team will facilitate, however not necessarily manage the project.\\
* Looking to establish a standard      set of questions - governance
** SLA expectations
** Registry       information
** Review of how       the portal real estate is used
** What       layout should content be included
** Is       there an existing layout
** Can       this new content be combined with existing content
** SDR
** Performance       review - how do we certify new content?
** What       happens if they have been showing an error page and is not fixed?&nbsp; What do you do? Disable? Delete?
** Centralized       portlet developers
** Distributed       content providers
** Ideally content will be delivered through an ESB

From Wisconsin: (Note from meeting should be reviewed)
* Service team - leader is a product manager - public face but not highly technical; gathers information; can it use existing infrastructure or needs something new?
* Info passed to tech team for additional evaluation
* Topics
** Who will do the work
** How paid for
** Guidelines for content
** Branding
** Look and feel
** Performance
* QA Environment
** Content provider responsible for testing and final QA
** Load testing runs automatically
* Before go-live
** Help desk document
*** Who to contact
*** Documentation for knowledgebase - internal and external
*** How should calls be handled&nbsp; <!-- 		@page { size: 8.5in 11in; margin: 0.79in } 		P { margin-bottom: 0.08in } 	-->
h2. Possible Actionable steps

* Consider voting and commenting on Jira issue: [UP-2047 - Create administrative portlet for managing channels, groups, and permissions|http://www.ja-sig.org/issues/browse/UP-2047]
* Wisconsin and&nbsp; Yale should look to publish their current content deployment process and procedure,{ size: 8.5in 11in; margin: 0.79in } 		P { margin-bottom: 0.08in with intent to produce a "reference best practice" document.