A lot of things have happened in the past two months and I’m happy to announce that we have not only completed the project, but, also achieved our stretch goals and more! Furthermore, we have noted down some nice enhancements to add after GSoC. In the next few days a summary post will be published with links to all the code and more info about the enhancements.
So, now, let’s see what has been done since the previous update.
Track request acceptance workflow
#1597 implements the workflow for accepting a request for a track. Specifically, after a track request has been submitted, it appears in
admin/Tracks#index along with the regular tracks (the ones that have been added from the admin views).
Here, the conference team can accept/reject a request or mark it as a possible acceptance/rejection.
For a track request to be accepted, it must have start/end dates and a room assigned to it. If not, then, when someone tries to accept a request, he/she will be redirected to
admin/Tracks#edit and a message will appear that informs him/her to fill them out.
Something nice about self-organized tracks is that the
Tracks#new form allows the submitter to request specific dates for his track. Also, self-organized tracks have a “relevance” field, where the submitter explains how that track is related to the conference and how he/she is related to the track’s content, which can really help the conference team review the request. An important distinction between the “description” and “relevance” fields is, that the first is publicly viewable, while the second is only visible to the conference team.
It’s useful to keep in mind that, when a track request is accepted then the role of the track organizer for that track is created. This, way the conference team can assign other people as track organizers, before it gets confirmed. When a track is confirmed, it’s submitter is assigned the track organizer role. Also, when a self-organized track is canceled or withdrawn then the role of the track organizer for that track is revoked from all the user’s that have it, all of it’s events are removed from it and their state resets to new.
Since, this PR implements the track acceptance workflow, it also enables the submission of track requests when the conference’s cfp for tracks is open.
Event management and scheduling for tracks
The whole point of having self-organized tracks is to delegate part of the proposal reviewal and event scheduling workload to someone else (the track organizers). So, this is what #1631 is about. Particularly, from now on, the track organizers have the ability to manage the events of their tracks, so they can review the proposals and accept/reject them. Also, the Schedule model and related controllers have been modified to distinct between conference schedules and track schedules, and show a unified schedule to the users in
Schedules#show. More specifically, in
admin/Schedules#index you have a tab for each kind of schedule, events of self-organized tracks can be scheduled only in their track’s schedules and the rooms of self-organized tracks appear semitransparent in the conference’s schedules.
New track schedules can be created either from the
Add Track Schedule button in
admin/Schedules#index or the
Create Schedule button that has been added in
Because the code supports multiple track schedules, this button becomes
Show Schedule, when one of them becomes the selected schedule of the track.
Bellow, we can see an event scheduled in the track’s selected schedule, the room and the event appear semitransparent in a conference schedule. If the track schedule wasn’t the selected one then the room would appear empty in the conference schedule.
Currently, there is some code refactoring going on in #1639. The only change that is visible from the user’s perspective is that the url to the role of the track organizer has been changed from
https://example.com/admin/conference/some_conferences/program/tracks/awesome_track/roles/track_organizer, because instead of using custom routes for the role of the track organizer, they are now generated by adding roles as a nested resource to tracks in