What I learned at GSoC Mentors Summit, 2018

Community
1

image
image1280×960 420 KB

Me, Yaw and Jeff at GSoC Mentors Summit '18 (Google Campus, Sunnyvale)

A few weeks ago, I attended the Google Summer of Code (GSoC) Mentors Summit with @yanokwa, @Jeff_Beorse, and @downey. It was an amazing experience and I would like to thank @LN and @yanokwa for serving as org admins and giving me this opportunity.

At this year’s summit, I learned three big lessons that I will use to improve ODK’s code and community going forward.

  1. Focusing on writing user docs and inline developer docs while writing new code
  2. Improve the organization of the GSoC program in our community by structuring some of the processes
  3. I was amazed to see the exceptional use of Trello for keeping the volunteers occupied and also using it as a tool to understand the action items. I am looking forward to discussing the pros and cons of the addition of another tool with the community.

Over the three day summit, there were a lot of sessions going on in parallel so I was only able to attend a few of them. I took notes and I’ve summarized the highlights from those sessions below. If any of these notes give you an idea of how we can improve our community, please let me know so we can work on the improvements together!

Documentation

  • Some people prefer docs living closer to the code (not feasible in case of ODK which has a lot of repos and a centralized documentation for all)
  • Inline developer documentation provides a lot of contexts while writing user-documentation
  • Promote Documentation Driven Development (DDD). When someone contributes to the code, the same person should add the docs in the same PR or a link to an issue (ODK does it already)
  • Tooling should make it as frictionless as possible to add docs (sphinx)
  • Automation that takes screenshots during tests, and integrates the screenshots in the docs (might not be feasible in ODK’s use case where docs and code do not reside in the same repo)
  • We need to encourage tech writing, and also make it part of the developer culture.
  • README-driven development. You’re responsible for writing the test cases and docs as well as the code.
  • GSoC projects should include writing the docs for the code as well

Search for mentors

  • Trello checklists mentioned below under “Volunteers” heading
  • Mentors should have a personal interest in the project and the global goals of the project
  • Early start looking for GSoC students
  • Finding mentors by organizing meetups
  • Sharing the word using social platforms
  • It's okay in not being a super-coder mentor but it’s important to be a social and motivating one
  • Bonding period very important for predictions. The earlier the better. The longer the better.
  • Mentors lacking responsibilities drifting off: structure the process more. Schedule meetings.
  • Make the mentoring process more structured
  • One org alternates between
  • even week: a one-on-one meeting between the student and their mentor(s)
  • odd week: all students/all mentors meeting
  • Get on social media to recruit students
  • Announce mentoring opportunities during regular project meetings

Retaining students

  • Give people responsibility & roles so that they have a sense of ownership
  • Show the career benefits of staying involved
  • Continue meeting even after it ends
  • Invite students at conferences/meetups
  • 4Rs (Mifos) - Reward, Recognition, Recommendation, Referral
  • Make it a pre-requisite for students to get involved in other ways (code reviewing)
  • Publish articles or videos recognizing students.
  • Keep on people who have been rejected but had great proposals
  • Offer to send them a certificate/t-shirt for their work
  • Help with recommendation letters
  • Maybe will help them get accepted to GSoC the following year

Volunteers

  • The main focus was on how to use Trello board to keep a track of volunteers (visibility restricted based on the type of board) entering and leaving the projects and use that info to motivate people and direct people to useful tasks which need volunteers
  • Why it is required? - Github only shows commit history and it is difficult to keep a track of the actual contribution of volunteers
  • Trello has features which have proven to be super-useful to automate/remind tasks related to management or motivation of volunteers
  • Some use cases mentioned
    • Keeping a track of new contributors who need motivation/guidance and following up with them
    • Sometimes people lose interest in a project because they don’t know what to work on
  • Checklist of user-life
  • Trello board life-span.
    • Look and check for a PR
    • Look for new forum user intro
    • Look for new issues/replies
    • Check social network
  • Having a public board which is visible to everyone
    • Ongoing tasks: Stuff that needs to be done regularly (Code review)
    • Roadmap items: Development stuff that needs to be planned and discussed
    • Released items: Tasks that are completed are moved into this
    • Example Trello board
  • A private board to keep a track of all contributors
    • Having all references of the user on different platforms (GitHub, forum, slack, email)
    • Keeping a checklist of user-life i.e. milestones for the contributions made and also using that to give badges in the forum. This helps in indicating if someone is ready for being a GSoC student/mentor, trusted reviewer
      • Eg. Introduction on slack/forum, PR submitted, Issue opened, Made a significant contribution, Code reviewed,
    • Use Trello’s feature to make the card turn yellow if we haven’t engaged with that person lately
    • Trello can be integrated with GitHub, slack and other tools to keep stuff automated to a certain extent but maintaining this board takes up a significant amount of time
  • Suggestions to use separate boards for GSoC/Outreachy program

