Title: MentoringProgramme
Many projects in the ASF are able to provide mentors for newcomers. In
fact, most projects are happy to assist newcomers to their projects as part
of their normal operations. However, some people are looking for more
structure. The Mentor Programme of the The Apache Software Foundation
provides additional support and structure for people looking to make an
initial contribution to an ASF project.
The mentoring programme is not here to teach you to write documentation or
code. It is here to help you understand how to make a valuable contribution
to an Apache project. You can expect to be guided through our contribution
processes. You can also expect to get technical support with respect to
your chosen project. You cannot expect your mentor to be a "teacher", they
will provide enough information for you to progress within the project. You
need to bring the confidence to take their guidance and discover the detail
for yourself.
This page is a description of the Mentoring Programme. The program is open
for business, but, like many other things at the Foundation, it under
constant improvement and revision. Therefore, the description below is
marked 'draft.'
# Quick Definitions
The ASF believes that the best way for people (and, indeed, entire
projects) to join the community is with the help of committed members of
the community. A community member who makes a commitment to help a new
contributor get started is a _mentor_. The new person, on the other hand,
is a _mentee_. Believe it or not, that is the word in the dictionary for
this role.
The Foundation is organized into a series of Top Level Projects, or TLPs.
The document uses 'TLP' when it is referring to an ASF project. It uses the
word 'project' to refer to a the work a mentee does under the Mentoring
Programme.
# Who can be a mentee?
The Mentor Programme is intended to assist people in becoming contributors
to ASF projects. Thus, anyone interested in contributing effort to an ASF
project is a potential mentee. You need to be a self starter, your mentor
will not take responsibility for "managing" your work here. Everyone who
contributes to an Apache project does so on a voluntary basis, there are no
managers here - only helpful peers.
Mentoring is a significant volunteer effort, over and above what the mentor
is already doing for the project. Therefore, the programme asks mentees to
make a material commitment of time to the process. There are no legally
binding commitments involved, but a mentee must, as described below, submit
a plan for a significant effort and show ongoing progress.
It is important to reiterate that all work on ASF projects is on a
volunteer basis. The Foundation does not pay anyone to mentor or
contribute.
## Applying for the Mentor Programme
There are two simple steps to apply:
1. Review the content below to learn about the details of the requirements.
1. [Fill out the application form](mentorprogrammeapplication.html)
If you are a student and wish to apply to the mentoring programme as part
of your formal education there are some [additional requirements](mentorprogrammeformaleducation.html)
that you must fulfill, along with your tutor.
# Draft: The ASF Mentoring Programme
The Mentoring Programme is structured around mentee projects. Each mentee
project is a coherent task contributing to one of the ASF's ongoing TLPs.
The Mentoring Programme does not work on a fixed calendar. Project start as
mentees and mentors are matched. Typically a project will last around three
months, but mentors and mentees are free to negotiate longer or shorter
periods of work.
The work of a mentee project can be code or documentation, so long as it
contributes to an existing Foundation project. Individual research or
prototyping projects are not acceptable -- working with an ASF project
community is an essential part of the process.
## Setting up a Mentoring Project
The first step is for a potential mentee to make contact with the Mentoring
Programme. Several of the following steps call for interactions with
potential mentors and target projects, and the Mentoring Programme mailing
list is the appropriate forum.
Next, a potential mentee should identify a Foundation TLP that he or she
would like to contribute to, and seek out a suitable project. The mentee
can propose an idea for a project, or ask the community for suggestions, or
ask the mentors for suggestions.
Given a target project and a rough idea for a task, the proposed mentee
must create a written proposal for the task, send it to the project's
development list for review, to ask for a sponsoring mentor. The sponsoring
mentor will be a member of the TLP.
This will lead to some negotiations with the project and a potential
mentor. If these negotiations succeed, the mentor and mentee agree to a
schedule and time commitment.
The plan must include a mid-project checkpoint as described below.
The mentor submits the agreed plan to the Programme, gets an acknowledgment
from the Apache Mentoring Programme admin,
and adds the project to the Mentoring Wiki as an "In Progress" Project.
The mentee sets up a wiki page for the project on the development Wiki,
linked from the Mentoring page.
The mentee joins the development community of the TLP and sets to work.
## Working on the Project
During the course of the project, the mentee is a member of the TLP
community. This has implications for both the mentee and the
TLP.
All Apache Software Foundation TLPs share some basic rules and conventions
for their operations. Each TLP has its own specific
conventions. The details of the ASF's conventions are beyond the scope of
this document, but a few principles bear repeating:
* Polite, respectful discourse.
* Open, transparent, discussions and decision-making.
* Open Source!
During the course of the work, the mentor is responsible for helping the
mentee navigate the process. If the mentee has questions, the
mentor answers or helps extract an answer from the community. If the mentee
has any problem in working with the community, the
mentor is available via email for private consultation. On the other hand,
The mentor is not intended to replace mentee background work.
Mentees must still read code, read email archive, and do any other work
needed.
Mentees have one additional responsibility over and above the usual work of
a contributor to a TLP: to give back to the Mentor Programme.
Mentees must document their work and experiences on the Mentor Programme
wiki, to help the programme improve the process.
In particular, mentees should document their code changes for possible
review. This can come in the form of subversion revision numbers or JIRAs.
For projects that are set up with FishEye, the Mentor Programme may set up
a JIRA project, and open a JIRA for each mentee. The
mentee can then ask committers to include their JIRA in commit comments and
thus set up automatic tracking.
## The Mid-Project Review
The Mentoring Programme reviews all projects at the half-way point. The
input to the programme review is a pair of reports: one from the mentor
and from the mentee. These are public documents.
The mentor's report must summarize progress and make a recommendation for
the
disposition of the project: continue to completion, or stop. The report
must also describe any changes to the project's scope.
## Scope and Schedule Changes
Inevitably, ugly facts will conflict with plans and intentions. Mentors and
mentees can agree to change the scope of a project and document the change
on the wiki and, as appropriate, on reports. The programme does not
encourage scope changes as a solution if the mentee is
unwilling to put in the time and effort to carry out the project. In such a
case, it is preferable to terminate the project. However,
nothing is completely black and white.
Similiarly, the programme prefers that projects end on their original
schedule, rather than drag out indefinitely.
If a mentee has made good progress on a substantial project over several
months, all while participating in the TLP community,
it is very likely that they are ready to continue without the help of a
mentor. Their Mentor Programme project can end in good
order even though coding continues.
## Finish up the Project
Every project ends, either when the work is done. or when the agree time
period is over. At the end, the mentee updates the Wiki page with a final
summary of their work.
The mentor submits a final progress report and determination of whether the
project should be marked complete or incomplete.
The admin acks the review and moves the project to completed or incomplete
as appropriate on the Mentoring Wiki.
Relevant certification is issued to both the mentor and mentee by the admin
team.
## Roles and Expectations
### Mentee
* The mentee is any individual interested in getting involved in open
source.
* The mentee is expected to dedicate a pre-agreed amount of time each week
to the project. Failure to
commit the agreed time is likely to result in failure on the programme,
* The mentee is expected to complete the project as described in the
proposal or make necessary scope adjustments with their mentor.
* The mentee is expected to maintain a Wiki page recording their progress,
which upon completion will present a final summary of their work with links
to code changes.
* The mentee is responsible for submitting progress reports at the half way
and completion points of the programme.
### Mentor
* The mentor must be a committer on the project accepting the mentees
contributions.
* The mentor is expected to dedicate at least 1/4 of the mentee time per
week to support.
* The mentor is expected to process supplied patches within reasonable
timeframes.
* The mentor is expected to ensure appropriate assitance is available from
the project community.
* The mentor is responsible for submitting progress reports at the half way
and completion points of the programme.
### Admin
* The Apache Mentoring Program admin(s) will liaise with ASF projects to
maintain a JIRA list of projects that are available and in progress.
* The admin(s) will assist with matching mentees with mentors
* The admin(s) will approve proposals and progress reports, but generally
won't do an in depth technical review but will rely on the mentor's
assessment.
* The admin(s) will mediate any dispute between mentee and mentor regarding
assessments/etc if the project community is unable to reach a resolution