#summary Project Documentation for Social Features for Melange(GSoC2010)
#labels Phase-Design,Contents-Draft,Importance-Details

<wiki:toc max_depth="3" />

= Post-GSoC Plan - Delayed/Postponed 2011 =

== Weekly Targets ==

*Week of Jan 9th - Jan 15th*

   * User Pages workflow
   * User Pages Image Upload
   * Clarify about issue of pulling task info with Madhu and work on it

== Issues to be handled ==

Order of Integration (and priority of issues to be resolved):
   * User Pages
   * Maps
   * Calendars
   

=== User Pages ===
|| *Short Name* || *Description* || *Schelduled* || *Priority* || *Primary Contributors* ||
||User Page Image Upload||Enable uploading of Images for User Pages||16 January ||High|| Savitha || 
||User Pages: Pull Task Info||Instead of showing student project info on User Page, get the users Task information also, to make it usable for GHOP/GCI as well || 16 January ||High|| Savitha ||
||Write tests for User Pages ||Testing all code related to User Pages|| ---- ||High||Savitha ||

=== Maps ===

|| *Short Name* || *Description* || *Schelduled* || *Priority* || *Primary Contributors* ||
||Map-View JS data handling||Find out how javascript will handle huge amount of users and events and show them on the map.||23 January ||Medium||Savitha ||
|| Rectify Empty Address Line in Event Pop-out || Format the pop-out windows html to avoid empty lines for missing address fields || 23 January || Medium || Savitha ||
||Map Generation based on Address field value||When filling in the address fields of a form, the Google map should be generated if either or all of the address fields are populated in any order.||23 January ||Medium||Savitha||

=== Calendars ===

|| *Short Name* || *Description* || *Schelduled* || *Priority* || *Primary Contributors* ||
|| Enable Auto-reload of DynaForms || The Calendars list in forms should be reloaded each time a form loads as the list keeps changing based on Calendar activation || TBD || Medium || Savitha ||
||Calendars are being sent from Melange ID || || TBD || Low || Savitha ||
||Calendars API Moved Temp. Error||Error situation on API side|| TBD ||Low|| Savitha ||
||Cron Job to check Event changes||Pull event from Google Calendars and run through them to check for changes from Google Calendar side and update Melange datastore.||TBD || Medium || Savitha ||


=== General ===

|| Add Appropriate Indentation for Community menu || Indent the menu items for the social features correctly/uniformly || 23 January || Medium || Savitha ||
||Testing other parts of project||Testing||TBD ||Medium||Savitha ||

----

== Issues to be handled ==

|| *Short Name* || *Description* || *Schelduled* || *Priority* || *Primary Contributors* ||
|| Enable Auto-reload of DynaForms || The Calendars list in forms should be reloaded each time a form loads as the list keeps changing based on Calendar activation || 30 September || Medium || Savitha ||
|| Add Appropriate Indentation for Community menu || Indent the menu items for the social features correctly/uniformly || 20 September || Medium || Savitha ||
|| Rectify Empty Address Line in Event Pop-out || Format the pop-out windows html to avoid empty lines for missing address fields || 10 October || Medium || Savitha ||
||Map Generation based on Address field value||When filling in the address fields of a form, the Google map should be generated if either or all of the address fields are populated in any order.||15 October ||Medium||Savitha||
|| Calendars are being sent from Melange ID || || TBD || Low || Savitha ||
||Calendars API Moved Temp. Error||Error situation on API side|| TBD ||Low|| Savitha ||
||Cron Job to check Event changes||Pull event from Google Calendars and run through them to check for changes from Google Calendar side and update Melange datastore.||20 October || Medium || Savitha ||
||User Page Image Upload||Enable uploading of Images for User Pages||20 September ||High|| Savitha || 
||User Pages: Pull Task Info||Instead of showing student project info on User Page, get the users Task information also, to make it usable for GHOP/GCI as well || 30th September ||High|| Savitha ||
||Write tests for User Pages ||Testing all code related to User Pages|| 10 October ||High||Savitha ||
||Testing other parts of project||Testing||TBD ||Medium||Savitha ||
||Map-View JS data handling||Find out how javascript will handle huge amount of users and events and show them on the map.||TBD ||Medium||Savitha ||

= Introduction =

  This document will be used to documents the progress and details of the Social Features (GSoC 2010) project for Melange. 


= Project Design and Implementation =

== Main Feature 1: Tabbed User Pages ==

