#summary A discussion page for what would be useful preferences for users to be able to set, and how to implement same.
#labels Importance-Details,Phase-Design,Contents-Draft

= User Preferences Discussion  =

Discussion of this topic stems from [http://code.google.com/p/soc/issues/detail?id=619 Issue 619].

What are preferences that users would like to see set in Melange? What does implementing these preferences look like? Please feel free to improve this page. 

= Possible Preferences =

*If we had preferences right now:*

  * Use a text box rather than TinyMCE as my editor
  * Do not show balloon help
  * Do not show feeds
  * Default to 100 items per page for tables
  * Show (named static document) in place of tree sidebar
  * Use (named style sheet) for look-and-feel

  * Frequency of notifications (Issue 561), e.g. abridged list.
    # no notification
    # one abridged notification until I log in: a single liner email with the URL to the detailed list of notification
    # grouped notifications every 24 hours: similar to digest mode of mailing list - a concatenation of individual notifications (see below)
    # individual e-mail notification of all events - each notification would be a plain text message with all the new information, e.g. the proposal to which a comment refers, as well as the text of the comment itself. I don't want to have to click myself through a web browser into melange to get the information that could be delivered to my inbox.
  * (if Admin) E-mails for all admin events like 'would like to be a mentor'
  * (if mentor) E-mails for all student updates and comments to proposals
  * (if mentor) E-mails for all mentor updates and comments to proposals
  * (if student) E-mails for all mentor comments

*scope of preference*

We may want finer grained notification preferences, particularly in large organizations, for example just to get notifications on students whose proposals I have tagged.  Issue 560 makes the point that a single simple global preference is not sufficient.

a preference is a user-decision that is repeatedly applicable to the same scope/situation as it arises again and again. Not all student proposals are equal and so they can not be considered to be the same scope. A mentor that subscribes to updates on a particular student proposal does not imply a preference for the same subscription pattern on all other students proposals. Hence Issue 560 which IMO is not a global preference, and has nothing to do with the size of an organization. It may or may not be useful to have default subscription preferences. It is more important to me to determine on a case by case basis for each proposal how I want to be subscribed. The improvement described in Issue 560 is the case by case basis that IMO makes sense for every mentor in an organization with more than two proposals.


*Possible preferences in future:*
  *