Mentor/Mentee Relationship

  • Recommend mentors to read Google's guidelines or create a new one because larger sized guidelines have counterproductive results
  • Recommended mentors to ask mentees to regularly update the community / write blog posts with the weekly / bi-weekly progress
  • Use community bonding period to create a bond between students and the community by setting up video conferences, discussing the project
  • Communicate with students in public! It’s important that students must bond with the entire community and just with the mentors.
  • Make it mandatory to write a blog post every 1-2 weeks
  • Story - Students have to go to a public event and show the idea

Quality of Software

  • Quick summary: ODK already has a pretty solid development-release-cycle which along with governance makes the release cycle structured
  • The focus was on how to decide when a release should be made based on the stability of the software
  • Use Net Promoter Score (NPS) to get user feedback
  • Handle public negative feedbacks/complaints gracefully. People usually do not realize that an actual person is responding and become harsh. Try emailing/messaging them (twitter/play store/mailing list/forum) and understand the reason for their review. Use a profile pic of yourself and not an avatar.
  • Ship experimental features along with the production release (may not be applicable to all projects). The only condition is that the experimental feature should not cause any kind of data loss to the user.
  • Experimental button for voluntarily opt-in for the experimental feature

Open Source Metrics

9 Likes
2

Thanks for sharing this Shobhit! The mentor summit is an awesome opportunity. I hope your post will inspire others in the community to become GSoC mentors if only to be able to participate in a future year, let alone the great experience of working with an awesome student.

Michael Downey

5 Likes
3

Thanks for the wonderful writeup, @Shobhit_Agarwal! I'm so glad you were able to make it all the way out to the Summit and that's just barely over a year after you were ODK's first GSoC student yourself. You are an inspiration to us all! :tada:

I want to highlight your note about public communication from the mentor/mentee relationship section. I think that's particularly important across the project and is something I hope we can keep improving!

5 Likes
4

Thanks for such a fantastic summary @Shobhit_Agarwal! It was great to meet you in person and participate in the summit together!

You have very thoroughly covered a lot of the lessons I took from the summit as well. I will add a few of my notes below as a supplement.

ODK vs other Open Source Communities
Overall, I got the impression that as an open source community we are fairly well organized, and though we have our struggles, many other organizations face similar challenges. This doesn't lead to any particular lesson, but I was glad to see that our community is doing well and we are in good company.

Some of these shared challenges include:

  • Attracting and retaining new contributors
  • Improving diversity among the community
  • Making docs contributions robust and intelligent while still easy and frictionless.

Google Season of Docs
Google is considering running a new program called "Season of Docs" that would be similar to GSoC, but would focus on documentation. It would also recruit aspiring technical writers rather than students. These writers would presumably already have full time jobs, so they would be contributing fewer total hours to the project. The idea is that the writers are hoping to gain tangible experience to leverage into a career in technical writing at a place like Google, Microsoft, Amazon, or the like, and the projects gain documentation contributors.

Converting Users to Contributors

  • Don't fix all the easy bugs right away. If they can wait, leave them and tag them for new contributors.
  • Have a good Github presence
  • Organize community events
  • Remove the word code from some things to make them less scary. For example, code sprints -> community sprints. Encourage contributions from all types
  • Explain the value of contributions. Particularly for users that are organizations, give them something they can bring to their boss about why contributing is good for their organization. For example: "the community will fix bugs + improve your module", "you don't have to do the same work twice". Publicly post these arguments on the website for why to contribute back.
  • Give space for contributors to brag about contributions they are proud of. Maybe on the forum or in a newsletter. Make it a regular thing so that it doesn't feel awkward or like showboating.

Managing Students: Maintaining Focus

  • Be firmest with requirements with the student in the beginning. It may feel unnatural; it is not the way you make friends. But it is necessary to set the precedent up front. Over time when trust is built you can wiggle more.
  • It need not be 1 mentor per student. Many orgs have two or more mentors per student. However, be careful not to let them play mentors against each other, or have things lost in the confusion. Probably good to assign a "lead" mentor who has final responsibility.
  • Don't let the mentor cover for the student or write their code for them. Collaboration is OK but students must complete their own work.
  • Keep as much discussion as public as possible. Encourage regular public communication. For example, weekly posts from each student with what they are doing, what they have accomplished. Students are usually intimidated by this, and are especially afraid of posting mistakes. Try to show the humanity of all contributors (how they all make mistakes) and encourage active discussion.

Attracting Diverse Contributors
This panel focused mostly on making the community more friendly to non-male (female, non-binary) contributors, though a lot of it is true for making a more welcoming, diverse community in general.

  • Post a code of conduct publicly and enforce it. Do not tolerate hate speech, bullying, or the like. For example: http://systers.io/code-of-conduct
  • Keep as much discussion public as possible. Some organizations have a policy that if a discussion didn't happen in public, it didn't happen at all (aside from a few leadership meetings). The idea is to not allow a bully to abuse someone in private and deny the abuse.
  • When creating a GSoC project description, or anything kind of posting that people will apply to, be aware of differences in how people read requirements. Traditionally many female applicants will see that they have 3/4 of the requirements and decide not to apply, while males are morel likely to meet 3/4 of the requirements and apply. Be more explicit about what are hard and soft requirements and nice-to-haves, and use more inclusive language. There are materials that teach this skill.
3 Likes