Unfortunately the Jenkins project will not be participating in the Google Summer of Code (GSoC) 2017. While I am disappointed, I am not all that surprised. Last year, our inaugural year in GSoC, was tough insofar that we had to learn many things the hard way, did a poor job of selecting student proposals, and failed to recruit a satisfactory number of mentors.
This year, I campaigned for a change in our proposal process. Instead of allowing anybody from the project to throw an idea into the top-hat of suggested project ideas, we would only list suggested project ideas that had a modicum of mentor commitment. Basically, if you weren’t willing to help mentor a student on your suggested project, we weren’t going to list it.
As a result we only had 3 suggested project ideas. Disappointing.
Considering our experience last year, where Oleg bore a significant personal burden stepping in as mentor when others failed to meet the commitment necessary, I would rather not have been accepted than to force Org Admins to do that again.
In my opinion the Jenkins project, or any open source project, should not attempt to participate in Google’s Summer of Code without being able to provide the necessary commitment to mentor students during the program. It’s exciting to imagine new contributors, and some funds donated, to the project, but the end-goal is to mentor and cultivate the next generation of open source contributors. The students must come first.
While it’s disappointing that the Jenkins project won’t have an influx of students this year, I have been discussing plans with Oleg to find ways in which we can mentor or encourage more activity from the hundreds of “casual contributors” to the Jenkins project.
In between this year and next, I think we (the Jenkins project) can focus on building up a mentorship base by:
- Expanding the number of plugin developers who contribute to more than just one plugin. Encouraging existing contributors to leave their little one-plugin-fiefdom of concern.
- Curate more low-hanging fruit in JIRA, and expose those to potential new contributors
- Doing whatever it takes to make it easier for somebody to contribute to the project. This includes, but is not limited to, Daniel’s Developer Documentation efforts, discouraging pedantic bike-shedding in new contributor pull requests, and encouraging more hands-on mentorship/pairing opportunities.
There are certainly a bunch of other things we can try between now and GSoC
- Either way, I’m disappointed, but I’m also optimistic that a GSoC rejection will encourage us to fix things. I would rather not be in GSoC than to ask a select few who are already stretched thin to commit time they don’t have.
Failure or rejection are learning opportunities, and to quote one of my favorite sayings: “let’s make better mistakes tomorrow.”