Following recent discussions about possibly creating a Community Development (or Community Outreach) group within Apache, some of us would like to meet at ApacheCon Oakland 2009 to discuss the project's goals and organization.

When

The meeting will probably take place on Monday afternoon November 2nd, at BarCampApache (co-located with ApacheCon) - watch this space.

What

Here's a suggested description of the groups's goals, subject to discussion.

The plan is to organize the group as a PMC, with a similar structure and governance as our coding projects.

Community Development Project

The mission of the Community Development Project is to help students and would-be open source developers in becoming involved with Apache projects.

The Community Development Project:

  • Coordinates the ASF's participation in student programs like GSoC and GHOP, and other similar programs.
  • Provides a space for mentors to exchange experiences, best practices, etc.
  • Provides information and resources to students and would-be open source developers.

Participation in the Community Development Project is open to all volunteers, and decisions are made by the project's PMC members, via votes on the project's public or private mailing lists.

MeetUp Agenda

The MeetUp will not follow a strict agenda, the idea is to follow the interests of those present and explore options for the Community Development group. However, here are some topics that may be discussed. Note, these are topics for discussion, it is not assumed that all these will be within the remit of the Community Development group, nor is it assumed that each point is a good idea:

  • making more of GSoC and GHOP
    • publicising student/mentor successes
    • clearer mentor guidelines
    • more active support of mentors and students
  • sharing resources with other mentoring activities
    • mentor manual from GSoC team
    • teaching open source group
    • mozilla education
    • etc.
  • mentoring outside of GSoC/GHOP (See draft proposal in Appendix A)
    • creating a rolling mentoring program (mentees and mentors are matched as and when they are available)
    • providiing recognition and reward for mentors and mentees
    • collecting and publicising mentee tasks
    • connecting mentees to tasks/mentors
  • mentoring as part of formal education/work based learning/internships
    • how to embed mentoring activities in formal education
    • how to embed mentoring in work based learning/internships
    • mediating between tutor/trainer and mentor/mentee
  • other areas of community development that may fall within remit if volunteers are available
    • open development documentation (e.g. documenting "The Apache Way", see Shanes Apache Way site)
    • women@apache.org

Please feel free to add other potential discussion points here.

Notes

Here are my DRAFT notes from the meeting:

  • Infrastructure [ACTION] BD

  • Mailing lists - See https://issues.apache.org/jira/browse/INFRA-2304
    • comdev-private@
    • comdev@
    • community@
      • Cross project interaction
    • code-awards@
      • GSoC only
      • privately archived
  • SVN - https://issues.apache.org/jira/browse/INFRA-2305
    • comdev
  • Web
  • JIRA - see https://issues.apache.org/jira/browse/INFRA-2303
    • comdev
  • Three month goals

  • Nail down mentoring program [ACTION] KM

    • Here are my notes from the (separate) BarCamp session on this
      • Who starts the project idea
  • Students suggest
    • projects can propose
      • projects need not be code only (as GSoC is)
      • Official mentor needs to be a committer
    • Actual mentor may be community
    • Must ensure patches are applied quickly
      • we need to list expectations for mentor and mentee
      • mentor network
    • real people to talk to
    • not necessarily related to the mentees project
    • foundation rather than project mentors

  • link with incubator [ACTION] RG

    • documentation on being a committer
    • Factor out the "how do you participate in the community"

  • link with TAC [ACTION] RG

    • would they set aside a part of their budget for bringing mentees together

      • Nick Burch was present at the meeting and asked to be a member of the PMC [ACTION] RG

  • Event calendar
    • Byelaws
      • PMC members need not be ASF Members
      • Do Members have right to ask for membership?
  • Other goals
  • Run a meetup to introduce people to easy community tasks
  • Encourage projects to have managed release cycles for closer integration with commercial activities
  • people.apache.org
  • project.apache.org
    • Melange (Google GSoC application)
      • Do we want to use it for tracking?

In addition to the notes above from this meeting I provide my notes from Kirrily Robert's keynote. They may be useful for future work:

  • Educate yourself
    • Read Opening the Clubhouse
  • Pay attention
    • See exclusive activity
  • Recruit diversity
    • reach out to minority groups
  • Be relevent
    • communicate use of project outputs
    • some people are not focussed on the technology but the uses
  • Say it. Mean it.
    • Code of conduct
      • See Ubuntu or Debian
    • Enforce it
  • Transparency
  • Tools
    • identify easy issues for newcomers
    • Discourage people from cleaning the easy queue
  • Mentoring
  • Value all contributions

