[Portfolio] Question about SAK-15822

Beth Kirschner bkirschn at umich.edu
Thu Mar 12 12:57:02 PDT 2009


I suggest putting this on the agenda for next Monday's call -- I'm  
confused by your statement "the next instructor might decide to have  
students interact with the matrix directly", since I think this  
problem could occur with either approach. Could this wait until then?

- Beth

On Mar 12, 2009, at 3:46 PM, Ward, Lynn E. wrote:

> For this case, we don't necessarily want the cell to start out as  
> pending for users created after the cell is evaluated.  Since the  
> matrix is used over a period of time, the next instructor might  
> decide to have students interact with the matrix directly.  If we  
> set the initial status to pending, the next cohort won't be able to  
> attach artifacts to their cells. I suppose we could reset the  
> initial status depending on who's responsible for facilitating the  
> completion and evaluation of the cell.  Besides, it doesn't solve  
> the problem of producing an expected result when the option is  
> selected.  We also discussed this today and here's what we came up  
> with as a possible solution.
>
> Instead of two radio buttons, provide three:
>
> 1. For this user only
> 2. For all active users
> 3. For all users, both active and inactive
>
> The third option could be hidden via a flag in Sakai properties.   
> Institutions that have very large sites might choose to hide the  
> third option.  We could even set the flag to hidden by default.
>
> Let us know what you think of this option.
>
> Let us know what you think.
>
> And yes, it makes sense to fix SAK-13935 at the same time.
> ==========================
> Lynn Ward, Principal Systems Analyst, Community Source Collaboration  
> and Learning
> University Information Technology Services
> Indiana University-Purdue University Indianapolis
> Information Technology and Communications Complex (IT 218S)
> 535 West Michigan Street, Indianapolis, IN 46202
> Phone: 317-278-5713  E-mail: leward at iupui.edu
>
> -----Original Message-----
> From: Beth Kirschner [mailto:bkirschn at umich.edu]
> Sent: Thursday, March 12, 2009 3:24 PM
> To: Ward, Lynn E.; Maurer, Christopher Wayne
> Cc: osp
> Subject: Re: [Portfolio] Question about SAK-15822
>
> Lynn,
>
> I guess I'm still not clear on why setting the initial status wouldn't
> work for your use case, unless you're saying that instructors may not
> know they want to change the status to pending until later? I agree
> that the 'change status for all users' definitely does have unexpected
> behavior (in fact, I stumbled on the same issue when looking into a
> solution for Sabanci).
>
> Noah and I were just discussing an option that brings the two
> proposals together -- what do folks think of this:
>
> (1) Add the ability to set the initial status of a cell to
> "Pending" (and maybe "Complete") when defining a matrix.
> (2) When selecting "Change Status... for all users", also change the
> initial status of the cell. This removes any concerns for performance.
> (3) While you're at it, you might also consider fixing http://bugs.sakaiproject.org/jira/browse/SAK-13935
>  (set the default to "For this user only", instead of nothing).
>
> Thoughts?
> - Beth
>
> On Mar 11, 2009, at 3:15 PM, Ward, Lynn E. wrote:
>
>> Although I can see the potential value of an initial pending state,
>> that's not quite what we need at the moment.  We've got a situation
>> in which students are submitting assignments that are linked to
>> program matrices.  Some instructors in the program may also ask
>> their students to interact with particular cells in the matrix
>> directly.  Anyway, the evaluators for the cells with the linked
>> assignments would like to be able to convert all of the cells to
>> pending at one time so they can add evaluations to these cells.  The
>> problems is that a matrix can contain a linked assignment without
>> having been instantiated by the student, so those cells don't
>> convert to pending.    I imagine we can solve this problem by
>> checking to see if the users has any linked assignments in the cell
>> before executing the command.
>>
>> Sabanci University provides another possible use case.  They want to
>> evaluate even though students haven't uploaded or submitted.  Having
>> the ability to convert a specific cells to pending for all users
>> would make it possible to push those cells to the evaluations tool
>> for evaluators to complete their work.  An initial status of pending
>> might work for them, but the ability to control which cells are
>> evaluated when might be preferable.
>>
>> Also, I doubt anyone but the developers would understand why, when
>> you select "change status for all users," you don't see a
>> corresponding status change in every user's matrix.  Until recently,
>> I had no idea that the matrix wasn't created until eh owner touched
>> it.  So, I simply thought the command was broken.    At the very
>> least, the radio button label and the alert text should be changed
>> to something like "for all active users"
>>
>> Lynn
>>
>> ==========================
>> Lynn Ward, Principal Systems Analyst, Community Source Collaboration
>> and Learning
>> University Information Technology Services
>> Indiana University-Purdue University Indianapolis
>> Information Technology and Communications Complex (IT 218S)
>> 535 West Michigan Street, Indianapolis, IN 46202
>> Phone: 317-278-5713  E-mail: leward at iupui.edu
>>
>> From: Maurer, Christopher Wayne
>> Sent: Wednesday, March 11, 2009 1:13 PM
>> To: Beth Kirschner; Ward, Lynn E.
>> Cc: osp
>> Subject: Re: [Portfolio] Question about SAK-15822
>>
>> Well, I can't really make that determination.  That'd be up to Lynn
>> and all the other functional folks...
>>
>> Chris
>>
>>
>> On 3/11/09 9:40 AM, "Beth Kirschner" <bkirschn at umich.edu> wrote:
>> It seems that the behavior that is really desired is not to change  
>> the
>> way 'Manage Status' works for all users, but to allow an initial
>> status of "Pending" in addition to "Ready" and "Locked".
>>
>> - Beth
>>
>> On Mar 10, 2009, at 2:31 PM, Holladay, Bryan Andrew wrote:
>>
>>> I would not advise calling this bulk creation of user's matrices
>>> after creating the matrix, for this will guarantee a slowdown.  I
>>> believe if you trigger this only in the case where someone is
>>> changing the status of a cell and there are missing user matrices,
>>> then this off case wouldn't have a big impact since the majority of
>>> the use cases will not be a complete bulk update (just picking up
>>> stragglers like new users)
>>>
>>> Bryan
>>>
>>>
>>> On 3/10/09 2:29 PM, "Maurer, Christopher Wayne" <chmaurer at iupui.edu>
>>> wrote:
>>>
>>> That is correct.
>>>
>>> Chris
>>>
>>>
>>> On 3/10/09 2:25 PM, "Sean Keesler" <sean at keesler.org> wrote:
>>>
>>> Seems to me that this would be a time consuming operation *just
>>> once* (when the matrix is published and all the user instances are
>>> created) and that the performance after that would be no different
>>> than if everyone had actually used the matrix.
>>>
>>> Sean
>>>
>>>
>>> On Tue, Mar 10, 2009 at 1:53 PM, janice.smith <janice.smith at threecanoes.com
>>>> wrote:
>>> Hi Chris
>>>
>>> I have not followed all the details of this discussion, but I can
>>> tell you from experience that performance issues with OSP can
>>> literally shut down an instance of Sakai. If we have the choice
>>> between creating something that dramatically complicates performance
>>> and something that does not, I will choose the less complicated
>>> option every time. So far the big performance problems have been
>>> with the wizard. If the matrix starts generating performance
>>> problems (which it has not to date), there will be serious
>>> consequences for portfolio implementations. Also as an FYI, at many
>>> institutions, only some of the users in portfolio sites actually use
>>> the matrix.
>>>
>>> Janice
>>>
>>> Janice A. Smith, Ph.D.
>>> Three Canoes Consulting
>>> 1204 Laurel Avenue
>>> Saint Paul, Minnesota 55104, USA
>>> 651-642-9069
>>> 207-841-6262 (cell)
>>> janice.smith at threecanoes.com
>>> jasmith at mm.com
>>>
>>>
>>> ---- On Tue, 10 Mar 2009 10:38:28 -0700 Christopher Wayne Maurer <chmaurer at iupui.edu
>>>> wrote ----
>>>
>>> http://bugs.sakaiproject.org/jira/browse/SAK-15822
>>>
>>> As a brief summary, the "manage status for all users" functionality
>>> will only work if the user has visited the matrix in question (and
>>> generated the actual data).
>>>
>>> What do people think about having this trigger the creation of
>>> matrix data first?
>>>
>>> My biggest concern is the performance of creating all that data (if
>>> it doesn't exist).  I would expect that the normal use case here is
>>> that most users will have interacted with their matrix by this
>> point.
>>> But, in practice this may not be the case.  I can obviously create
>>> a site with 1000 users, create a matrix, and immediately change the
>>> status for all users (not the same as changing the cell's initial
>>> status).  This action will create all 1000 user matrices (well, 999
>>> since the author just went to the matrix).
>>>
>>> The case that isn't covered (and I think that it's okay not to
>>> worry about it) is when all the statuses have been changed and a
>>> user is added to the site.
>>>
>>> So, what do people think about this bulk creation?
>>>
>>> Chris
>>> _______________________________________________
>>> portfolio mailing list
>>> portfolio at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/portfolio
>>>
>>> TO UNSUBSCRIBE: send email to portfolio-unsubscribe at collab.sakaiproject.org
>>> with a subject of "unsubscribe"
>>>
>>>
>>> _______________________________________________
>>> portfolio mailing list
>>> portfolio at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/portfolio
>>>
>>> TO UNSUBSCRIBE: send email to portfolio-unsubscribe at collab.sakaiproject.org
>>> with a subject of "unsubscribe"
>>>
>>>
>>>
>>> _______________________________________________
>>> portfolio mailing list
>>> portfolio at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/portfolio
>>>
>>> TO UNSUBSCRIBE: send email to portfolio-unsubscribe at collab.sakaiproject.org
>>> with a subject of "unsubscribe"
>>
>
>
>



More information about the portfolio mailing list