>* The setup wizard should not be forced IMHO. If the teacher needs to
>edit a
> single setting (and experienced teachers often know exactly what they
>need to change), they still should have the option to see all settings
>on one page so that they can easily find what they need (e.g. by
>searching text on the page). Maybe the wizard can be an optional
>and/or displayed when creating a new workshop instance only?
Actually, it's already optional. When you create a new workshop we added a "Show advanced settings" link in the top right corner. In this mode, the “Save and follow wizard” button is replaced by the standard “Save and display” button.
This settings is saved for users with a user_preferences.
Screenshots :
- showAdvancedSetting.png
- saveAndReturnToCourse.png
- editSettings.png
>* The early allocation in advance kind of presumes that the workshop
> participants are a static group. I am wondering how is that supposed
>to work
> in dynamic MOOC-like environments when participants join and finish
>the
> workshop in different time periods (typically not all are enrolled
>yet when
> the Workshop is being set up).
According to our understanding, the actual workshop don't cover MOOC very well. We don't think our changes make things worse but we agree that we didn’t make some improvement based on this. Right now the MOOC with Moodle is not a priority for our institution.
The new parameter "Allow assessment after submission" help, but the fact that we don't have reimplemented yet the "planed allocation" is not helping.
>* I understand the demand for implementing the anonymity as a setting
>rather
> than via capabilities. The original reasoning behind the current
> implementation was that only capabilities allow for maximum
>flexibility. What
> if some users/roles should be exceptions from the default setting? It
>was
> discussed in the past that a solution might be a widget that appears
>as a
> part of the settings form, but it actually sets the required
>capabilities
> behind the scene. To use the best parts of both worlds.
The checkbox for anonymity are not parameter save into the database, but a change of capabilities (mod/workshop:viewauthornames and mod/workshop:viewreviewernames).
The goal was to make life simpler to teacher. We think an ordinary teacher will find the option more easily with our improvement. We don't think that the ordinary teacher know how to change capabilities.
>* The plan to merge Workshop grading strategies with Advanced grading
>methods
> has been there since the beginning. The thing is, there are some
>conceptual
> differences that must be sorted out first on Advanced grading methods
>API
> level.
> - Advanced grading methods are not necessarily seen as multi-criteria forms
> with individual grading of each criterion. They are free to be implemented
> in any way, as long as they produce a single number grade. But Workshop
> needs and relies on knowing the internal values of how each particular
> criterion has been graded, because it uses that data when comparing the
> similarity of two assessments (it is not the final grade that counts, it is
> how the form has been filled).
> - Advanced grading methods do not support embedded images in criteria
> descriptions, Workshop does. To be able to migrate/merge them without
> data-loss, the AGM should start supporting them, too.
Right now we are running out of time to do that. It's a big job.
>== Some details spotted on the way ==
>
>* As Damyon noticed as well, the "Open setup wizard" button should not
>be
> displayed to students.
Already fixed.
>* The phases block is too high and empty for students, especially when
>there is
> not much tasks for them.
Actually, we are removing the phase block for the student because it's not relevant for the student. We will show the student the current phase, but not the other phases.
We are working on that right now.
Screenshots :
- studentInterface.png
>== Things I am particularly interested in ==
>
>(1) The early allocation: How do you store the allocations internally? Thing is, there are two major demands in the community for extending the Workshop and they kind of contradict.
>
>- There is a demand for ability to use the Workshop for assessing peers'
> offline performance, so that the authors should not need to even
>submit
> anything. And there are voices that the allocation should be
>implemented as
> user-to-user relationship, not user-to-submission. So that it is the
> participant being assessed, not the submission.
We are creating fake submission to do the allocations.
We agree with you and we have made change for that.
- We got the "Allow submissions" checkbox. No submission is required in that case
- In that case also it's a user-to-user relationship
>- There is a demand for team/group submissions in Workshop which needs
>the
> submission entity essentially. So that the submitted work can have
>multiple
> authors and it is the work being assessed.
>- (nobody yet raised that one student should be co-author of multiple
> submissions but I am sure it will be on the table one day
Apart from the fact that we are now doing user-to-user instead of user-to-submission, the whole group mechanism continues to work as before. We will not have time to improve it from our side but you could do it later.
Screenshots :
- All the file group*.png
> My current plan is to keep the allocations on user-to-submission
> basis, but let Workshop to automatically pre-populate draft
> submissions for all currently active participants (and keep it
> up-to-date). So that would allow us to pre-allocate assessments without loosing the entity/concept of the submitted work.
We are doing that, but on a user-to-peer basis.
>(2) How do you see your version compatible with the plan to get rid of
>Workshop phases completely? As you may know, the plan is to have each
>of the submission to go through its own workflow without the need to
>wait for others (with all additional features like events, semaphors,
>deadlines etc). As a result, the manual allocation of peers will be still available, yet not dominant at all.
>There will be a heavy focus on Workshop itself picking up the most
>appropriate reviewer for the submitted work just in time, so that
>there are ideally no delays and the feedback loops are as short as possible.
Quite the same answer that the one for the MOOC.
Right now, our mean focus was reduce the learning curve of Workshop. We really don't have a good adoption for this activity. We got 2500 teachers and I think we can count the teachers that use it on 1 or 2 hands. So we decided to improved it to increase is adoption and address the business need.
> (3) Is the code with your development available publicly?
We got a branch workshop_udem-33 in our github :
- https://github.com/StudiUM/moodle/tree/workshop_udem-33
You can also check the compare between Moodle 3.3.1 and our branch
- https://github.com/moodle/moodle/compare/718003c...StudiUM:workshop_udem-33#files_buckets
For a better experience you need to use our theme :
- https://github.com/StudiUM/moodle-theme_cleanudem/tree/workshop_udem-33
- Compare
- https://github.com/StudiUM/moodle-theme_cleanudem/compare/master...workshop_udem-33
Some improvements are currently only in the theme. If you like it, you need to put it in the core. You can see those improvements in the screenshots :
- themePhases.png
- themeMessages.png
To conclude, I would say that we have according to our understanding responded in part to some community need without preventing other future needs. As for the MOOCS and the fusion of the phases, it is a work that will necessitate a big refactoring but that can be done later, whether our code is integrated with the core or not. In general, I think there would still be some work to integrate it to the core. However, we think it would be interesting for the community as much as for us to be integrated in the core.
