Mentoring: setup and management
Management of mentoring projects
Please, be sure you have read already some general information on mentoring in CommonSpaces in this other help page: Mentoring: how it works.
In CommonSpaces, mentoring concepts and mentoring activities are closely linked to the fact that largely autonomous communities are hosted by a common infrastructure. The role of the communities and of their administrators are critical for mentoring.
The Administrator of a Community owns a general role of guarantor that things happen in a correct and fluid way inside it. Among other things, s/he
- by accepting the application of a user to the community, guarantees that the user has titles to become a trustworthy member of the community
- creates the Roll of Mentor inside the community and appoints its Supervisor, who in turn is responsible for the enrollment of the mentors in the roll
- on request, tries to find a mentor fitting a wouldbe mentee and monitors and/or facilitates the setup of the mentoring relationship.
Inside his/her user dashboard, the Administrator of a Community will find a section
- providing a summary of mentoring projects and of requests for a mentor related to members of his/her community
- highlighting situations possibly requiring some action from his/her.
Setup of a mentoring project
Two models are foreseen for establishing a mentoring relationship:
- model A - the mentee places a request for a mentor
- model B - the mentee chooses a mentor from a Roll of Mentors
The distinction above concerns mainly the setup phase of a mentoring relationship. It doesn't impact the later development of the mentoring project. Whatever the model, the mentoring project can start only when the mentor chosen has given his/her consent.
Each community can support model A or B or both. The administrator of a community can switch from the setup model A to B or viceversa only if no mentoring projects currently exist in the setup phase (pending requests); in any case it is possible to move from A or B to A+B.
Model A - Placing a request for mentor
The wouldbe mentee
- places a request for mentor;
as a result, s/he becomes the proposer and the mentee member of a mentoring project in the making, still lacking the mentor member; then
- an Administrator of his/her community picks a mentor from the Roll of Mentors and assigns this to the mentee;
as a result, the mentor becomes the other member of the mentoring project; finally,
- by accepting the request, the appointed mentor starts (opens) the mentoring project.
Note: if the chosen mentor doesn't accept (or doesn't accep within some time, say a couple of weeks), the choice expires; the Community Administrator can make another choice (model A); or, if model B is supported, the mentee can retract the request and choose a/another mentor directly (see next sub-section).
Model B - Choosing the mentor directly
After filling the other fields of a request for mentor, and saving them, as for model A,
- the mentee chooses a mentor from a Roll of Mentors;
then s/he submits the request. In this case
- the chosen mentor must explicitly accept the choice, so starting (opening) the mentoring project.
Note: if the chosen mentor doesn't accept within some time, say a couple of weeks, the mentee's choice expires and the mentee can make another choice or submit the request leaving the choice of the mentor to the Community Administrator (if model A also is supported by the community).
The mentoring journey
The development of a mentoring project can be seen as a journey being made by a mentee with the company of his/her mentor.
In principle, it could be left to the mentor to choose, possibly in agreement with the mentee, how to structure the mentoring journey. However, since much experience has been gained by specialized agencies, such as the Brightside Trust - UK (a partner in the CommonS Project), and best practices have been distilled from it, a mentoring journey can reuse a standardized structure, such as the one depicted in the previous page: Mentoring: how it works.
We have implement some tools allowing the mentor
- to model some variations of the basic structure of the mentoring journey, possibly in collaboration with other members of the Roll of Mentors: the model - or prototype - of a mentoring journey could consist in a Learning Path designed just for this purpose
- to choose for a specific mentoring project, after it has started, one of the available mentoring journey models
- to make explicit, at any time, which is the current stage of the mentoring project and to make available to the mentee (and to him/herself), at any stage, supporting materials matching that stage.
Site pages supporting the management of mentoring projects
In the homepage of each community where a Roll of Mentors is active, a link is present to the homepage of the latter; this lists all mentors enrolled, including those currently not able to accept requests.
Moreover, the homepage of each of those communities and the dashboard of each user include some boxes related to mentoring.
The view of a generic user
In the homepage of a community of which s/he is a member, the user has a view of:
- the mentoring projects (if any) in which s/he is a mentee, or his/her pending requests for a mentor (if any)
- the setup model supported by the community and possibly a button for requesting a mentor.
The user dashboard includes boxes replicating the information on ongoing projects and pending requests from a mentee viewpoint,
The view of the mentor
In the homepage of a community of which s/he is a member, the user being a member of the Roll of Mentors of that community has also a view of:
- the mentoring projects concerning mentees of that community (if any) in which s/he is a mentor, and the pending requests s/he still must accept or refuse.
The user dashboard includes boxes replicating the information on ongoing projects and pending requests from a mentor viewpoint,
The view of the community administrator
In the homepage of a community of which s/he is an administrator, the user will find:
- a small form for setting the mentoring setup model and other mentoring-related options
- a list of the mentoring projects concerning mentees being members of the community
- lists of the pending requests for a mentor submitted by users being members of the community, distinguished between those requesting from him/her the choice of a mentor (model A) and those waiting for the acceptation by the chosen mentor (model A or B).
The user dashboard includes boxes replicating the information on ongoing projects and pending requests for the communities, if any, of which the user is administrator, making easy to identify situations where some action is expected from him/her as an adminsitrator.