GSoC Tips: What makes a good project?

Continuing our #mentorship #tips, I’ve got a question for all of you past & current GSoC mentors:

What makes a good (well-defined, fun, and ultimately successful) GSoC project?

  • How do you know how much work to include in the initial project description?
  • How do you decide which activities and tasks to group into a reasonably-sized project?
  • How do you avoid students feeling like they’re on “Open Source Clean-Up” duty, doing stuff no one else wants to do?

Would love to hear from those of you with ideas and experience. Thanks!

I think I would have the following as suggestions for projects:

  • Make sure you have entry level issues to ease out student to get into your project. I think this is going to be helpful for first time students.
  • Have mentor available to give early guidance and answer questions.
  • For the most part during the GSoC I think the biggest task is keeping student staying on track (use issue tracker, slice the entire project into bite size task).

We need to ensure that a 100% failure rate doesn’t happen again with LibreHealth and that we don’t get a student that’s all talk and can’t do the project. One idea that I got from the Mentor Summit was to create a task that by design requires them to do research to complete the task. Not sure if that would be torture, or would lead us to have rockstar students.

Another thing that I remember @downey doing during the OpenMRS days was a survey that tracked students’ experiences during the program, and similarly, for mentors; think of them as unofficial evals. I fully intended to carry those over, but never did. I want to do that this year.

Some other things:

  • Blog posts weekly
  • Each project gets a thread on discourse and new this year, a Discussion on Rocket Chat and they must use both of these as all communication is public, otherwise it never happened.
  • Failure to do the above, may lead to a fail even if the code works, that’s not the point of GSoC. If the code is complete but the student is silent, that is a red flag and means that they are having private communications with their mentors, and that’s not good.
1 Like

Hi all, at Public Lab, Emily Ashley and I brainstormed on this a bit. We felt that a good project:

  • can be broken into smaller parts that can be merged into our main branch on at least a weekly basis
  • could be completed as a “small” initial version (MVP) that is later expanded on or refined
  • has an integrated recruitment plan, i.e. the student has plans to recruit others into the project and designs the project for this
  • has background/context/historic info readily available to inform the work
  • is generally self contained - all the code in one place (or clear integration guidelines provided)
  • contributes to our software roadmap - (stability, maintainability, low technical debt, legible:
  • solves priority issues for Public Lab’s broader community
  • provides a feeling of accomplishment!
  • helps students build skills/portfolio
  • is a “cool new thing” (but not all the projects we NEED done fulfill this…!)
  • has a good plan for integration/publication to the live production environment, and schedules time for this

We’ve also compiled some guidance on our community’s workflows and style of collaboration, which also inform good projects and project plans, here!

I hope this is helpful!!