Who

Current volunteers include:

  • Ross Gardler (rgardler at apache dot org)
  • Luciano Resende (lresende at apache dot org)
  • Santiago Gala (sgala at apache dot org)
  • Bertrand Delacretaz (bdelacretaz at apache dot org)
  • Kathey Marsden (kmarsdenderby at sbcglobal dot net)
  • Ted Dunning (ted dot dunning at gmail dot com)

Feel free to email us for questions about this, we don't have a mailing list for the group yet.

Add your name here if you're also interested in participating in the meeting, and maybe later as a member of the Community Development Project. Leave your email address if you want to receive details about the meeting's time and place.

  • <your name here>

Appendix A

Draft ASF Mentoring Program

Kathey Marsden has worked with Bernd Fondermann and Ross Gardler on the ASF CodeAwards list to draft an outline plan for the creation of an ASF wide, ongoing, mentoring programme. The text of this proposal is copied below for your consideration and comment. Note this draft proposal is not to be considered an indication of the defined direction of the community development group, it is merely a suggestion for us to consider.

Draft Apache Mentoring Program

Overview

The Apache Mentoring Program is available all year but each project starts and stops as mentors and mentees are matched together. Typically a project will last around three months, but mentors and mentees are free to negotiate longer or shorter periods of work.

Projects can be code or doc, but should be something intended for integration into an Apache project. Individual research or prototyping projects are not acceptable since they will not allow the mentee to learn about community development at Apache.

Potential mentees choose from projects ideas proposed by mentors or draft their own in consultation with the project community.

Potential mentees send project proposal to the appropriate development list for review and to ask for a sponsoring mentor.

After necessary adjustments to the proposal are made, mentor accepts/rejects the proposal and agrees a start date and time commitment with the mentee. Mentor gets an ack from the Apache Mentoring Program admin and adds the project to the Mentoring Wiki as an "In Progress" Project. Mentee sets up a wiki page for their project on the development Wiki which is linked from the Mentoring page.

During the course of the project the mentee is treated like any other member of the community, for example all technical discussions should be conducted on the appropriate project list and mentees are encouraged to create subtasks and make incremental submissions to the svn repository rather than make a large submission at the end.

Mentors ensure that the mentee requests for assistance are responded to in good time and are thus able to progress. They also provide oversight with respect to the mentees progress, possibly providing non-technical advice and guidance offlist.

The Mentor is not intended to replace mentee background work, they merely provide a contact point and guidance where documentation and process is unclear. The mentee is expected to document guidance provided by the mentee within the appropriate documentation.

The project scope can be adjusted for technical reasons, for example precursor work was required or there were many review iterations, but it cannot be adjusted, simply because the mentee was not making the required time commitment.

At the half way point in the mentor program the mentor submits a progress report and recommends the project be continued or marked incomplete at that time. Any adjustments to the project scope should be called out in the report. The mentee will also submit a mentor review, so we can make sure that both the mentee and mentor are are getting sufficient support.

After completion of the scheduled project time, the mentee updates their Wiki page with a final summary of their work with links to code changes. 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.
  • 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, but the entire development team can provide support and must provide oversight in the normal ASF way.
  • The mentor is expected to dedicate at least 1/4 of the mentee time per week to student support.
  • 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 maintain the Mentoring Wiki with links to "In Progress", "Completed", and "Incomplete" projects.
  • 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

Mentoring in Formal Education

It is expected that some mentees will wish to participate in the mentoring program as part of a formal education course. In these cases there will be additional requirements on the process to ensure that the mentees can be evaluated by their tutor. This section describes these additional requirements and process.

Overview

Projects are defined by the students tutor in consultation with the project community/mentors and the student. They will need to be isolated enough from other ongoing work to ensure that success/failure to deliver is not dependent on someone else. They will also need to be of sufficient complexity/simplicity to be a final year project.

Tutors are responsible for the day to day management of the student. If the student does not participate in the project it is not a concern of the mentor. The mentor must be available for the tutor should a problem arise and must be willing to mentor the tutor with respect to how they encourage the students to participate

Roles and Expectations

In addition to the notes above:

====== Tutors ======

  • Ensure the mentee is participating in the program
  • Tutor grades the student within their formal education (the mentor feedback should assist here)

====== Mentees ======

  • mentees are typically students in their final yearm they participate as part of their final year project which forms a formal part of their examined work.

====== Admins ======

  • Provide assitance in interpreting reports to allow tutors to grade student participation
  • Provide mediation between student, mentor and tutor in the event of a dispute
  • No labels