[srobo-devel] Mentoring Scheduler

[Tom Leese]

Hi all,

At the Southampton Tech Day I developed a simple tool to help schedule mentoring which I wanted to share with you.

Basically, there are two YAML files which you can fill in with mentor’s free times and when the teams meet up, and then you run the script and it produces an HTML file which can be used to determine who the mentors should be. The script also takes into account the distance from your position to the school and tells you how much time you have to get there and get back so you can be sure that whoever is picked will be able to mentor them.

I’ve attached an example output file to look at. The code is available at https://github.com/thomasleese/sr-mentoring-scheduler <https://github.com/thomasleese/sr-mentoring-scheduler>, pull requests welcome.

I hope that you find it useful!

Tom

[Jeremy Morse]

Hi Tom,

Post by Tom Leese
At the Southampton Tech Day I developed a simple tool to help schedule
mentoring which I wanted to share with you.

This looks really good, thanks for sharing,

One labor intensive task last year was building a schedule for the
competition as a whole (i.e., scheduling shepherds, linesmen, helpdesk,
battery charging...), and ideally it would have been presented in an
easy to use manner (spreadsheet entries are OK, but could have been
better). Do you think this is the kind of thing you / other soton people
might be interested in?

The scheduling algorithm itself isn't so interesting or important (it's
all NP-hard), IMO all the real issues are in ensuring consistency and
ease of presentation. I definitely fell down a lot last year on the
consistency front. Ideally the operator could just enter constraints
then click 'Go'.

--
Thanks,
Jeremy

[Tom Leese]

Hi Jeremy,

Post by Jeremy Morse
One labor intensive task last year was building a schedule for the
competition as a whole (i.e., scheduling shepherds, linesmen, helpdesk,
battery charging...), and ideally it would have been presented in an
easy to use manner (spreadsheet entries are OK, but could have been
better). Do you think this is the kind of thing you / other soton people
might be interested in?

Sorry for the slightly delayed reply!

Yeah, this is definitely something we would be interested in doing in Southampton.

Tom

[Samson Danziger]

Jeremy,

We have now started doing this.

We are planning a web interface on which one can just sign up volunteers
and their capabilities, and then the schedule is generated in the
background for the specified roles.

<Loading Image...>
We're planning to use the Individual Schedules spreadsheet from last year
to source the roles. Are there any other roles we should be aware of?

Samson

[Peter Law]

Hi,

Post by Samson Danziger
We have now started doing this.

Cool. Do you have an outline of the architecture and technologies
you're planning to use?

I'm thinking in terms of deployment (I'm guessing you'd want this to
be deployed onto saffron) and long-term development. In both cases
there is some benefit to using things which we already have
familiarity with.

Post by Samson Danziger
We are planning a web interface on which one
can just sign up volunteers and their capabilities,

I think there would be value in also allowing the system to work from
a CSV (or similar) import. This would allow the sign-up process to be
decoupled and use (for example) a Google Docs Form (as has been done
successfully in the past).

Thanks,
Peter

[Tom Leese]

Hi,

Post by Peter Law
Cool. Do you have an outline of the architecture and technologies
you're planning to use?

We’ve decided to use Django for the backend. Bootstrap/HTML for the frontend.

Post by Peter Law
I'm thinking in terms of deployment (I'm guessing you'd want this to
be deployed onto saffron) and long-term development. In both cases
there is some benefit to using things which we already have
familiarity with.

Django is Python. Although it is not Flask (which has been used for previous Web ventures), Django offers a much wider range of functionality and lets us get started much quicker.

Deployment is effectively no different to Flask, they both use WSGI.

Post by Peter Law
I think there would be value in also allowing the system to work from
a CSV (or similar) import. This would allow the sign-up process to be
decoupled and use (for example) a Google Docs Form (as has been done
successfully in the past).

Sure, although we do like the idea of serving the sign-up page ourselves. It just avoids having to move data around which saves time and gives us ownership of that data.

Tom

[Jeremy Morse]

Hi,

fgasdf,

Thanks for initiating this (I have mountains of Things right now), FYI
I'm not myself bothered by what technology powers this [0],