===Overview===
User Page feature will be used by each user to share information about 
themselves with the rest of the GSoC community. The UI of this feature is designed with tabs, 
hence users will remain on a single page while navigating between multiple tabs. The details of this feature's design and implementation are as follows.

The tabs of the user page will be as follows:
   * Profile
   * Project
   * My Stuff (to be renamed later)

===Workflow===

Workflow for Users: 
The workflow for using this feature is largely similar for all user roles in the soc framework, with some differences for the program and organization admins.

Workflow for Student, Mentor, Organization Admin User roles

    
    # User receives acceptance notification email that they have been accepted to participate in the program. A short message is appended to this email, mentioning that users can now update their respective user pages on Melange as well as view other users’ pages.
    # There are two possibilities from here:
      # If users click the link, they are redirected to the profile tab of their user page, where they see their partially filled profile based on current user information provided at sign up (i.e. name, current/past user roles).
      # If they do not click on the email link, whenever they next log into Melange, they will see ‘User Page’ on their sidebar under the ‘User’ tab. Clicking on this will take them to the profile tab of their user page.
    # They may further update the data on their profile tab, or the other two (Project, MyStuff) tabs by clicking on the ‘Edit User Page’ button to be redirected to a form where they can edit/add data for all the three tabs. 
    # The *Profile tab* will display a subset of the properties from the user_page data model. Profile related information such as contact, personal profile details, education and job information will be shown here.
    # In the *Project tab*, students can fill in details of the project they are working on, while mentors can provide details about the project they are mentoring for. Past and Current project data for both mentors and students will be pulled from the database. Users can add on to it using a text field.Organization Admins can use this page to provide information about all their student projects. Program Admins can use this page to provide general information about the GSoC/GHOP program itself.
    # In the *My Stuff tab*, users can click on “Add Blog Feed”, to insert their blog url to display updates from their personal blogs using Melange’s RSS widget. For organization and program admins, there is provision to display two blog feeds. This is to display their own personal blog feed as well their organization/program blog feeds.
    # Once changes are saved, users may return anytime during the course of the program to change and save the information on their user pages.
-----
*Suggestion Incorporated* Comment (Madhu): I think there should be only one edit page where they can edit all the three tabs.
-----   
-----
*Suggestion Incorporated* Comment (Madhu): Nope, that makes the interface too complicated and messy. Or if you would like, don't make it generic, but give Admins options for 2 RSS widgets. Thats the max, not more than that for sure.
-----
    
===Data Models===

*UserPage*

This user_page.py will be the master model for this feature which will enclose the three tabs that make up this feature. The other data models created are for multiple-valued properties such as education, jobs, current/past projects, updates and comments.

The Data Models
  * user_page.py
  * project_details.py (pulled from database) 

Properties of user_page.py
  * user - *ReferenceProperty*         (required)
  * email – *StringProperty*
  * website - *LinkProperty*
  * biography - *TextProperty*
  * profile_picture – *BlobProperty*
  * last_modified - *DateTimeProperty* (required)
  * project_details – *ListProperty*   (required)
  * feed_url - *LinkProperty*
  * user_page_status - *StringProperty*(required)
  * tags - *ListProperty*              (required)

-----
*Suggestion Incorporated* Comment (madhu): I think you must really use tag framework in Melange here and use the tag property.
-----


The User page feature should be in one of the following states implied by the user_page_status property of the model.
 * Visible - This state occurs after the user is accepted into the program. Only the minimal information about the user already entered during registration period is shown on the user page. In this state, the user may edit or add to his user page at any time during the program.
 * Invisible - This state of the user page can be activated by the user if the user wishes to prevent other users from viewing their profile.
 * Invalid - The user account has been terminated.

-----
*Suggestion Incorporated* Comment (Madhu): Status is good, but I don't think Uninitialized, Initialized and Updated is a good idea. Instead we can just have three states like, visible, invisible and invalid.
-----
 

-----
*Suggestion Incorporated* Comment (Madhu): Oh! I am extremely sorry for not making this clear earlier, when you started writing it out, but anyways better late than never. You need not create so many Python files and data models. From what I can see all the files and data models you have specified above can be merged into one single file with one single data model. So many reference properties is not good. Also, even if we keep all the data you have specified in a single data model we can write views in such a way that it shows only what data needs to be shown to a specific user and tabbing etc etc can all be controlled by views and templates. So we might not want so many data models. We will have to redesign this together. 
-----

===Views, Templates & Logic===
*Views*

*_soc.modules.social.views.models.user_page.py_* : Since the user_page feature serves more or less the same purpose for all the different user roles in Melange, a single view will be created.

