Child Protection policy update

[Jon Bartlett]

Hi,
with many apologies for my inactivity in these areas, I have now
prepared more drafts of various policies for SR. These will be in the
following posts for criticism/appraisal as text, since my previous
approach of attaching PDF files to trac tickets is a little clunky for
editing.

Note that some of them are rather generic and were originally posted
six months ago.

[1]Procedure for Children at Possible Risk of Abuse

This policy is generic, original sources given at the end of the
document. May require minor tweaks.

[1]https://www.studentrobotics.org/trac/ticket/2472

[Jon Bartlett]

Policy 2 - Recruitment and DBS policy

This one is more specific to SR and may need more input - was also sent out in May.

Student Robotics Recruitment and DBS Policy

This policy applies to anyone responsible for recruiting and inducting volunteers in Student Robotics.

The purpose of the policy:

· To take all reasonable steps to prevent unsuitable people from joining the organisation
· To ensure new volunteers are given a proper induction
· To ensure all volunteers receive ongoing support


Recruitment and DBS Checks

In Student Robotics, volunteers may fall broadly into two categories:

1. Roles that do not involve regular contact with children, such as software or hardware development. This group also includes volunteers attending the annual competition weekend. These roles do not require DBS checks.

2. Mentor and remote mentor roles involving regular, supervised contact with children. These roles require an Enhanced DBS check (without Barred List check) from an umbrella body. Volunteers in these roles are encouraged to subscribe to the DBS online update service to prevent the need for an annual check.

Any volunteer who has contact with teams is expected to complete a Volunteer Information Form providing basic information such as name and contact details. This information will be stored securely in accordance with relevant legislation.


Induction and Support

All volunteers should receive an induction appropriate to their role. This may include relevant safety training (for example in constructing the competition arena) and training on child protection policies (for those in contact with teams). Volunteers in contact with teams should read and sign the appropriate codes of behaviour.

New volunteers will be put in contact with experienced volunteers who are able to act as advisors.

[Jon Bartlett]

Policy 3 - Code of Behaviour for volunteers

This is slightly based on the 'Yellow Card' from Scouting but specifically altered for SR purposes.  This is likely to need most feedback from those who have actually done mentoring.

Student Robotics Code of Behaviour for Volunteers

Student Robotics volunteers working with teams should be aware of these rules at all times.


Do:

Complete the online mentoring record form regularly

Send copies of all email correspondence with team members to arc...@studentrobotics.org

Treat everyone equally and respectfully

Avoid unacceptable situations within a mentoring relationship (e.g. sexual or romantic relationships with team members)

Ensure the team leader or another suitable adult is present during mentoring sessions

Behave in a professional manner when representing Student Robotics, including online interactions

Raise any concerns with the designated person for child protection


Do not:

Take part in inappropriate behaviour or contact, whether physical, sexual or mental.

Use inappropriate language when communicating with teams

[Alistair Lynn]

Hi Jon–

Pardon my not reviewing this when originally sent out. Thanks for
writing these up.

> 2. Mentor and remote mentor roles involving regular, supervised contact with
> children. These roles require an Enhanced DBS check (without Barred List
> check) from an umbrella body. Volunteers in these roles are encouraged to
> subscribe to the DBS online update service to prevent the need for an annual
> check.

What is the policy in case a DBS check doesn't come up clean? Also, do
we need the check against the Barred List?

> Any volunteer who has contact with teams is expected to complete a Volunteer
> Information Form providing basic information such as name and contact
> details. This information will be stored securely in accordance with
> relevant legislation.

What specific information, and how (and by whom) would this be
kept—centralised or a matter for branches?

> All volunteers should receive an induction appropriate to their role. This
> may include relevant safety training (for example in constructing the
> competition arena) and training on child protection policies (for those in
> contact with teams). Volunteers in contact with teams should read and sign
> the appropriate codes of behaviour.

The nature of this training is probably a separate discussion. What we
do want is as many people as possible being able to go out mentoring,
how long do you think the training would be?

> New volunteers will be put in contact with experienced volunteers who are
> able to act as advisors.

+1

Alistair

[Alistair Lynn]

Hi Jon–

More review.

> Send copies of all email correspondence with team members to
> arc...@studentrobotics.org

Generally it seems like it's a bad idea to have contact with team
members directly over email anyway. Perhaps that should be mentioned
in the policy?

> Raise any concerns with the designated person for child protection

