Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

Agenda

  1. Feedback on library at http://uidesignpatternsosdpl.fluidproject.org
  2. Discussion questions
    • Goal definition: 
      • At http://wiki.fluidproject.org/display/fluid/Design+Patterns+Library+Proposal, our proposed goal reads: "The primary goal of the design pattern library will be to introduce design patterns as a way to design usable, high-quality user interfaces in specific contexts ("a proven solution to a common problem in a specified context"). The library will have a practical focus, intended mostly as a tool for junior/new designers as well as developers. It will not focus on creating a complete pattern language, or describing patterns in a more academic sense." Is this the best statement of our goal? Can we add to this and flesh it out more?
    • Who is the audience of the OSDPL?
      • Are we trying to serve too many different audiences, and if so, should we try to pick a primary audience to serve? Is it possible to pick a primary audience to focus on where if we serve their needs, we will end up serving most of the needs of our other audiences? (This is a similar concept to picking a primary persona on whom to focus a website or application's design. In this situation we also try to meet the needs of secondary personas, but never to the detriment of the primary persona's experience.)
  3. There have been problems sending to multiple mailing lists, so how should we have discussions? Drupal Forum? Low traffic fluid-talk? New design pattern-specific mailing lists?
  4. How should we update patterns as we come up with more information? Review by this group, or just update? (http://issues.fluidproject.org/browse/FLUID-3310)
    • Larger question: what should the workflow be? See Jonathan's suggested  workflow below. Request feedback.*
  5. Sign up for work
  6. Revisit meeting schedule

...

...

In #4 above, I am not sure technically how this can be done and what flexibility Drupal offers in terms of permissions. Ideally we would like to have real fine granuality: assign edit permissions to users on a per post basis. assign edit permissions to a group (moderator / editor group). (Note from Allison: Some of this functionality may be in Drupal's permissions system, but if it's not enough Organic Groups may be answer to this.)

OSDPL Users

  • anyone can sign up for an account.
  • any account holder can create and edit their own content.
  • any account holder can rank a polished pattern
  • any account holder can be involved in discussions through the comment system

Anonymous Users:

  • View privileges only. No other rights

Pattern Editor:

  • Content author can assign edit rights to their own content to other OSDPL users.
  • Not sure how this can be accomplished on Drupal.

Moderator / Editor:

  • Same as an OSPL user
  • can edit any pattern and comment.

Administrator:

  • the poor sod who has to look after the plumbing. (wink)