*Templates*

 * *_soc.templates.modules.social.user_page.view_user_page.html_* : Since the user pages will be tabbed, the entire page will not reload when users switch between tabs. With the help of JavaScript, this can be achieved with a single template with different html div and id tags defining the data to be displayed in different tabs :).

 * *_soc.templates.modules.social.user_page.edit_user_page.html_* : A different template with the html form will be created for the 'Edit User Page' function which will be used to update the user_page.py data model.

*Logic*

*_soc.modules.social.logic.models.user_page.py_* : To handle the edit/update of the user data a logic is created which will be used to update the user_page.py data model.

== Main Feature 2: Maps + Calendars for GSoC ==

===Overview===
This feature consists of two main components. The *Calendars* and *My Community* components. These two components will appear in the sidebar in the User section.

The My Community tab will provide a portal for users to explore all the participants of the program by different categories such as location, organization, project tags etc. Users can can get to know their fellow participants by visiting their user page.

The My Community section also allows user to explore community events by location, organization and tags. Non-admin users can also request to add a new event to the calendar by sending "Add Event" requests to their respective admins with the event details.
The My Community tab provides two views for the above-mentioned activities, a simply list view and a global map view(default).

The Calendars component is used to view only the events such as GSoC meetups, irc meetings, conferences and other related events which might be of interest to the community members. Each user can view the public program calendar and the private organization calendar which is owned by the organization admin and is viewable only by users associated with that organization.


===Workflow===

*My Community*

Workflow for all Users: 
    
    * When users click on 'My Community' in the sidebar, under the 'User' tab, they will be redirected to the _MapView_ which is the default view. Here, they will see a world map which they can manipulate to show either *users or events*.
    * In the _MapView_
         # Once users or events are selected, the map can be further manipulated to show the data based on location, organization and tags(i.e. C#, PHP, Django etc).
            # If users are selected: The map will point to all user locations based on the filters selected. A mouse-over on a particular user, will show a link to user profile, which can be clicked to be directed to the user page.
            # If events are selected: The workflow is same as users, except that events are shown on the map. The users can mouse-over and click on a particular event to view the details as a pop-up widget.
    * In the _ListView_
         # Once users or events are selected, the same filters as above can be applied, except the data will be shown in a text-based list format. Clicking on any row in the list, will lead to the corresponding user page or the pop-up event widget respectively.

*Calendars*

Workflow for Users:

    * All calendars will be hosted under a single Google account owned by the program_admin. When the accepted organizations are announced, a new calendar can be created for each new organization. If organizations have participated in the program previously and they already have a calendar with the account, then that same calendar can be used.
The Google ids of org_admins can be added to their respective org calendars giving them 
rights to publish on their calendar.
Org_admins can be notified about their org_calendar on acceptance. A short message and link can be added in their acceptance notification emails leading them to their org calendar page. (*Note* : Program_admins will have to provide the google account under which the program and org calendars are to be hosted.)
    * Click on 'Calendars' under the User tab in the sidebar. They view a single calendar containing events in the Program calendar as well as the events in their organization calendar. (Organization admins are owners of their respective org calendars.)
    * From this point onwards, users may choose any of the following:
       * *For Admins* Add a new event by clicking on the 'Add Event' button, which will take them to a form where they can fill in the event details and it will be shown on the org calendar.
       * *For Admins* They can choose to approve or decline requests sent by other users to publish events in their calendar by clicking on the 'Requests' button. They will be redirected to a page showing a list of event requests. After inspecting the event details, they can approve or decline the events.
       * *For Non-Admins* User can choose to request to add a new event by clicking on the  'Request Add Event' button. They will be redirected to a similar form as the admins 'Add Event' function. They can submit it and this event will be shown on the respective org or program calendar after it is approved by the respective admin.
       * View user's org events only.
       * View Program events only.
    * Additionally, users can also subscribe to feeds to be notified about events with certain tags.
 
===Data Models===

Currently, the additional data model required here is for the event objects. 

_soc.modules.social.models.event.py_

Properties of for event.py
  * created_by - *ReferenceProperty*  (required)
  * created_on - *DateTimeProperty*   (required)
  * modified_by - *ReferenceProperty*
  * modified_on - *DateTimeProperty*
  * event_name - *StringProperty*     (required)
  * description – *StringProperty*    
  * location – *GeoPtProperty*        (required)
  * is_org_event – *BooleanProperty*  (required)
  * organization - *ReferenceProperty*(required if is_org_event=True)
  * program - *ReferenceProperty*     (required)
  * status - *StringProperty*         (required)
  * time - *DateTimeProperty*         (required)
  * tags - *ListProperty*             (required)