I agree with pretty much everything already said, there seem to be some
distinct features developing, which to my eyes are:
* Data collection (which as Tom says we should own)
* Actual scheduling
* Presentation of results
We could consider these as different applications; we could also not.
IMO what we need to consider first is precisely what inputs and outputs
this system is going to work with, which in general I believe would be:

Inputs:
* Raw data from volunteers signing up to help at the competition
* Information about the requirements of the schedule to be produced
(i.e., number of roles, what they are, how many, time divisions)
* Some specific constraints from the "Schedule operator" (see below)
Outputs:
* A *printable* A4 page illustrating who's on what role for each day
* Specific schedules for each volunteer
* Role-specific schedules (i.e., a list on the helpdesk help desk that
tells you who's working there when)
* Some set of stats that we can use elsewhere, i.e. how many
volunteers are staying overnight [1], average load of volunteers
(i.e. how many free slots they have), uncommitted people who can
help with teardown at the end, and so forth.

That's all off the top of my head -- can anyone think of anything more?
In all circumstances, this then becomes a question of what data points
each volunteer needs to provide (if we don't get it right the first
time, it's massive pain to go back and get more info). People have a
habit of changing their minds too, some kind of superuser should be able
to edit it. IIRC last year there were several people who withdrew
(circumstances etc) or had to change the times they were available.

Regarding the "Schedule Operator": there'll inevitably be someone in
charge of producing a canonical schedule, and they're going to want to
add their own constraints and make the scheduler fill in around it. For
example, for the past n years I've been on the door when people arrived
at the competition to handle media consent irregularities, certain
people might only commit to one specific job/slot, and so forth.
Allowing this configuration should be a first class feature IMO.

Finally, are there any features other people think should be present?

Just to re-iterate, next steps would be defining data points to collect,
then storage, then moving on to logic and interactions.

[0] Although if it involves node.js I will become slightly more snarky,
[1] Might need to find out who needs a room or whatever; this is an area
that's subject to change though as there's currently no Policy (TM) on
who has accommodation,

--
Thanks,
Jeremy

[Jeremy Morse]

Hi,

The "Mentoring Scheduler" discussion is now really a discussion about
competition volunteers. Please continue with this subject line (what I
wrote is below), to avoid confusion.

Post by Jeremy Morse
Hi,
fgasdf,
Thanks for initiating this (I have mountains of Things right now), FYI
I'm not myself bothered by what technology powers this [0],
I agree with pretty much everything already said, there seem to be some
* Data collection (which as Tom says we should own)
* Actual scheduling
* Presentation of results
We could consider these as different applications; we could also not.
IMO what we need to consider first is precisely what inputs and outputs
* Raw data from volunteers signing up to help at the competition
* Information about the requirements of the schedule to be produced
(i.e., number of roles, what they are, how many, time divisions)
* Some specific constraints from the "Schedule operator" (see below)
* A *printable* A4 page illustrating who's on what role for each day
* Specific schedules for each volunteer
* Role-specific schedules (i.e., a list on the helpdesk help desk that
tells you who's working there when)
* Some set of stats that we can use elsewhere, i.e. how many
volunteers are staying overnight [1], average load of volunteers
(i.e. how many free slots they have), uncommitted people who can
help with teardown at the end, and so forth.
That's all off the top of my head -- can anyone think of anything more?
In all circumstances, this then becomes a question of what data points
each volunteer needs to provide (if we don't get it right the first
time, it's massive pain to go back and get more info). People have a
habit of changing their minds too, some kind of superuser should be able
to edit it. IIRC last year there were several people who withdrew
(circumstances etc) or had to change the times they were available.
Regarding the "Schedule Operator": there'll inevitably be someone in
charge of producing a canonical schedule, and they're going to want to
add their own constraints and make the scheduler fill in around it. For
example, for the past n years I've been on the door when people arrived
at the competition to handle media consent irregularities, certain
people might only commit to one specific job/slot, and so forth.
Allowing this configuration should be a first class feature IMO.
Finally, are there any features other people think should be present?
Just to re-iterate, next steps would be defining data points to collect,
then storage, then moving on to logic and interactions.
[0] Although if it involves node.js I will become slightly more snarky,
[1] Might need to find out who needs a room or whatever; this is an area
that's subject to change though as there's currently no Policy (TM) on
who has accommodation,
--
Thanks,
Jeremy