We should probably get on with working out who that is?

Alistair

[Jon Bartlett]

> What is the policy in case a DBS check doesn't come up clean?

There isn't a formal requirement for 'clean' checks as such - the
responsible people (in each branch I guess) would see the results and
decide on a case-by-case basis. Basically comes down to a judgement
on suitability, so an old shoplifting conviction is probably fine,
while a child abuse conviction isn't. A sample policy from the DBS is
here[0]. More detailed stuff will probably be needed at some point
but I'm trying to get a minimum in place for now.

> Also, do we need the check against the Barred List?

I've just re-checked the legislation on this and confirmed that no
barred list check is needed as mentors will be under the supervision
of a teacher (the exact nature of that supervision is the
responsibility of the school, legally it must be 'reasonable in all
the circumstances to ensure the protection of children'[1]). Since SR
mentoring is therefore not regulated activity, it would be illegal to
request barred list checks. I'll also update the terminology, as the
barred list check is now called 'Enhanced Check for Regulated Activity
(Children)'.

Alternatively if we make sure mentors visit less than once a week (or
4 times in 30 days), a standard DBS check would be enough.

> What specific information, and how (and by whom) would this be
> kept—centralised or a matter for branches?

Branches or central would both be fine, just a matter of preference -
specifically I'd expect a record of name, address, phone number, email
address, school mentored and a 'DBS has been checked' box. Since this
is personal data then the Data Protection Act would be in force - I'm
not sure of the exact requirements though.

> The nature of this training is probably a separate discussion. What we
> do want is as many people as possible being able to go out mentoring,
> how long do you think the training would be?

There are a couple of options for training. Given the nature of the
mentoring role the minimum should be some kind of induction session
which goes over the child protection policies and code of behaviour -
essentially just making sure everyone knows what they should do and
who to contact if anything happens. A doing would be fine for that,
possibly even an online 'I have read the documents' form. If SR
decides to go further (maybe after charity status?) there are various
free online training things available, but I think they might be
overkill at the moment.

The designated person (or people if it goes by branch) will probably
need more formal training which is available from various providers
such as the NSPCC [2].

For safety training, not really my area. Again probably a minimum of
a safety briefing for whatever the job involves (e.g. wear gloves when
you put up scaffolding, don't try carrying 50kg of stuff by yourself).

>> New volunteers will be put in contact with experienced volunteers who are
>> able to act as advisors.
>
> +1

This one should be really important for SR as far as retaining
volunteers and ensuring consistency.

Jon

[0]https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/268599/DBS_sample_policy_on_the_recruitment_of_ex-offenders_v2_1.pdf
[1]https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/349126/DBS_guide_to_eligibility_v6.pdf
(See table on page 2)
[2]http://www.nspcc.org.uk/what-you-can-do/get-expert-training/designated-safeguarding-officer-training/

[Jon Bartlett]

> Generally it seems like it's a bad idea to have contact with team
> members directly over email anyway. Perhaps that should be mentioned
> in the policy?

I don't see any problem with communicating over email as long as
mentors are sensible about it (e.g. use SR email addresses and always
copy to archive@). Ideally also use only school email addresses for
students. While most questions should go to the forum, sometimes
teams may just want to ask something specific relating to secret plans
or following from discussions.

> We should probably get on with working out who that is?

+1. Probably also need to decide if one is needed per branch or just overall.

Jon

[Peter Law]

Hi,

Alistair wrote:
>> What specific information, and how (and by whom) would this be

>> kept--centralised or a matter for branches?

Jon wrote:
> Branches or central would both be fine, just a matter of preference -
> specifically I'd expect a record of name, address, phone number, email
> address, school mentored and a 'DBS has been checked' box. Since this
> is personal data then the Data Protection Act would be in force - I'm
> not sure of the exact requirements though.

In the past I think that we've recorded the CRB ack value by
adding/removing people from a crb-$YYYY group in LDAP. Given that we
already have DPA related restrictions on LDAP data this seemed a good
fit, but I suspect that it doesn't currently record all of the above
data about a person.

Peter

[Harry Cutts]

Hi Jon,

Thanks for working on this. It all looks good to me, but there's one thing I'm unclear on:

On Saturday, 8 November 2014 15:17:06 UTC, Jon Bartlett wrote:

Do not:

Take part in inappropriate behaviour or contact, whether physical, sexual or mental.

What is 'mental' contact? Communication?

Harry Cutts