-----
*Suggestion Incorporated* Comment (madhu): 
  # Same as above. You may want to use tag framework for tags. 
  # Also you may want created by and created on along with modified by and modified on properties. 
  # Also you may want to use http://code.google.com/appengine/docs/python/datastore/typesandpropertyclasses.html#GeoPtProperty GeoPtProperty here instead of Lat Lng location float properties. The reason why it was used in previous model was because this property was not in Appengine then. But now we have!
  # You also want reference to program.
-----

An event can only be published in one calendar(i.e. program calendar or org calendar). If is_org_event is true, then it will be published in the current user's org calendar, if is_org_event is set to false, then the event will be published in the program calendar.
These two status properties differentiate the program admin and the org admins.

----
Comment (madhu): Just to warn you, a user may be involved with two or more Organizations. For example, Sverre is mentoring two students this time :P One for Melange and another for Git
----

Based on the calendar(org or program) in which the event is meant to be published, the status property is set to either of the three values.

  * *requested* : If the current user is not the owner of the calendar where the event is to be published, then this state is set by default. When it is approved by the owner, this is set to is_approved.
  * *approved* : If the current user is the owner of the calendar where the event is to be published, then this state is set by default. Else if the event is approved by the owner, this state is set for the event.
  * *declined* : If the calendar owner chooses to decline an event request this state is set.

-----
*Suggestion Incorporated* Comment (madhu): For clarity reasons I think it is better to name these values *requested*, *approved* and *declined* since they are not really Boolean fields but a 3-state property.
-----
=== Calendars in Detail ===

*UseCases for Different User Roles*

Program Admin

http://www.comp.nus.edu.sg/~savitha/gsoc/cal_init.png

"Initialize Calendars" use case simply refers to the automated creation of a new calendar for each accepted Organization and the assigning of access rights for all the org_admins and students at the start of the program.

*Org Admin*

http://www.comp.nus.edu.sg/~savitha/gsoc/org_admin.png

*Student or Mentor*

http://www.comp.nus.edu.sg/~savitha/gsoc/student-mentor.png


*Calendar Types*:
   * *Program Calendar*: This is a completely public calendar which is visible to all users participating in the program including mentors, students, org_admins and program_admins. 
   * *Organization Calendar*: Every accepted organization has its own private calendar which is visible only to users working for that particular organization such as mentors, students and org_admin of that organization.

