Proposal phase gsoc summit session notes

Preface

• these are notes derived from a session held in 2023 GSoC mentor summit

  • the audience of these notes is the team at Mathesar
  • the tone is supposed to be one of recommendation
    • these are above all things to consider, as opposed to blindly follow
  • written up by Dom
  • they discuss techniques, methods, approaches
    • that we might use in upcoming GSoCs to improve the proposal phase
  • the motivation for having this session and keeping these notes
    • is that our previous GSoC proposal phases required a lot of effort and time
      • and we’re interested in improving that

• a different set of notes for the same meeting

  • (raw and not written by Dom)
  • can be found here.

Notes

Miscellaneous

• start early

  • best students start interacting very early
  • same goes for organizations

• encourage demonstrating value by contributing and being active

  • how that goes can be a strong indicator of how fitting a candidate is
  • consider only accepting proposals late,
    • e.g. last 2 weeks before the deadline
  • encourage preparing via contribution and community involvement
    • prevents candidate from endlessly refining their proposal
    • might give more valuable information than a highly refined proposal

• instead of defining very concrete projects

  • consider defining themes
    • i.e. be more abstract, leave wiggle room
  • let candidates find what needs to be done
    • this optimizes for contributors that fill in the gaps
  • this might not work for every project
    • for example,
      • when there aren’t a lot of things to be done
      • or when the possible projects are highly difficult and require great insight
  • nonetheless, vagueness of project idea can be a useful parameter to tweak

Communication

• public, clear, fair comms

  • some orgs keep proposals private
    • but insist that meaningful discussion/feedback be public
    • while others keep everything public
      • and reassure candidates that others won’t be able to steal their ideas
      • and note that “this is in the spirit of open source”
  • clear and fair
    • need openness for fairness
    • private proposal reviews give candidates with many private discussions an unnecessary advantage
  • lots of communication
  • these things together make proposal phase smoother

• self-filtering

  • once you make communication, discussion and feedback open for everyone to review
  • lower quality candidates filter themselves out
    • because they are able to gauge their fitness relative to others’

• open communication saves on management

  • when others see competition for a given project idea,
    • they’ll naturally consider less popular project ideas
  • last GSoC this was a problem
    • best candidates competed for the same project
    • adhoc solution was to ask one of them to submit another proposal
      • it turned out weak, because was done at the last moment
      • but we knew candidate to be strong

• encourage threading of conversations

  • and make those threads accessible to other candidates
  • that way candidates can review discussions around a given project idea
    • reducing redundant communication,
    • and encouraging communication between candidates
  • and also let’s them evaluate their competition
    • which helps distribute candidates between project ideas
    • and let’s candidates self-filter
    • reducing work for the org
  • zulip was introduced in this context
    • superior threading features to matrix/element

• have contributor prepare documents for future contributors

  • documents that help figure things out
  • and/or take first steps

Candidate selection and community

• high standards

  • having high standards can save on work
  • be clear (with yourself and others) about what kind of
    • contributors and mentoring you’re looking for
    • if a candidate doesn’t seem ready this year, tell them that
  • be harsh about not needing hand holding
    • if you can’t or don’t want to provide that
  • mentor exhaustion is a concern

• trade-off between candidate’s skill and candidate’s need for mentoring

  • when selecting candidates there are at least two things you can optimize for
    • how good a candidate already is
    • how much of an impact we can make by mentoring this candidate
  • i.e. balancing maturity and newbieness
  • a candidate that is not familiar even with the most basic things
    • might derive more benefit from mentoring
    • compared to someone who’s fairly self-relient and skilled
  • which is better for community?

• proposal/project is a start

  • ultimate goal is to get contributor involved in community
  • community building might be
    • more than just getting projects done

Project ideas

• tooling project ideas
  • projects that improve things which are often neglected
    • tests, linters, docs, dev scripts, ci
• a project idea needs to be easy to review
  • otherwise mentors will be taxed more
  • this applies to proposal review and to code review
  • useful criteria when evaluating project ideas
• some projects (e.g. scala) draw in very skilled candidates
  • such projects need challenging projects to satisfy those candidates
  • having project ideas that are all similarly challenging might not be desirable

Outreach

• outreach can help draw in more or better candidates
• seo optimization in and via gsoc
  • look at how gsoc project search works for candidates
    • optimize our relevant documents based on that
  • ask contributors to maintain blogs on our subdomains
    • helps future contributors
    • gives us seo benefits
    • ask them to use a lot of screenshots
      • helps newcomers
• doing a video
  • a video to advertise org to potential candidates
  • helps reach more candidates