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.
The meeting will probably take place on Monday afternoon November 2nd, at BarCampApache (co-located with ApacheCon) - watch this space.
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:
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.
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:
Please feel free to add other potential discussion points here.
Here are my DRAFT notes from the meeting:
Infrastructure \[ACTION\] BD |
Nail down mentoring program \[ACTION\] KM |
link with incubator \[ACTION\] RG |
link with TAC \[ACTION\] RG |
Nick Burch was present at the meeting and asked to be a member of the PMC \[ACTION\] RG |
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:
Current volunteers include:
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.
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.
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.
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.
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
In addition to the notes above:
====== Tutors ======
====== Mentees ======
====== Admins ======