[sakai-core-team] Content Review Improvments for 10

[Matthew Jones]

Well, since this would be in core, we'd update Assignment, Content-Review
and include ContentReviewFederated into the 10.x branch as the default
impl.

It would break anyone who is running Assignment2, Vericite or TurnItIn,
causing them to need an upgrade. I guess the main question we were just
wondering, since this really only affects Content-Review-Impl's is if all
of the improvements and fixes that it includes are things people who are
running Vericite or Turnitin would really want now, or if they would be
okay waiting until they upgraded to 11? (which may not be until July/August
2015 at the earliest)

Western was saying that they want them now and would have to backport them
into a 10.3 branch when they merge. I know most (all?) of our clients on
10.x who are using either/both Turnitin and Vericite are running these
changes?

I'll look at the federated and see, every non-void method already *has* an
else case by default, like

	if (provider != null)
			return provider.isSiteAcceptable(arg0);
	return false;


So maybe it just needs to print a debug message before the return.


On Thu, Nov 13, 2014 at 1:30 PM, Bryan Holladay <holladay at longsight.com>
wrote:

> I don't think it's wise to introduce these changes into a maintenance
> branch. All of the following projects must be updated in someones instance
> at the same time, otherwise the tools will be broken: Assignment,
> Assignment2, Content-Review, VeriCite Impl, TurnItIn Impl, and
> ConterReviewFederated. You'll also need to update the TurnItIn impl 10.x
> branch (prob cut it from trunk).
>
> As far as testing goes, yes, they have been tested a lot and in production
> with several institutions. You haven't missed anything, just those 6
> projects. As for the mock content-review impl, I don't think that's
> necessary since the federated impl handles the case of no content review
> impls just fine. Only advantage would be for logging. I wouldn't use
> federated impl to do logging since you'd have to change how it works (e.g.
> return "true" for  isSiteAcceptable, which would prob then break b/c there
> are no implementations of content-review).
>
> -Bryan
>
> On Thu, Nov 13, 2014 at 12:56 PM, Matthew Jones <matthew at longsight.com>
> wrote:
>
>> Hi Bryan,
>>
>> We were talking on the call today about getting the improvments on
>> https://jira.sakaiproject.org/browse/SAK-26318 and the all of the
>> related sub-tasks in for 10.x for either 10.3 or 10.4. I know that whoever
>> picked this up would also have to update Assignment 2 (if they're running
>> it) and the Turnitin and Vericite Impls (if they are also running those).
>>
>> It seems like these all have been tested enough and looks like we're
>> running on some clients locally so they are low risk and would be preferred
>> for anyone running content review, just wondering what you think and if I
>> missed any impls or non-core changes that are not listed as sub-task or
>> we'd have to mention in the release notes.
>>
>> And I know we worked on a mock content-review-impl at one time that just
>> prints log messages. I think it would be nice to include that in the core
>> Sakai code so it can easily be switched over to for testing. Was that
>> checked in anywhere? Either that or maybe when we bring over the default
>> federated impl we can add in an option for more logging if the there are no
>> defined providers.
>>
>> Like
>>
>> if (provider != null)
>>
>> //Run the provider
>>
>> else
>>
>> //Print a log (debug?) message about how it would run the provider, but there is no provider available
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-core-team/attachments/20141113/b338c2dd/attachment.html