*Calendar Account*:
    * All the organization calendars and the single program calendar will be hosted in a *single* Google account owned by the program_admin. (this can be the program_admins own account or analternative account such as gsummerofcode@gmail.com where the current program  [http://www.google.com/calendar/hosted/google.com/embed?src=gsummerofcode@gmail.com&ctz=America/Los_Angeles calendar] is being hosted.)
    * Every org_admin will be given owner access to their org calendar. Google's Calendar API provides access control lists for each calendar. Hence, each org_admin can be given owner  access(user can make changes to events) while org students are given read access(this user can see all event details). (Ref: http://code.google.com/apis/calendar/data/1.0/developers_guide_python.html#SharingACalendar)

*Access Rights for User Roles*
When users access their Calendars, the respective calendars and rights will be triggered based on the account in which they are logged in. For example, if bob@gmail.com is an org_admin, and is logged in. He will automatically have "owner" access to his org calendar and "read" access to the program calendar.

*Program_Admin*:
  * Has "owner" access for all org calendars and program calendar

*Org_Admin*:
  * Has "read" access to program calendar.
  * Has "owner" access to their org_calendar.

*Mentors*:
  * Has "read" access to their org calendar and program calendar.

*Student*:
  * Has "read" acess to their org calendar and program calendar.

Users who do not have access to a particular calendar but want to add an event can send requests to the owner who can approve it. This is an internal feature to be implemented within Melange and not visible to Google Calendar API. The calendar will view the event as being added by the owner. (This is depicted in the Calendars User case [http://code.google.com/p/soc/wiki/SocialFeaturesMelangeGSoC2010?ts=1274515831&updated=SocialFeaturesMelangeGSoC2010#Maps_+_Calendar_Feature below]) 

=== APIs & Libraries ===
   * Google Calendars API
   * Google Maps API
   * CalVi's UI library
   * GeoModel (filtering locations, tentative)
 (more coming up...)

-----
Comment (madhu): Want to see them soon. Esp. jQuery plugins for tabbed pages since you are starting with User pages in two days.
-----

== Use-Case Diagrams ==

===User Page Feature===

http://www.comp.nus.edu.sg/~savitha/gsoc/user_page_usecase4.png

===Maps + Calendar Feature===

*Maps*

http://www.comp.nus.edu.sg/~savitha/gsoc/maps_usecase1.png


*Calendars*

http://www.comp.nus.edu.sg/~savitha/gsoc/calendars_usecase2.png

== Latest Workflow (as of Week 7) ==

=== User Pages ===

  # User Pages features are only accessible for those who have been assigned a role.
  # The workflow changes slightly based on the different roles Users will have.
  # User Page entities are Program scoped.

*Student Role* :
  # Users can Register as a Student
  # Upon successful registration, they will see a red highlighted "Create User Page" link on the sidebar.
  # They can click on this to activate the User Pages feature and fill in the User Page forms.
  # Once they create their User Page entity, it will be listed in the "List User Pages" link and all other users will be able to view their page if they have set their User Pages as "Visible".
  # Each User may edit their User Page visibility and other information appearing on their User Page at anytime by selecting "Edit User Page".

*Mentor* :
  # Users can apply to become a mentor for an accepted organization.
  # The respective org_admin then accepts the user as a mentor.
  # The user is then notified of his acceptance as a mentor and made to fill out the mentor registration form.
  # Upon successful registration as mentor, the red highlighted "Create User Page" link will appear.
  # The steps from this point on are same as the Student Role.

*Org Admin and Program Admin*:
  # Upon accepting invitation to be org/program admin, they will be fill in the form to register.
  # Upon successful registration, they will see the red highlighted "Create User Page" link appear on the sidebar.
  # The steps from this point on are same as the Student Role.

===Calendars===

*Calendar Feature Activation*

  # Once the timeline passes the "Accepted Organization Announced" deadline, the program_admin will see a red highlighted "Activate Calendars for Orgs" link on their sidebar.
  # Cliking on this will trigger the creation of one calendar for all accepted organizations.
  # Simultaneously, notifications will be sent to all org_admins about the new feature.
  # Org_Admins can choose to accept their calendar, upon which time, their user email will be added with 'owner' rights to their organization's Google calendar.
 
*Calendars Feature*

  # Once the Calendar feature is officially "activated" by the program_admin, all users will see "Events", "List Events" and "Add Event" links on their sidebar.
  # "Events" link will show them the calendars. They may select to view different calendars using a drop down box.
  # "List Events" will give a list view of events with the respective event tags.
  # "Add Event" will take them to a form, where users choose the calendar they want to add their event to and the fill in the other event details.

*Event Creation by Owners*:

  # If the user posting the event has 'owner' rights(org_admin or program_admin) to the calendar they are posting to, the event entity will be created on Melange as well as on the actual Google Calendar immidiately.
                                  
*Event Creation by Non-Owners*:

  # If the user posting the even does not have 'owner' access to the calendar, the even entity will still be created on Melange with status "Unconfirmed" and will not posted to the Google Calendar. Instead, a notification with the event details will be sent to the 'owner' of the Calendar.
  # Upon recieving the notification, the owner may choose to accept the event, whereby the event will be posted to the Google Calendar, and the status of the correpoding event entity set to "Confirmed".


= Code Work Flow & Documentation =

== User Pages ==

*Main Files*:

*Code*:
    * User Page View - soc/modules/social/views/models/user_page.py
    * User Page Model - soc/modules/social/models/user_page.py
    * User Page Logic - soc/modules/social/logic/models/user_page.py

*Other Files*
    * edit.html  - soc/templates/modules/social/edit.html
    * view_page.html - soc/templates/modules/social/view_page.html
    * userpage.css - soc/content/modules/social/css/userpage.css

*User Page View*:
    * *__init__* function: 
          # Access params are set for 'create','edit' and 'list' access for User Pages.
          # new_params[] is used to set: *(i)* module and url names, *(ii)* templates for create, edit, view_page and list, *(iii)* create,edit and exclude dynaproperties, *(iv)* set public fields to be shown in User Page lists.
          # Setting url patterns for 'create','edit','list' and 'viewpage'.
    * *viewpage* function:
          # sets the template to be used for View Page
          # calls Logic method to get context, containing User Page entity details.
    * *_editPost_* function:
          # used to set User Page properties before User Page entity is created
          # properties such as *(i)* User reference, *(ii)* link_id, *(iii)* last_modified, *(iv)* role_entity of user, *(v)* calls Logic functions to get Student Projects associated with the role of the User, *(vi)* sets tags associated with user, *(vii)* image property(yet to be fixed) *(viii)* call Logic functions to get additional Work and Education entities added from the POST dictionary.
    * *_editGet_* function:
          # sets 'link_id' and 'tags' as a string before going to edit page.
    * *_edit_* function:
          # if request method is 'GET', call logic function to get all Work and Education entities associated with User Page to load to edit form.
          # if request method is 'POST', call logic function to create the additional Work and Education entities added to edit form.
    * *getExtraMenus* function:
          # creates Extra menu item called 'User (Community)'
          # if user if not logged in, shows a 'Sign In' link
          # if user if logged in, call redirect functions to get links for 'create', 'edit', 'view', and 'list' user pages based on respective access checks.
    * *list* function:
          # Filter and list user pages whose status is set to 'Visible'.

*User Page Logic*
    * *getRoleEntity* function: gets the role entity associated with current user.
    * *getProjects* function: get student projects associated with current user.
          # student projects in which current user is participating as student.
          # student projects in which current user is particiapting as mentor.
          # if current user is org_admin, all student projects associated with the org.
    * *getEducation* function:
          # gets all additional education-related field values from POST dict and updateOrCreates the Education entities.
    * *getWork* function:
          # gets all additional work-related field values from POST dict and updateOrCreates the Job entities.
    * *getUserPageContext* function:
          # gets the User Page entity, and the addtional education and job entities associated with the user.

*User Page Model*
    * Contains all the properties of the user page data model.

*edit.html*
    * *Javascript* functions:
          # *afterLoad()* function: This function is called upon the loading of the page. It gets the additional education and job entities in the context and calls *getWork()* and *getEducation()* functions to create the additional fields in the form for these entities.
          # *getWork()* function: for each work entity in the context dictionary, this creates the additional form fields and fills it in with the already existing work entities, if any.
          # *getEducation()* function: for each education entity in the context dictionary, creates the additional education form feilds and fills it with respective values.
          # *$('#moreEducation').click* function: Creates a new set of empty education form fields for user to fill. 
          # *$('#moreWork').click* function: Creates a new set of empty Work form fields for the user to fill.
    

= Timeline =
  The tentative project timeline will be added here.

===Week 1(22 May - 28 May)===

*To Do*:
  # Code the models, views/templates and logic for User Pages as per design above.  
  # Modify existing code to accommodate new feature (sending out user page link in acceptance notifications etc.)
  # Test code on localhost instance of Melange
  # Find out how to pull data from past year databases (how to test this? can we import the database files from somewhere?)

-----
Comment (madhu): Simple, create your own dummy data. If Felix has something to seed by then, we can probably use it. But in the first week I doubt it. But yeah you can create your own data.
-----

*Deliverables*:
  # Partial User Page feature:
      * On receiving acceptance notification, users can click on the link to their User Page or access it from the User tab in Melange.
      * User's will see default values on their User Page.
      * Users can view only their *own* user page. (search and view others' user pages not added yet).
      * Users can edit their user page data using forms.


===Week 2(29 May - 4 June)===

*To Do*:
  # Complete left-overs from Week 1
  # Develop an All Users ListView for viewing all users (who are not private) where clicking on a user takes them to the User pages
  # Work on providing filtering in the list view based on user-tags, location and org
  # Testing and Debugging previous weeks' work. 

*Deliverables*:
  # Almost-There User Page feature:
      * Users can use ListView to sift through the rest of the users and click on them to view their user pages.
      * Users can apply dynamic filtering to view users by location, org and tags using ListView.
      
-----
Comment (madhu): This is already there. Can you please tell us what you want to do other than this? http://socghop.appspot.com/gsoc/program/list_projects/google/gsoc2010
-----

===Week 3(5 June - 11 June)===

*To Do*:
  # Complete left-overs from Week 2  
  # Testing of feature plus writing tests(to be confirmed).
  # code event.py data model.
  # Design UI for calendar to be displayed (CSS/ CalVis).

*Deliverables*:
  # Fully-Functional User Page feature:
      * User can view/edit their own user pages.
      * Users can have a list view of all users participating in the program and view them by location, org and tags.
      * Users can view user pages of other users by clicking on their names in the ListView.


===Week 4(12 June - 18 June)===

*To Do*:
  # Modify View, Logic for Program_admin to authenticate an account where the program calendar and org calendar will be hosted. Create new org calendars once accepted orgs are announced.
  # Modify Views and Logic for users and admins, to view the program and their org calendars Clicking on calendars in their User tab.
  # Create templates for viewing the calendars based on user roles.
  # Use calendar api to import calendars and display them in Melange.
*Deliverables*:
  # Very-Partial Calendars feature:
      * On org acceptance, new calendars are created for each org.
      * All users can access their 'Calendars' link in their User tab.
      * They get to view their respective org and program calendars.


===Week 5(19 June - 25 June)===

*To Do*:
  # Code or modify existing user Views, create forms and templates for event creation/requests based on user roles.
  # Create templates and modify Views for org_admins and program_admins to approve or decline event requests.
  # Add event.py Logic to add new event in the actual Google calendar using API once its status is set to is_approved.
  # When adding event, use Maps Api to show a mini-map which users can use(optional) to point to the location of the event. Store this as Lat,Long attributes of event.py data model.

*Deliverables*:
  # Partial Calendar feature:
      * Users can view Calendars
      * Admins can add events to their respective calendars and approve/decline requests.
      * Non-admins can send requests to add event.
      

===Week 6(26 June - 2 July)===

*To Do*:
  # Write a feed function using Django's feed generator(to be confirmed) allowing users to subscribe to rss feeds on events with certain tags.
  # Test previous weeks' code.
  # Fix Bugs, complete lagging work from previous week.
  # Write tests?

*Deliverables*:
  # Almost-there Calendar feature:
      * All deliverables from Week 4 and 5.
      * Users can subscribe to feeds for events with certain tags.


===Week 7(3 July - 9 July)===

*To Do*:
  # Develop ListView for events (similar to users ListView)  
  # Allow dynamic filtering by tags, location.
  # Users can click on events they are interested in to see a pop-out widget with the event details.

*Deliverables*:
  # Almost-there Calendar feature:
      * All deliverables from weeks 4,5 and 6.
      * Calendars ListView
      * Event filtering by categories.
      * View event using pop-up widget.


===Week 8(10 July - 16 July)===

*To Do*:
  # Any left-over todo's from previous weeks.
  # Testing, Testing and Testing.  
  # Bug fixing.
  # Documentation
  # Get ready for mid-term evaluations.  

*Deliverables*:
  # User Page feature
      * View/edit User Page
      * View User Pages of all other users in the program.
      * Use ListView to filter users by location, org and tags.
  # Calendars Features
      * View Program and User's org calendar.
      * Add or Request to add Events.
      * ListView of all program and org events and all other events marked as public.
      * View a particular event's details.

===Week 9(17 July - 23 July)===

*To Do*:
  # Any left-over todo's from previous weeks.
  # Get started on Maps, read up on APIs 
  # Design UI
  # Decide on possible jqueries that will be required
  # Wind up User Pages & Calendar features and testing.  

*Deliverables*:
  # Maps feature
      * View all users and events in one shot no filtering yet

===Week 10(24 July - 30 July)===

*To Do*:
  # JS for filtering data based on tags, locations
  # Wind up previous weeks' work

*Deliverables*:
  # Maps feature
      * filtering should be visible

===Week 11(31 July - 6 August)===

*To Do*:
  # Complete Maps feature
  # Documentation
  # Get ready for final-term evaluations.  

*Deliverables*:
  # User Page feature
      * View/edit User Page
      * View User Pages of all other users in the program.
      * Use ListView to filter users by location, org and tags.
  # Calendars Features
      * View Program and User's org calendar.
      * Add or Request to add Events.
      * ListView of all program and org events and all other events marked as public.
      * View a particular event's details.
  # Maps Features
      * View all users or all events
      * apply filtering based on various criteria


= Meetings and Agendas =

== Friday April 30, 2010 13:30:00 in UTC ==
===Meeting Logs===
    Meeting start: http://www.thousandparsec.net/~irc/logm/%23melange.2010-04-30.log.html#t2010-04-30T13:30:05

    Meeting End: http://www.thousandparsec.net/~irc/logm/%23melange.2010-04-30.log.html#t2010-04-30T14:19:13    
    

===Meeting Notes===

  Location: #melange on freenode

  Time: 13:30:00 Friday April 30, 2010 in UTC 

  Chaired by: Madhusudan C.S

  Notes taken by: Savitha R 


    * A general overview of the project design was discussed.
       * Users should be able to view fellow GSoC students/mentors/admin by (i) geographic location (perhaps like a global map) (ii) by organization attached to (iii) by type of work/projects they are doing (iv) a complete list of all users in the program.
       * Users should be able to find other users using the above categories and then further have the option of finding out more information by clicking to view their personal GSoC user pages.
       * Privacy & Visibility issues: Users might need to have the option to keep their location and personal information private. In their personal user pages they may or may not choose to share their personal profile. However, they can share information about their projects such as progress, issues and other information related to the project.  Further discussion on the specific details is required.
       * In addition to finding fellow users by location, users can also choose to view events/calendars by selecting to view the happenings in certain locations only. In this case, the location will dictate the calendar to be displayed.

    * Tips on getting familiar with the code and documentation.
       * Select or get assigned to a simple patch/issue. Fix and submit the patch.
       * Homework assignments during community bonding period to get familiar with Melange code base.

===Next Meeting===

Location: #melange on freenode

Time: 13:30:00 Wednesday May 5, 2010 in UTC

Attendees: C.S.Madhusudan, Savitha

Agenda:
       * Detailed Project requirements
       * Design and Implementation details of project
       * Discuss and assigning of patch/bug-fixing home works to be taken up.


== Wednesday May 5, 2010 13:30:00 in UTC ==
===Meeting Logs===
    Meeting start: http://www.thousandparsec.net/~irc/logm/%23melange.2010-05-05.log.html#t2010-05-05T13:30:33

    Meeting End: http://www.thousandparsec.net/~irc/logm/%23melange.2010-05-05.log.html#t2010-05-05T15:19:58    
    

===Meeting Notes===

  Location: #melange on freenode

  Time: 13:30:00 Wednesday May 5, 2010 in UTC 

  Chaired by: Madhusudan C.S

  Notes taken by: Savitha R 


    * General discussion on version control.
       * Cloning project. - Done
       * Learn and understand mercurial version control system as well as commands etc. How to make changes, submit patches, push changes etc.
       * Fix and submit a patch a.s.a.p. for the issue no. 890 bug
    * APIs to be used – Google Calendar API, Maps API, CalVi UI library, GeoModel for filtering in maps, Google AJAX APIs, default GMAPs UI.
    * Project features in detail -  Maps
       * Global map indicating GSoC students/mentors/etc. and events occurring at specific locations.
       * Filtering data displayed on global map using different categories such as 
          (i)show all GSoC students from specific location 
          (ii)show all students from specific organization 
          (iii) show all events organized by program 
          (iv) show all events for a specific organization 
          (v) show all events between given date range 
          (vi) show all students based on the work they are doing (e.g all students working with C/C++ project tags)
          issue:  have to check app engine quota restrictions
       * Maps can be used to display student items or event items with any combination of the above filters.
       * UI – An AJAX-based UI which shows the map and a section for users to type in their filtering options, as they type input, map display gets updated dynamically. When users mouse over and click indicated points on the map, there will be a pop-out widget providing more information. If a user scrolls over and clicks on a GSoC meet up event at Singapore then a small widget will pop out showing the details such as time, venue and info about the event.
    * Project features in detail – Calendars
       * Other than maps view, there will be calendar-only display, to just view events.
       * Program calendar and their own organization calendar will be shown in this view.
       * If organization admins choose to make their org calendar “public”, this can also be viewed in the calendar display.
       * Events can be added by calendar owners only, such as org admins and program admins. Other wishing to share events, can submit a simple form with event details, which calendar owners can approve and publish on their calendar.
       * Display-only UI as users will not be allowed to edit calendar events without authorization.
       * Pop-out widget like In the maps, with event information and optional Google map view and optional YouTube video embed related to the event.
    * Project Features in detail – User pages
       * User pages will contain (i)personal profile (ii) picture (iii)project updates (iv) rss widget (iv) (if time permits) twitter widget also!
       * UI to be like face book profile pages, with tabs. (i) Profile tab for users to share personal, educational and professional information. (ii) Project tab for users to share info about their project progress, updates  and issue. (iii) Other stuff tab where users can add other social widgets such as rss widget for their blog feed.
       * Simple forms to be used to get users to fill in profile information etc. Under “Project” tab users can post using a text field which takes in “html”.
    * Discussion on resolving issue 890 and submitting patch this weekend. Posting weekly updates to dev blog and submit patches by Friday night (compulsory!).
    * Todo List for Savitha
       * Keep updating wiki with project design, workflows and formalized implementation details over the week.
       * Post on Dev Blog this weeks’ update.
       * Fix issue 890 and submit patch.